
The CSS Standardization Process - zackhsi
https://www.w3.org/Style/2011/CSS-process.en.html
======
brownbat
"Later we also discovered that people didn't want to replace CSS and rather
wanted to make it bigger."

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.

~~~
iratewizard
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.

~~~
tobr
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.

~~~
RobertRoberts
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.

~~~
tobr
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.

------
nessunodoro
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](https://i.imgur.com/oJDfTOg.jpg)

Maybe it needs initial-scale=1 in meta viewport? Anyone else getting this
render?

------
amelius
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.

~~~
onion2k
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...

~~~
amelius
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.

~~~
onion2k
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.

~~~
amelius
> 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.

~~~
onion2k
_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.

~~~
amelius
> 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.

------
_jstreet
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..

~~~
sradman
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).

------
djxfade
I find it a bit ironic that the page isn't being rendered correctly on Safari
14

------
pers0n
Typography still has a long way to go. Generating a proper baseline rhythm
easily would be nice

------
tannhaeuser
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....](https://lmeyerov.github.io/projects/pbrowser/pubfiles/paper.pdf)

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).

~~~
felixfbecker
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

~~~
corty
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.

~~~
RobertRoberts
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)

~~~
corty
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"

