The CSS Standardization Process
w3.org
w3.org
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.
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.
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.
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.
https://i.imgur.com/oJDfTOg.jpg
Maybe it needs initial-scale=1 in meta viewport? Anyone else getting this render?
Really, if you develop a standard for visual formatting, at least cover the basics.
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...
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 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.
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.
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.
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.
Here is a bit of background on why there is a need for aspect ratio:
Here you go:
you can use it in all major browsers except Safari
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..
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).
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"