frivoal
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.
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.
i 泳
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)
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/
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.
Also, Manga is massively popular, and that form doesn't covert well (or at all) to audiobook.
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.
Banning all applications that enable access to non-moderated decentralized content is simply not compatible with a phone being a smart phone.
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.
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.
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.
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.