frivoal

I think Pen vs mouse isn't the issue. To me, the question is: did you do it all yourself, to the last line (including choosing the thickness, the color… of it all), or did something do it on your behalf, based on higher level instructions?

When you draw by hand, you are directly responsible for everything that ends up being on the paper. Nothing ends up there that you did not deliberately put there. So you get to know every what every single line, every single line style is for. You wouldn't put them there otherwise.

When you draw with the computer, you ask it for something, and it produces some output. But what makes computers efficient is that they do a lot of the work for you. So you do not digitally draw every single pixel yourself. You ask for a screw, a window, a light fixture, and you get one. It's much faster (and possibly prettier), but you are not necessarily getting familiar with every single piece of the drawing that gets produced when you ask for one.

If architects (or mechanical engineers, for that matter) don't really need to know what a thick or thin line is for, or what the parts in the drawing of a window or of a ventilation system mean, then they don't need to draw my hand. But if they do, I'd argue that learning drawing by hand does matter. (Or in some pixel art program, but ain't anybody got time for that.) Once you do know it all, use whatever too, but start by learning the basics of your craft, thoroughly.

Automation on top of understanding is great. Automation instead of understanding is fast, until it's a source of mistakes and confusion.

I don't think virus is a 4th declension noun, and I've seen it described in multiple sources as a 2nd declension (meaning slime, poison, infection, mucus, or something thereabout). It is unusual in being a -us noun despite being neuter, but irregularities happen (other examples of neuter 2nd declension -us nouns being vulgus and pelagus). In classical Latin, it is a mass/uncountable noun, and only got the modern meaning (and the ability for form plurals) in recent times.

references: https://en.wikipedia.org/wiki/Latin_declension#Virus https://en.wiktionary.org/wiki/virus#Latin https://gaffiot.fr/#virus

That said, your point about virulent vs virolent is interesting, but I don't know enough about sound changes, or how that word came to be and made it's way to us to know if this is counter evidence to being 2nd declension, or if it can be explained away otherwise.

This is a duplicate of https://news.ycombinator.com/item?id=34021208 (not your fault, OP cross-posted between twitter and mastodon)

All the above is correct. Additionally, it is important to understand that W3C isn't wholly hosted at MIT. MIT is one of 4 co-hosts (the others being Keio University in Japan, Beihang university in China, and ERCIM in France), though MIT is the central hub of that relationship.

The reason why this cannot be done is documented in the csswg's informal FAQ: https://wiki.csswg.org/faq#versioning-css-fixing-design-mist...

All the history of the css colors, and lots of humor: https://www.youtube.com/watch?v=HmStJQzclHc

That country could have an interestingly named neighbor: if Ireland and Scotland band together, they could be the United Republic of Ireland and Northern Great Britain.

For the font size, it's kind of the same, kind of not. The numerical value of the font sized used is typically the same, but Chinese characters fill the allocated space more thoroughly.

i 泳

If you like this, there's a whole family of such documents:

Chinese: https://www.w3.org/TR/clreq/

Ethiopic: https://www.w3.org/TR/elreq/

Arabic: https://www.w3.org/TR/alreq/

Tibetan: https://www.w3.org/TR/tlreq/

Korean: https://www.w3.org/TR/klreq/

Indic: https://www.w3.org/TR/ilreq/

Tamil: https://www.w3.org/TR/ilreq-taml/

Japanese was the first in the series, but the rest is equally fascinating (even if the documents may be somewhat less mature)

Same here. Desktop mail client just had its first successful connection in a little while.

> The web was designed to publish documents, it was never intended to build applications.

I find that repeated a lot, but to me, it's somewhere between an overstatement and a misconception.

Sure, the early web wasn't anywhere near the versatility of what we have today, and interactivity was extremely limited (and as you say, is still more complex than it ought to be). But the semantics of HTTP+HTML, from the early days, allowed for application development. If all we had had were <p>, <h1>, <aside> and GET, sure, documents it is. But we had forms and POST and everything you need to make a CRUD application from the early 90s. It was pretty basic, but so was support for documents (tell Desktop Publishing people that HTML in the 90s was good for documents, and they're not likely to agree much).

Just as one example, what is this, of not an application: https://thehistoryoftheweb.com/postscript/pizzanet/

Or, more commonly, Nihon. Nippon is more emphatic, which is occasionally taken to make it sound more nationalistic.

The notion that non profit boards are self appointed and answerable to nobody doesn't seem universal. In the model I am familiar with (the French one), non profits typically have broad and open membership, and that membership elects the board. In fact, I find it difficult to find non-profit with self appointed boards to be quite as legitimate. While the board doesn't actually own equity as shareholders would in a for profit, since they are answerable to nobody, they effectively run the organization for their own sake. They might have a charitable agenda, but there isn't much holding them to it.

Depending on what you consider core: also SVG, WebRTC, ServiceWorkers, Aria, Web Payments, WOFF, Web Audio…

Can a new phone platform be successful if it launches without whatsapp / wechat / line / instagram / [add a dozen social networks there]?

A phone that doesn't let you speak to your friends, family, and coworkers is going to be a tough sell. Getting all those from the get go, without a large user base to motivate the developers, is going to be a tough sell.

Pretty sure bufferin is aspirin, not paracetamol.

I'd speculate differently. Americans commute by car, audiobooks are convenient to read while driving. Japanese commute by train, which is much more suitable to looking at a book (paper or electronic).

Also, Manga is massively popular, and that form doesn't covert well (or at all) to audiobook.

Here's a greatly entertaining talk about the whacky history of the bizarre naming of colors in CSS: https://www.youtube.com/watch?v=HmStJQzclHc

