CSS layers are completely unintuitive to work with. I really don't see the use case for them. I hoped to isolate Telerik styling with it but it only made it harder to override styling.
Old dogs, new CSS tricks
91–100 of 108 posts
Re: Old dogs, new CSS tricks
#92If you want to use nesting, for example, you will have to give up Windows < 10 and iOS < 17.2. It's a big ask for some sites.
You don’t. Safari has supported CSS nesting since v16.5. The specification was updated to remove the earlier requirement to use & though, and support for that was introduced in v17.2. As long as you include the &, you can support everything back to v16.5. Not sure what you are referring to regarding Windows If you do need to support browsers that don’t understand CSS nesting, use PostCSS or Lightning CSS. They will t…
If you want to use the normal non-& syntax, then you will need to use Safari 17.2, yes.
I am referring to the fact that there are no browsers with native CSS nesting that support Windows < 10.
Re: Old dogs, new CSS tricks
#93> Quick question: how many of these have you actively used in production? > Container Queries They aren't useful yet because: 1. Using them requires a wrapper element which can dirty up the HTML 2. While we were waiting for container queries to arrive, we also got new rules that made fluid layouts easier to implement which handle a chunk of container queries use cases. Container queries will become more useful when e…
:has isn't available in Firefox ESR (115) yet. The next ESR (128) will trickle out between July and October. @property (not mentioned) is only in Firefox Nightly; hopefully it makes it for 128 ...
Only enterprises are going to care about ESR editions, so they're likely already using older code. Any time they are going to need something like :has, they're probably going to achieve it with js anyway.
@property will be nice, but almost every initial use-case will be animation related. That said, I'm happy it's reaching baseline support since more powerful features can be built on top of it.
Re: Old dogs, new CSS tricks
#94> Quick question: how many of these have you actively used in production? > Container Queries I haven't used this, but it looks super useful. > Style Queries Eh, I'm sure this is useful for situations that don't come up very often. > CSS Layers Ugh, I'm not going to use this overly-complex silliness, and I'm not looking forward to debugging this when other people use this. > Subgrid Again, overly complex. Grid could…
> But I might be willing to make an exception for people who write CSS that requires you to read the MDN article on Specificity to understand it. May I ask you, are you a front-end developer?
Full stack. Typically Django+React, using React as a component library not an SPA framework. But I've worked on stacks that deviate from that pretty significantly in the not-too-distant past.
Re: Old dogs, new CSS tricks
#95Earlier quoted context omitted.
Is there a Chrome LTS channel? Firefox has an LTS version which can be a baseline for features, but which receives security updates at the very least. I don't know about, say, Chrome 80 line that would receive security fixes but not new features. I also think that would be against Google's interests to have such an LTS line, it would decrease the moat between it an other browsers.
Why do you need Chrom LTS to use "a separate stylesheet to support everyone."?
Because supporting older Chrome releases is pointless: they should be replaced because of their security holes, discovered later. You may, of course, to decide to put the baseline somewhere, but that baseline would be arbitrary.
With Firefox (ESRs are at 102 and even 52) and, to an extent, Safari (tied to iOS releases) there are non-arbitrary baselines, where you know what kind and size of the audience you additionally cover by staying away from newer features.
Re: Old dogs, new CSS tricks
#96For me personally, it's because I've been burned too many times by blog posts announcing that "feature X is here!", when in reality, it's only here in Chrome or behind a feature flag, or the exciting parts haven't been implemented yet. Even this blog post falls into the same trap. There isn't good cross-browser support for view transitions or anchor positioning, and yet they're listed as here now.
View transitions are the perfect candidate progressive enhancement. If the browser supports it, then the user will get the rich animations. If it doesn’t, then they get what they currently have. And once other browsers starts supporting it, the experience will automatically work in those browsers too without you needing to touch a single line of code :)
> View transitions are the perfect candidate progressive enhancement.
Quite the opposite. The alternative to "no view transitions" isn't "clunky hard-refresh page-by-page experience," it's single-page view transitions orchestrated by JavaScript (instead of by Chrome). View transitions require you to fundamentally change the architecture of not just a page, but your entire website/app.
Re: Old dogs, new CSS tricks
#97Earlier quoted context omitted.
Why do you need Chrom LTS to use "a separate stylesheet to support everyone."?
Because supporting older Chrome releases is pointless: they should be replaced because of their security holes, discovered later. You may, of course, to decide to put the baseline somewhere, but that baseline would be arbitrary. With Firefox (ESRs are at 102 and even 52) and, to an extent, Safari (tied to iOS releases) there are non-arbitrary baselines, where you know what kind and size of the audience you additional…
They point is the same for Chrome - "should" is a wish, not a description of reality, so if you care about users using old versions, you use a fallback method.
Also don't you have stats by version number, what is extra non-arbitrary about LTS?
Re: Old dogs, new CSS tricks
#98Earlier quoted context omitted.
After having seen a11y written about 100x times in Svelte warnings, it's finally dawned on me that it means accessibility, which is somewhat ironic that I had no idea what it meant all those times before.
Please don't take this the wrong way, but can I ask how you personally find answers to similar solutions when they come up in your work/personal life? The first thing I do when I see an acronym or word I don't understand is go to Google and type `what is a11y webdev` or whatever. I think you get the idea. This has been a part of my life for almost 2 decades now so I'm curious how others handle the situation! What mad…
I would normally do something similar. The context in which I was seeing these warnings was that I was working on a new UI for a VST plugin using web front-end tech, something novel for me so I was more interested in getting it to work before dealing with what the warnings meant.
It was the parent comment mentioning a11y and screen-reader in conjunction that made me make the connection, I just found it hilarious that the term a11y itself is so inaccessible if you don't already know what it means!
Re: Old dogs, new CSS tricks
#99Earlier quoted context omitted.
You don’t. Safari has supported CSS nesting since v16.5. The specification was updated to remove the earlier requirement to use & though, and support for that was introduced in v17.2. As long as you include the &, you can support everything back to v16.5. Not sure what you are referring to regarding Windows If you do need to support browsers that don’t understand CSS nesting, use PostCSS or Lightning CSS. They will t…
If you want to use the normal non-& syntax, then you will need to use Safari 17.2, yes. I am referring to the fact that there are no browsers with native CSS nesting that support Windows < 10.
> If you want to use the normal non-& syntax, then you will need to use Safari 17.2, yes.
Non-& is not “the normal syntax”. It was a late addition to the specification. Both with and without & are normal, but with & has better compatibility.
Even if you don’t use the &, you can still write nested CSS and support older versions of Safari, like I said. Use PostCSS or Lightning CSS. There are normally several areas where you can start writing modern CSS today and fill in the backwards compatibility with these tools. It’s not just nesting.
Re: Old dogs, new CSS tricks
#100Earlier quoted context omitted.
CSS needs a compiler with warnings, dead-code removal, type safety, modularization, standard structuring and "design patterns" - then software engineers will take it seriously.
We do have tools for that though, how would a build tool fit into a language specification? Aren't those different concerns?
Dead CSS code should ideally be a warning on the web platform. This should be in the spec. Browser can probably emit a warning in the console log if there are CSS selectors that are not used. Authors can choose to explicitly mark with a `ignore-unused`, delete them or move such selectors to separate style-sheets that are loaded by the pages that actually use them. With HTTP/3 this makes more sense (CSS modularization) rather than one single massive CSS for the whole site that just keeps growing over time.