41–50 of 50 posts
Earlier quoted context omitted.
Bizarre that a statement of fact is being voted down.
Didn’t downvote (can’t even downvote, wouldn’t anyway), but if I were to guess it’s that the article talks about it fairly extensively.
Earlier quoted context omitted.
I'm also frequently surprised at how long certain CSS features take to implement. Some recent examples for me are the `has:()` pseudo selector [1], the scripting media queries [2], and css nesting [3]. [1] https://caniuse.com/css-has [2] https://caniuse.com/mdn-css_at-rules_media_scripting [3] https://caniuse.com/css-nesting
The `scripting` @media query isn't very useful. If you want CSS that's in effect when the browser doesn't have JavaScript, you can put those styles inside . More commonly, use JavaScript itself to add or remove a class that is used within the relevant selectors. Only using JavaScript itself is potentially effective when script-blocking extensions are used rather than JavaScript not being available at all. `:has()` is…
If your styles are defined within external stylesheets, then having to extract them from their respective stylesheets and place them directly in a noscript DOM node is not very ergonomic (and it will also affect your ability to cache those styles, since they're now a part of your potentially dynamically generated HTML rather than a static stylesheet).
> use JavaScript itself to add or remove a class that is used within the relevant selectors.
Well yeah, If you're ok with adding JS then most native CSS features can be polyfilled. This is a very imperative solution to a problem that the scripting media query handles declaratively. I would much rather have my styles dictated by my stylesheets, and reserve my JS for adding interactivity.
> However, even if someone figured out how to implement it twenty years ago, it probably still couldn't have been used for performance reasons.
Yeah the has selector is similar to a lookahead assertion in a regular expression, and CSS nesting is similar to a lookbehind (both of which can be computationally expensive). I'm not sure browsers needed to wait until the 2020s to deliver these features though. I would have loved to ditch SASS and SCSS years ago.
Why don’t top and bottom `auto` margins center things?
Because our writing system is unidirectional. Documents have a direction that they flow in (typically vertical), and text within those documents is written along the other axis (typically horizontal) and wraps when it hits the edge. So in a viewport, a document has three fixed edges defined by the viewport dimensions (typically top, left, and right), with the other edge (bottom) defined by the size of the content. So…
Earlier quoted context omitted.
Vertical centering has been trivial in numerous ways for many years. At least since flexbox. This is mostly a convenience to achieve what flexbox already did, with a simpler (albeit more error prone) imposition on document structure. With that in mind, which “really weird priorities” would you have deprioritized relative to this convenience?
I don't think it's fair to dismiss something as "convenience". Convenience is very important in development, convenience is the reason we use CSS to begin with. The idea of centering an element within another is extremely basic. Something someone might want to do literally within the first 30 minutes of touching CSS for the first time and historically that person, who probably expected some evident answer instead fou…
Earlier quoted context omitted.
Doesn’t seem like that would play nice with margin collapsing, like what if you had two box elements with that style that would otherwise undergo margin collapsing, how should they render? What’s the baseline margin to combine if they should collapse and what’s the baseline margin to separate them if they shouldn’t?
Why would that be an issue? Isn't it fundamentally the same as with the horizontal centering via margin: auto for inline-blocks?
Earlier quoted context omitted.
Doesn’t seem like that would play nice with margin collapsing, like what if you had two box elements with that style that would otherwise undergo margin collapsing, how should they render? What’s the baseline margin to combine if they should collapse and what’s the baseline margin to separate them if they shouldn’t?
Just let me opt out of margin collapsing. That may be helpful if we’re dealing with paragraphs on a long piece of prose, but that’s decidedly not what I’m dealing with 95% of the time. Even with all the cool layout props we have today, it’s way too complicated to say „make this thing fill the whole screen minus the navbar at the top, make it scrollable if the content overflows and Center it vertically otherwise“. Add…
You’re right that it’s super hard to accomplish that but you have to remember it’s also hard to accomplish that in real life if you’re mathing it out. It’s easy to look at something and put something in its center (probably not accurately but convincingly enough) but to automate it is a different case, especially when the DSL for doing so 1) must handle so many other structuring features, as you noted, 2) was originally designed for structuring text documents rather than applications, as you noted, and 3) must maintain backwards compatibility so as not to break the internet.
It’s frustrating, it is. I’m not trying to say “margin collapsing takes precedence over your minute concerns!” I’m just suggesting one reason (of perhaps many reasons) why margin: auto isn’t an effective approach.
Earlier quoted context omitted.
The `scripting` @media query isn't very useful. If you want CSS that's in effect when the browser doesn't have JavaScript, you can put those styles inside . More commonly, use JavaScript itself to add or remove a class that is used within the relevant selectors. Only using JavaScript itself is potentially effective when script-blocking extensions are used rather than JavaScript not being available at all. `:has()` is…
> The `scripting` @media query isn't very useful. If you want CSS that's in effect when the browser doesn't have JavaScript, you can put those styles inside . If your styles are defined within external stylesheets, then having to extract them from their respective stylesheets and place them directly in a noscript DOM node is not very ergonomic (and it will also affect your ability to cache those styles, since they're…
Yes, there's probably been enough device performance to handle things like :has() and CSS nesting for a while. Another factor may have been IE; as long as there was a browser that wouldn't add features but still had to be supported, interest in expanding CSS spec in ways that couldn't easily rely on CSS parsers ignoring code they don't understand may have been limited.
Earlier quoted context omitted.
> The `scripting` @media query isn't very useful. If you want CSS that's in effect when the browser doesn't have JavaScript, you can put those styles inside . If your styles are defined within external stylesheets, then having to extract them from their respective stylesheets and place them directly in a noscript DOM node is not very ergonomic (and it will also affect your ability to cache those styles, since they're…
When the CSS is only to be used when JavaScript runs, I'm okay with using JavaScript to make it active. Again, the media query only does its thing when the browser says JavaScript isn't supported , if the page's JavaScript doesn't run because the .js file was blocked or there was a network issue, you get the "JavaScript styles" without the JavaScript. Yes, there's probably been enough device performance to handle thi…
I get how it works, it just feels like a hack designed to work around a missing feature, rather than the ideal way to handle the problem. Phrased another way: if the scripting media query was ubiquitous I would never go back to toggling classes via JS.
> Another factor may have been IE;
Browsers have been shipping features that don't work in IE for the better part of the last decade. If you think CSS nesting would break IE, imagine what IE would do when it encounters a modern JS feature that can't be polyfilled like Proxies.
Earlier quoted context omitted.
When the CSS is only to be used when JavaScript runs, I'm okay with using JavaScript to make it active. Again, the media query only does its thing when the browser says JavaScript isn't supported , if the page's JavaScript doesn't run because the .js file was blocked or there was a network issue, you get the "JavaScript styles" without the JavaScript. Yes, there's probably been enough device performance to handle thi…
> Again, the media query only does its thing when the browser says JavaScript isn't supported I get how it works, it just feels like a hack designed to work around a missing feature, rather than the ideal way to handle the problem. Phrased another way: if the scripting media query was ubiquitous I would never go back to toggling classes via JS. > Another factor may have been IE; Browsers have been shipping features t…
I am asserting that in the majority of cases where a person's browser is not running a page's JavaScript, it is because of a network failure or intentional blocking, neither of which can be detected by the media query.
Therefore, three years from now when the media query will be ubiquitous, it won't prevent your styles that are meant to be used only with your JavaScript from being used most of the time.
Earlier quoted context omitted.
> Again, the media query only does its thing when the browser says JavaScript isn't supported I get how it works, it just feels like a hack designed to work around a missing feature, rather than the ideal way to handle the problem. Phrased another way: if the scripting media query was ubiquitous I would never go back to toggling classes via JS. > Another factor may have been IE; Browsers have been shipping features t…
> if the scripting media query was ubiquitous I would never go back to toggling classes via JS I am asserting that in the majority of cases where a person's browser is not running a page's JavaScript, it is because of a network failure or intentional blocking, neither of which can be detected by the media query. Therefore, three years from now when the media query will be ubiquitous, it won't prevent your styles that…