The CSS Standardization Process(w3.org)
w3.org
The CSS Standardization Process
https://www.w3.org/Style/2011/CSS-process.en.html
28 comments
I've used advanced CSS nonstop for the last 15 years as a design specialist. I do love CSS and how it has grown. I really can't say I have any complaints, and much of what I do when converting my prototypes to layout is a process of intuition.
With the important thing, it's a matter of specificity. I've gotten in the habit of thinking about styles in layers of abstraction. When I'm working in a high level of abstraction, I keep it to a tag or a class. As I go lower down I add standard levels of specificity so the importance level changes (because 'div .class' will be inherited over '.class' every time). Class naming conventions help this too. If I know I'm overwriting an existing style, I often copy the existing style's rule exactly and just add 'html ' or 'div ' to the start of the rule out of habit.
With the important thing, it's a matter of specificity. I've gotten in the habit of thinking about styles in layers of abstraction. When I'm working in a high level of abstraction, I keep it to a tag or a class. As I go lower down I add standard levels of specificity so the importance level changes (because 'div .class' will be inherited over '.class' every time). Class naming conventions help this too. If I know I'm overwriting an existing style, I often copy the existing style's rule exactly and just add 'html ' or 'div ' to the start of the rule out of habit.
Genuinely reassuring to hear.
Really didn't want to toe the line into code wars too much, I'm sure there are some features of css that are the result of difficult tradeoffs and hard won lessons over the years, and I know I haven't spent enough time with it.
I think for me, I naturally gravitate towards an atomic, functional style where no segment of code knows anything about the rest of the program. Working in "inheritance is everything" mode was a sort of mindscrew, but maybe healthy for me in the long run.
Really didn't want to toe the line into code wars too much, I'm sure there are some features of css that are the result of difficult tradeoffs and hard won lessons over the years, and I know I haven't spent enough time with it.
I think for me, I naturally gravitate towards an atomic, functional style where no segment of code knows anything about the rest of the program. Working in "inheritance is everything" mode was a sort of mindscrew, but maybe healthy for me in the long run.
I’ve also been writing CSS for about 15 years, and I have endless complaints. I think the provisions for maintaining and composing styles are just really lacking out of the box. It’s better with the recent addition of calc and var, but even those feel strange, underpowered and bug-prone. This is aside from complaints about the many overlapping, poorly-designed layout systems that interact in baffling ways, and the mindless profusion of syntax variations.
So are your "endless complaints" about web designing documents or applications? (curious to update my experience database with your response)
I think CSS was designed for documents and not apps. And almost all the real difficulties I have with CSS (and all the ones I hear from others) is with application development, not web design per se.
CSS is my favorite coding "language", but I have always been an artist & coder.
I think CSS was designed for documents and not apps. And almost all the real difficulties I have with CSS (and all the ones I hear from others) is with application development, not web design per se.
CSS is my favorite coding "language", but I have always been an artist & coder.
I think it’s worse for apps than document-based websites, but the border between those are fuzzy to me. I’ve certainly run into problems with both.
You nailed the problem. It's hard to compose css without resorting to what feels like a hack. @mixins and @appliers should have been part of the css years ago.
SM-J700T (June 2015), Android 7.1.1 Firefox 68.4.2, 720x1280, minimum screen zoom and font size in settings
https://i.imgur.com/oJDfTOg.jpg
Maybe it needs initial-scale=1 in meta viewport? Anyone else getting this render?
https://i.imgur.com/oJDfTOg.jpg
Maybe it needs initial-scale=1 in meta viewport? Anyone else getting this render?
When will we finally get a way to fix the aspect ratio of a div in a straightforward way?
Really, if you develop a standard for visual formatting, at least cover the basics.
Really, if you develop a standard for visual formatting, at least cover the basics.
I don't quite understand the issue with aspect ratio. I know there isn't a way to define it well yet, but people have been building websites for almost 30 years without a way to specify it, and now all of a sudden everyone claims to need it. It's weird.
I hope it's just evidence that CSS layout has improved to the point where 95% of the problems are effectively solved by flexbox and grid, and the upcoming subgrid, so now there's the edge cases left. Aspect ratio certainly seems to come up a lot though...
I hope it's just evidence that CSS layout has improved to the point where 95% of the problems are effectively solved by flexbox and grid, and the upcoming subgrid, so now there's the edge cases left. Aspect ratio certainly seems to come up a lot though...
> I don't quite understand the issue with aspect ratio. I know there isn't a way to define it well yet, but people have been building websites for almost 30 years without a way to specify it, and now all of a sudden everyone claims to need it. It's weird.
Here is a bit of background on why there is a need for aspect ratio:
https://youtu.be/AQqFZ5t8uNc?t=233
Here is a bit of background on why there is a need for aspect ratio:
https://youtu.be/AQqFZ5t8uNc?t=233
The problem with stating why "aspect ratio" is a useful concept is that people will give ways to work around it, which would totally miss the point.
This article is about the CSS standardization process, which has left much to desire. For example, it took ages before we could properly align things against the bottom of the page without hacks. The functionality of grid and flexbox has been present in TeX and most GUI tools from day 1, but somehow it took CSS more than a decade to even consider them.
This article is about the CSS standardization process, which has left much to desire. For example, it took ages before we could properly align things against the bottom of the page without hacks. The functionality of grid and flexbox has been present in TeX and most GUI tools from day 1, but somehow it took CSS more than a decade to even consider them.
The web had, and to an extent still has, a problem with no one really knowing what it's supposed to be for. A lot of people think it's for documents. And not even documents in the print sense, but "documents" as in a stream of content to be shared between computers. The early web was all about the content and how it was moved around, and very little about what it looked like. Why bother adding the ability to control how things align things to the bottom of the page if the point is simply to stream text on to a screen for someone to read the content?
The reason those things are in TeX is because Knuth was replacing typesetting for his book. He added what he needed. Browser developers did the same thing for webpages, and no one really needed to align things to the bottom of the page.
The reason those things are in TeX is because Knuth was replacing typesetting for his book. He added what he needed. Browser developers did the same thing for webpages, and no one really needed to align things to the bottom of the page.
> Why bother adding the ability to control how things align things to the bottom of the page if the point is simply to stream text on to a screen for someone to read the content?
If the point was simply to stream text on to a screen for someone to read, we wouldn't need CSS to begin with.
> and no one really needed to align things to the bottom of the page.
Documents have footers. Most company webpages have useful information in their footers. I think it is reasonable that a web formatting spec offers the tools to properly format these footers. And formatting a footer is not as simple as just "adding text at the end of the content". Yet, it is also not very difficult to specify how it should properly work.
This is just another example to illustrate that the CSS standardization process has been hopelessly lagging for very straightforward use-cases.
If the point was simply to stream text on to a screen for someone to read, we wouldn't need CSS to begin with.
> and no one really needed to align things to the bottom of the page.
Documents have footers. Most company webpages have useful information in their footers. I think it is reasonable that a web formatting spec offers the tools to properly format these footers. And formatting a footer is not as simple as just "adding text at the end of the content". Yet, it is also not very difficult to specify how it should properly work.
This is just another example to illustrate that the CSS standardization process has been hopelessly lagging for very straightforward use-cases.
Yet, it is also not very difficult to specify how it should properly work.
Should a footer align to the bottom of the content or the viewport or should it be sticky? Should I be able to continue content after the footer? What happens if I have a second footer element? Should the footer create a new section in the document outline? Should it display inline or as a block element? What should be the default behaviour if I print a page with a footer? Is the footer of a document the same as a footer on a website, and is that the same as the footer on a web app?
These are easy questions I can think of in 30 seconds. No doubt there are some much more complex issues too. The idea that defining a footer element for HTML is easy is nonsense.
As it is, HTML5 has had a <footer> tag for years, and it doesn't do what a document footer does. HTML5 added <header>, <main>, <section>, <aside> and more. None of them do what TeX does.
Should a footer align to the bottom of the content or the viewport or should it be sticky? Should I be able to continue content after the footer? What happens if I have a second footer element? Should the footer create a new section in the document outline? Should it display inline or as a block element? What should be the default behaviour if I print a page with a footer? Is the footer of a document the same as a footer on a website, and is that the same as the footer on a web app?
These are easy questions I can think of in 30 seconds. No doubt there are some much more complex issues too. The idea that defining a footer element for HTML is easy is nonsense.
As it is, HTML5 has had a <footer> tag for years, and it doesn't do what a document footer does. HTML5 added <header>, <main>, <section>, <aside> and more. None of them do what TeX does.
> Should ...
I just wish the CSS committee asked themselves these questions ... Like I said, it's more involved than you would expect, but on the other hand it's not rocket science, really.
I just wish the CSS committee asked themselves these questions ... Like I said, it's more involved than you would expect, but on the other hand it's not rocket science, really.
> When will we finally get a way to fix the aspect ratio of a div in a straightforward way?
Here you go:
https://css-tricks.com/a-first-look-at-aspect-ratio/
Here you go:
https://css-tricks.com/a-first-look-at-aspect-ratio/
lucky for you it's finally in the CSS draft proposal now
https://drafts.csswg.org/css-sizing-4/#ratios
you can use it in all major browsers except Safari
you can use it in all major browsers except Safari
Can we get "2011" added to the title?
I think it'd be interesting to know how the process described has evolved/progress in the last ~9 years; is it still much the same? To give some context, CSS3 was "released" around 2011.
> the standard part is slowly growing, the part still in development has been growing as well, but should eventually diminish.
I'm also curious about this, the article seems to suggest that new features would become more standard several years ago..
I think it'd be interesting to know how the process described has evolved/progress in the last ~9 years; is it still much the same? To give some context, CSS3 was "released" around 2011.
> the standard part is slowly growing, the part still in development has been growing as well, but should eventually diminish.
I'm also curious about this, the article seems to suggest that new features would become more standard several years ago..
The URL has /2011/ but the page footer says "LAST UPDATED TUE 18 FEB 2020". This looks like a living document that cements the past decisions applied to all documents in the [sub-]site (e.g. URL/information structure, <div> vs. Semantic HTML5, etc).
Typography still has a long way to go. Generating a proper baseline rhythm easily would be nice
I guess the lack of comments could be interpreted as uneasy silence considering TFA is about justifying the bureaucratics of a "process" that never comes to an end, never produces a coherent final result, and puts sustained access to the digital information of two or more generations at risk.
Maybe someone should tell W3C it's time to come to an end with CSS standardization (with only one and a half implementation left). If they feel like there's not much anything more to do after 25 years of job security by inventing a thousand microsyntaxes, maybe they could start cleaning up their mess and provide profiles and formal specifications for at least core CSS specs such that, you know, coming generations will want to even consider maintaining their stuff. The precious few attempts at a formal semantics for even basic CSS box layout are certainly discouraging:
> Even for a seemingly simple language like [ours covering a fragment of the CSS box layout model], we see scenarios where constraints have a surprising or even undefined interpretation in the CSS standard and browser implementations [1]
[1]: https://lmeyerov.github.io/projects/pbrowser/pubfiles/paper....
But maybe CSS is a lost cause at this point. I'm certainly more than open to a more formal (constraint-based or whatever) spec that covers significant portions of CSS (like GSS which seems abandoned however).
Maybe someone should tell W3C it's time to come to an end with CSS standardization (with only one and a half implementation left). If they feel like there's not much anything more to do after 25 years of job security by inventing a thousand microsyntaxes, maybe they could start cleaning up their mess and provide profiles and formal specifications for at least core CSS specs such that, you know, coming generations will want to even consider maintaining their stuff. The precious few attempts at a formal semantics for even basic CSS box layout are certainly discouraging:
> Even for a seemingly simple language like [ours covering a fragment of the CSS box layout model], we see scenarios where constraints have a surprising or even undefined interpretation in the CSS standard and browser implementations [1]
[1]: https://lmeyerov.github.io/projects/pbrowser/pubfiles/paper....
But maybe CSS is a lost cause at this point. I'm certainly more than open to a more formal (constraint-based or whatever) spec that covers significant portions of CSS (like GSS which seems abandoned however).
Never comes to an end and produces coherent final results? CSS grid and CSS flexbox are some of the most powerful, most thought-through layout systems I’ve ever seen
flexbox and grid are a poor copy of Qt layouts. They are better than anything previous on the web, but thats not a high hurdle.
I have never used Qt, can you give a rough outline/commentary on what Qt does right? (it's been decades since I've worked with a gui library that is non-web based)
Well, the general idea is similar to what CSS has at the moment with grid and flexbox. You get containers with configurablr automatic widget distribution and reflow that you can nest.
The difference is that in Qt, there are no such weirdnesses as widgets painting outside their container, broken scrollbars on resize, unwanted scrollbars, etc. Corner cases such as min and max size are more configurable and less broken.
Overall, I also think that Qt looks more like a proper design overall, thinks have been designed together to work together. CSS feels like it has grown and festered into its current state between "works fine" and "uh, thats weird"
The difference is that in Qt, there are no such weirdnesses as widgets painting outside their container, broken scrollbars on resize, unwanted scrollbars, etc. Corner cases such as min and max size are more configurable and less broken.
Overall, I also think that Qt looks more like a proper design overall, thinks have been designed together to work together. CSS feels like it has grown and festered into its current state between "works fine" and "uh, thats weird"
Ha.
Just finally got around to using css in something and it felt like the opposite of PEP 20.
I hope it gets better over time. Maybe you eventually get more of a feel for things like why svg behaves differently from all other images (except when the contents of the file tell it not to), or tracing where your inherited styles come from, or nothing you write being "important" unless you tag it that way, or figuring out how to make something dynamic and responsive but only relative to a series of independent constraints.
I'm sure there are masters of css who have grown to love it. And it seems like there are some good patterns emerging, grid is great. Overall though, I found the experience painful and bewildering. Maybe I'm just uniquely unsuited for that work, but I hope layout gets its Van Rossum or a "css for humans" movement someday.