The naming is far from great, but there is a method to the madness. Here's a talk I did a while back on how various line breaking things fit together: https://cssday.nl/2019/speakers#florian

I suspect the opposite situation is what you run into: it is possible to write programs that are valid and out to be accepted by the type system, but get rejected because you blew the stack of the type checker. Had the type checker been allocated more memory / time, it could have accepted the program, but it crashed before that.

This reminds me of that: http://litherum.blogspot.com/2019/03/addition-font.html

You can craft font files that perform arbitrary calculations… if you give the font shaping engine a (practically) unlimited stack, where it usually limits recursion to 6 levels. If you do so, you can make a font that does math (or whatever you want) as part of computing ligatures.

But in practice, you hardly ever hit those kinds of limits unless you're trying to do something silly on purpose. Sure you cannot port Doom to font substitution lookup tables, despite them being Turing complete. But that doesn't make your font shaping engine useless, or even broken.

That's still weird though. By that logic, they should ban all web browsers, and mail clients… Content they find unacceptable is definitely accessible through those.

Banning all applications that enable access to non-moderated decentralized content is simply not compatible with a phone being a smart phone.

This would encourage the people who have the most options to leave, and those with the least to stay. This isn't necessarily the same, but is likely to be very similar to encouraging your best employees to leave, the worst ones to stay.

No, because the group that decides on raising the salary is not a shareholder meeting or something like that, but the same people who get that salary. See Mozilla's bylaws: https://static.mozilla.com/foundation/documents/mf-bylaws.pd...

Some countries do have a huge mask supply: in Japan for instance, wearing a mask if you have a cold / in the cold season / in the pollen allergy season / … is very normal, and almost everybody has a box or two of masks laying around the house. If masks are even remotely useful, telling people not to were the masks they already own (because you touch your face or something) is also pretty nasty.

> when you can guarantee that your JS will never apply certain styles to certain elements

It goes further than that: using contain means that even if you tried applying these styles that would break optimizations, the browsers will not obey you. css-contain isn't just a hint to the browser that you're not screwing things up, it's a mode switch that prevents you from doing so.

> That seems to imply that `overflow: hidden` could still be used with `contain: size` to "access" clipped content.

Ah, you're right. This changed at some point in the history of this property, and I was remembering the old version.

> And still I don't see how the optimizations they list are not available with `overflow`.

Here's one: Setting overflow to something other than visible doesn't cause the element to be a containing block for absolutely positioned children, so they can escape. https://jsbin.com/wesirup/edit?html,css,output

Here's another one: stacking contexts are weird https://jsbin.com/hepiqof/edit?html,css,output css-contain:paint puts sensible boundaries.

> BTW, I think it's unfortunate that the MDN article introduces `contain` as if it were a hint... ...when actually it modifies layout and display behavior, overriding other properties.

Agreed.

`contain: none` is a thing: https://www.w3.org/TR/css-contain-1/#valdef-contain-none

> `contain: layout` means that its internal layout is not affected by anything outside.

The other way around:

* normally, a float can poke out of its parent div, and affect stuff around

* an absolutely positioned element can poke out of its parent, and if a further ancestor is overflow:auto and the absolutely positioned thing goes far enough, it could trigger scrollbars, whose appearance could cause a relayout

* margins of children can collapse with the margins of parents (recursively), and affect the layout of ancestors

* there are more like that

> `contain: paint` means descendants cannot display outside the element's bounds. Isn't this already given by `overflow: hidden`?

Almost: `overflow:hidden` actually makes the element programatically scrollable. It doesn't discard everything that sticks out, because you might just start scrolling using JS, so the browser needs to keep a buffer with the out -of-view stuff ready, just in case, even if it's unlikely. Or maybe it'll optimize a bit more, and create these buffers on demand, but it still needs to have facilities to keep track of which buffers it has, which it could create, what font would need to be downloaded to render the out-of-view part…

> If these properties disagree, who wins?

contain wins. The point of contain is that if it's on, the behavior is guarateed, and the browser doesn't need to check a dozen properties on an arbitrary number of elements before knowing if certain optimizations are safe to do. So if it's on, it's on, and there's no way to break out.

> `contain: size` means that the element's size does not depend on its children. Isn't this already given by height, width, etc?

* there's an etc here, and it turns out that there a few more properties than you'd expect that need to be checked. Doable, but checking 13 properties takes more time than checking 1, and we're trying to turn on optimizations. Expensive checks before you can optimize can make the optimization not worth pursuing.

* There are cases where even with `width` set to something other than a fixed size, the width of the parent doesn't depend on children. But checking if you're in one of these cases can be complicated, if it isn't being guaranteed by something like contain.

Browsers can do that, scrolling is cheap (unless you highjack it with JS, but that's another story).

However, if change the layout / content of some element in the page, making it bigger, or smaller, or positioned differently, etc, that has an impact on its parents, recursively. So browsers mark subtrees as dirty when something changes, and work their way back up.

In certain cases, there are changes that cannot have an effect on the parents, so you should be able to stop the recursion. And browsers typically are reasonably smart about that.

However, there are a surprisingly large number of cases where checking whether or not the parents could possibly be affected by the change is an expensive operation, so you're better off relaying out your parents (recursively) rather than checking if you could safely skip doing it.

Css-contain changes the rules of how css works, to eliminate these expensive to check cases. contain:content makes a few useful things impossible. contain:strict is even harsher, as parents' size cannot depend on children's size. But if you happen to have an element that can be set up to fit within these constraints, turning containment on on the right element lets the browser know that a whole bunch of optimizations are safe without checking for preconditions.