W3C Publishes First Public Working Draft of CSS Nesting Module (w3.org) 60
koavf shares a blog post from the World Wide Web Consortium (W3C): The CSS Working Group has published a First Public Working Draft of CSS Nesting Module. This module introduces the ability to nest one style rule inside another, with the selector of the child rule relative to the selector of the parent rule. This increases the modularity and maintainability of CSS stylesheets.
Sass/less (Score:3)
Re: (Score:2)
Re: (Score:2)
curious.
when will this module be implemented in the various browsers
Re: (Score:3)
The whole point of standardization is to make sure the same wheel fits everyone's axle.
Of all the people that could invent the wheel, W3C isn't a bad pick because they're a cooperative consortium.
Re: (Score:2)
Isn't that their job?
Re:Sass/less (Score:5, Informative)
Sure, there are workarounds that let you maintain a distinct 'source' and 'compile' css.
Of course, if you don't think a website style should require a 'build' tool, then it's easy enough to see why they might want to extend CSS to cover such use cases without inflicting 'build' tools on web development. Particularly with the web developer console, technologies that can run 'live' without some build step are easier to experiment in the browser, and easier for the browser to help annotate the derivation from style rules as written by human to the appearance of an element.
Other than WASM, nothing in the browser runtime was really *supposed* to be post-build assets of things like TypeScript, Svelte, Sass, etc.
Re: (Score:2)
Comment removed (Score:4, Interesting)
Re: (Score:3)
Now if they can add some macros and basic arithmetic
Let's go all the way and have JavaScript directly in the CSS. You know we will end up there sooner or later.
Re: (Score:2)
And we'll continue to have it until we know this is actually implemented correctly in most web browsers.
But it's possible that people would move over to this once that happens, to reduce bandwidth
Of course, looking source HTML & CSS these days, most people stopped caring a long time ago, and just rely on the server to compress the file in transit, like apache's mod_deflate.
Re: (Score:3)
10 years ago people said the same about HTML5 - isn't this why we have Flash?
Aren't we glad that the browser doesn't require hacky workarounds anymore?
Re: (Score:2)
I'm not a web guy, but isn't CSS supposed to do this already? Isn't "nested" what is meant by "cascading" in Cascading Style Sheets?
No [mozilla.org].
It's the scope of rule application that cascades through several rule sources,
not the rules within a single source - with "CSS from the web server" always
being a single source, the "author stylesheets".
Re: (Score:3)
No, the "cascading" of "cascading stylesheets" is that some rules are more specific than others, and the most specific one wins conflicts. This change is basically adding a compact way of writing rules which have a lot of their specifiers in common. It can be used to set up cascades (by having one rule which applies to all foos, and then an inner rule which says "and if it's also a bar, do this instead"), but it can also be used e.g. to style a bunch of grouped items by having an outer selector for foos and
Here we go (Score:2)
Ugh (Score:3)
But dear god the syntax they used to achieve it is horrible. WTF is that ampersand about? That just makes a mess of the readability and is a surefire way to introduce errors into the rules. I bet they only did it because parsers already had some kind of selector logic so they half assed this in to work the same way to simplify extending existing parsers.
Re:Ugh (Score:5, Insightful)
I think the ampersand is there so that you can write a context-free parser for CSS. Otherwise a parser would need a potentially "infinite lookahead" to determine if an expression inside a rule block is a the beginning of a rule or a child selector. Personally I've seen syntax far worse than this in other languages (I'm looking at you, Apple, you mutant alien enemy, for calling interfaces "protocols" and unions "enums").
Overall nested rules make CSS a lot easier to read and write, and in turn, eliminate some of the need for preprocessors. Because we all know how much fun those are.
Re: (Score:1)
Yea that's what it looks like to me exactly; just something like "How can we make the JavaScript parser handle this too?"
Re: (Score:2)
It's borrowed from earlier CSS-generating projects like SASS [sass-lang.com] and Less [lesscss.org].
Re: (Score:2)
Stylus too - that ampersand is the syntax that pretty much everyone has already settled on, so it makes sense that they'd adopt the existing convention.
However, I think DrXym issue was not so much "why did they pick ampersand as the symbol?" and more "why not let us omit the ampersand when it can be inferred, as most style preprocessors already allow?".
The proposed feature is very nice as it is and, while being able to omit the ampersand would most certainly be even better, it comes with a rather heavy time
Re:Ugh (Score:5, Informative)
They have a comment about the apersand:
Why can’t everything be directly nested?
Nesting style rules naively inside of other style rules is, unfortunately, ambiguous—the syntax of a selector overlaps with the syntax of a declaration, so an implementation requires unbounded lookahead to tell whether a given bit of text is a declaration or the start of a style rule.
For example, if a parser starts by seeing color:hover ..., it can’t tell whether that’s the color property (being set to an invalid value...) or a selector for a element. It can’t even rely on looking for valid properties to tell the difference; this would cause parsing to depend on which properties the implementation supported, and could change over time.
Requiring directly-nested style rules to use nest-prefixed selectors works around this problem—an & can never be part of a declaration, so the parser can immediately tell it’s going to be parsing a selector, and thus a nested style rule.
Some non-browser implementations of nested rules do not impose this requirement. It is, in most cases, eventually possible to tell properties and selectors apart, but doing so requires unbounded lookahead in the parser; that is, the parser might have to hold onto an unknown amount of content before it can tell which way it’s supposed to be interpreting it. CSS to date requires only a small, known amount of lookahead in its parsing, which allows for more efficient parsing algorithms, so unbounded lookahead is generally considered unacceptable among browser implementations of CSS.
Re: (Score:1)
Re: (Score:3, Insightful)
As I understand it is not about "existing parsers", but the parsers that are required to be fast - i.e. browser parsers that work in real time as opposed to CSS generators like SASS or Less which are usually used offline and for which couple seconds slower or faster does not have a big difference.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
No, they set a rule-based limitation in order to permit parsers to continue to be fast, and not to need loads more memory. This affects future parsers, not present ones (which can't actually parse the ampersand)
Re: (Score:2)
Re: (Score:3)
color: red;
@nest
color: blue;
}
}
.foo {
color: red;
@nest
color: blue;
}
}
@nest is introduced such that those nesting selector expression won't be mistaken as css property name when ampersand is not at the beginning.
Re: Re-use @ symbol (Score:2)
Re: (Score:2)
WTF is that ampersand about?
Assuming this is the same as SASS, it's kind of like the "this" in OOP, or the old $_ in Perl. It's self-referential, a placeholder for itself.
(You can't retype div in place of the ampersand because that changes the nesting to "div div + p", "div div:not(#someID)", etc.)
In SASS, if you have:
div { // Same as " + p " - the ampersand is for clarity
color: red;
& + p {
color: blue;
}
&:not(#someID) {
color: green;
}
}
That outputs this CSS:
div { color
My life is complete now (Score:2)
Farewell Sass/Less
"Maintainability"? (Score:1)
This increases the modularity and maintainability of CSS stylesheets.
lol.
Re: (Score:2)
What year is this? (Score:1)
Re: (Score:2)
Is it?
DEATH TO IE3!
How about a consistent use of the vertical. (Score:4, Insightful)
I have been using CSS for nearly 20 years now, and what always bugs me, is how hard it is to deal with vertical styling.
Having an object use vertical-align, height. I often want things to be in the exact middle of stuff, things that I don't know their exact size, I would think
One would think in a control you could use something like
div.middleme { align: center; vertical-align; middle; height: 100%; }
would be a universal solution to have a div fill the screen (or the object that it is in) and have the content be right in the middle of it.
But noo. You need to either use precise measurement, or give heights to all its parents first and you might just get lucky.
Re:How about a consistent use of the vertical. (Score:4, Informative)
I can't seem to wrap my head around it at the moment well enough to explain, but it has to do with the fact that it isn't a static markup language. It re-flows based on the size of the device. A long as you're not hard-coding pixel values and doing it the proper way, you're fixed to consider all the possibilities.
If you 3 items in a container, the height of the bounding box might be the height of any one item. Or, it wraps to two rows and the height is double. You may say you've set the width of each to 33% but the parser can't make a quick judgment on how that will actually render, so it would kill performance to have it try to analyze things that way.
Anything that requires vertical alignment like you want probably requires some degree of rethinking.
Re: (Score:2)
I understand why it is hard technically to do this, however in terms of the commands giving the output you expect should be much more simple.
Re: How about a consistent use of the vertical. (Score:2)
The technical hardships probably are the reason vertical-align doesn't behave as we expect, and now that is probably possible to solve them practically, retro compatibility means vertical-align will never be "fixed".
But the vertcal align problem has been solved for a while now, with flex and align-items (or justify-content if you have flex-direction: column).
Re: (Score:2)
div.centercontent{ display:flex; align-items:center; justify-content:center; }
Or are you frustrated you have put display:flex on the parent?
Re: (Score:2)
I never said they are not was to do it. But the way CSS is natively handled. the obvious set of commands isn't used, but having to a set of additional command, or other tricks.
Re: (Score:2)
Re: (Score:2)
And if flexbox can't do it, surely grid can. These two should cover at least 95% of cases.
Re: (Score:2)
You may know more than I do about why this is bad, but generally I do:
top: 50%;
transform: translateY(-50%);
And that gives me vertical alignment. I'm not really that much into it so there's probably something broken about it, but so far it's been ok for me.
I can't wait! (Score:2)
I can't wait to use that new feature in 2041 when the majority of people will have updated their browsers!
Re: (Score:2)
huh? most browsers just auto update, even more so the mobile versions
Re: (Score:2)
Old joke from the no-auto-updating browsers era, when the W3C would announce something and it would take years before browsers added those features and even more years before the majority of people updated their browsers.
So even with auto-updating you'll need to wait until all browsers add these new features and also wait until they all work correctly.
The only thing that saves us work today is the fact that Internet Explorer doesn't exists anymore, and Safari, Chrome and Edge are basically the same engine f
Upstream WebKit is years behind (Score:2)
Safari, Chrome and Edge are basically the same engine for the most part (yes I know, Webkit is not Blink - but a huge chunk of Blink is Webkit).
Yet this huge chunk of Blink is far, far more up to date than upstream WebKit. For instance, Blink has had Push API for years and upstream still doesn't.
Re: (Score:2)
Most, but not all. Especially the ones I use. Auto-updating is one of the first things I turn off not only in a browser, but every piece of software. The last thing I want is for an update to butcher things and either render the software unusable, or remove items which were useful.
I tell the same thing to everyone that listens. Disable auto-update everywhere and you will find your experience that much better.
Also, there ar
Re: (Score:2)
yes, most, that's what I said
the rest of your post just sounds like you need somebody validate how good at computers you imagine you are, it'd be hilarious if it wasn't so sad and misguided
Features missing for years in WebKit for iOS (Score:2)
Web browsers nowadays automatically update to a newer version of the same engine. If no new version of the same engine is available, web browsers don't switch to a different engine that has the features that a particular developer used. For example, updating a web browser on iOS won't add support for the numerous web platform features missing for years in WebKit for iOS [infrequently.org].