Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Incomplete List of Mistakes in the Design of CSS

wiki.csswg.org

Post reply on HN
Print view View original

101–110 of 111 posts

Re: Incomplete List of Mistakes in the Design of CSS

#101

Post by TabAtkins »

NickHaflinger wrote: post #17

Why do keywords have to end in a colon. couldn't the parser use space " " to detect the end of a word, like in C ..

I assume you mean property names, because keywords are all over the place and don't have anything to do with colons.

It's just a separator between the two semantic halves of a declaration. It could just be a space, but it wouldn't be quite as obvious. Compare "display block;" to "display:block;"

It wouldn't save characters, either - you can omit spaces around the colon today and have the same number. That is, "display block" and "display:block" are both 13 chars.

There is indeed nothing requiring a colon vs a space, as the grammar is unambiguous either way.

Re: Incomplete List of Mistakes in the Design of CSS

#102

Post by TabAtkins »

kayamon wrote: post #21

This doesn't even address the fundemantal design flaw with CSS: (paraphrased badly from a quote by Casey Muratori) Layout is about the relationship between TWO THINGS. If you have a layout language that deals with only one thing at a time, then you have failed.

CSS layout is about two things - the relationship between an element and its parent (and its siblings to a lesser extent).

It's specified in two halves: the parent lays down general dictates about how its children will be laid out (via 'display' and the layout-specific properties like 'flex-flow'), while the child responds with details about how it would like to be laid out (via width/height/etc and layout-specific properties like 'flex').

We never did end up creating a layout mode that deals in direct relationships between elements, for a number of reasons both good and bad, but that's why the CSSWG's Houdini Task Force exists - one of our deliverables is Custom Layout, so you can write JS-driven layouts that interact with the rest of CSS properly. (Today you can't without a lot of hacks, and those only get you partway there.) Custom Layout will be one of our last things to do tho, because it's the hardest, both to specify and to implement performantly (in particular, without slowing down pages that don't use Custom Layout at all, and ideally not kicking the whole page into a slow mode if one widget uses Custom Layout). So it's still a few years out - we've only got rough ideas for how the spec will work right now.

(Some of the reasons we haven't done direct "X is 10px to the left of Y" layouts: (1) CSS's syntax isn't built well for it. The rule/declaration dichotomy privileges one element, the one matched by the selector. There aren't good, reliable ways to select a unique element for the other end of the relationship. IDs aren't good, because they're page-global; everything else is too promiscuous. (2) Too easy for things to overlap in bad ways on unexpected screen sizes. Authors often develop for the computer they're on, and most don't pay much attention to screen sizes they don't own devices for. Existing CSS layout modes all degrade more-or-less gracefully, because the parent has ultimate control over where the children go and can avoid making them overlap. The exception is abspos/fixpos, which are the closest to the direct-relationship layout mode, and which can easily cause bad layout - see almost any page using position:fixed and designed for desktop, then viewed on a phone's screen. (3) It requires being extra-opinionated about how to handle cycles and such. Individual libraries do this fine (and often respond with a simple "don't write cycles"), but specifying it unambiguously and usefully is pretty hard.)

Re: Incomplete List of Mistakes in the Design of CSS

#103

Post by TabAtkins »

Turing_Machine wrote: post #3
Cshelton wrote: post #2

This doesn't even get to the overall design of css in the first place and the problems it has... http://blog.vjeux.com/2014/javascript/react-css-in-js-nation...

The whole idea of using (at least) three separate languages (HTML, JavaScript, CSS) would seem weird if it were proposed de novo . Consider that LaTeX manages to carry out all of those functions (layout, styling, and computation) using only one language.

As a very busy CSSWG member... I agree. There are a number of benefits to the current structure, but I highly suspect that if the web were invented today, styling would a JS-mediated aspect of the DOM, not something fully separate like it is today.

Re: Incomplete List of Mistakes in the Design of CSS

#104

Post by TabAtkins »

mschuster91 wrote: post #5

> Box-sizing should be border-box by default. Didn't older versions of IE do precisely that, leading to endless frustration? I hate to say it but MS did something right for once.

Yes, that's the point. ^_^ IE's "'width' sizes the border box" behavior was the better behavior. This was very early in the CSSWG's life, tho, and the group as a whole was less mature, so it didn't value back-compat and supporting actual pages as much. I wasn't around at the time, so I can't be sure of exactly why people preferred the content-box sizing model, but regardless, it was a wrong choice for compat at the time, and in hindsight, it was the wrong choice for the sizing default.

There are still reasons to size the content-box, but that's what box-sizing is for (or some equivalent mechanism).

Re: Incomplete List of Mistakes in the Design of CSS

#105

Post by TabAtkins »

alsonote wrote: post #9

> white-space: nowrap should be white-space: no-wrap and line wrapping behavior should not have been added to white-space > word-wrap/overflow-wrap should not exist. Instead, overflow-wrap should be a keyword on 'white-space', like nowrap (no-wrap) Well, which is the mistake?

Both, either. ^_^ Having wrapping behavior split the way it is today is wrong - either all of it should be in white-space, or none of it should be. (Moving it all out into a separate property is probably best, so white-space can keep just being about white-space itself.)

Re: Incomplete List of Mistakes in the Design of CSS

#106

Post by TabAtkins »

Oduig wrote: post #65

If you ask me, a layout language should have simple orthogonal concepts in it. The reason CSS gets so much hate is, in my opinion, a lack of coherence, a lack of modularity and terrible naming choices. You only have to look at vertical centering to see the problem. Situations that look almost the same require entirely different solutions, often causing a change to ripple through to parent/child/sibling elements.

Yup, that's the problem with having a language that evolved slowly over 20 years, while its problem space changed enormously. CSS was originally intended as a simple way of styling text documents on the web.

We're trying to fix vertical centering, at least. The alignment properties from the Align spec " rel="nofollow">https://drafts.csswg.org/css-align/> do consistent centering (and other alignment) across layout modes. Currently they only work in Flex and Grid, but they're defined to work in Block and Abspos as well.

Re: Incomplete List of Mistakes in the Design of CSS

#107

Post by TabAtkins »

kagamine wrote: post #72

If I had to pick a favorite it would be: > descendant combinator should have been » and indirect sibling combinator should have been ++, so there's some logical relationships among the selectors' ascii art Now, where do we stand on the omition of a parent selector? I've seen it mentioned over the years that CSS lacks an all important parent selector, eg: ul where the html would appear thus: ... This goes against the…

CSS selectors always select "down the tree". Or, read in reverse (from right to left), evaluating them only requires information from further up the tree. In HTML, "further up the tree" corresponds exactly to "earlier in the text stream". This means that as soon as an element finishes parsing, we can find all the selectors that apply to it immediately, enabling better incremental display.

Of course, that's no longer always true today. In particular, selectors like :nth-last-child() depend on information from later siblings. Defining a combinator or equivalent mechanism that allows direct selection based on later siblings is thus not out of the realm of possibility. And selecting a parent vs an earlier sibling is almost identical - the parent's start tag is immediately prior to the first sibling (or text), so the distance between "thing you're selecting" and "thing it needs to know about to evaluate the selector" is only incrementally larger. So a way of selecting a parent based on children is probably fine too.

There are a few issues that have prevented us from doing so today. For one, it's slow. Using a single one of the "backwards" sibling pseudo-classes can kick your entire page into slow-selector mode, because it breaks optimizations. The same would be true of parent selectors, probably. For two, we have to prevent nesting - siblings usually aren't too far from each other, but the root can be very far from a descendant. (Also, siblings are usually walkable by traversing an array, while parent/descendant relationships are typically pointer-based and slower to traverse.) This makes it a bit clumsy to specify.

That all said, it's on the roadmap. I plan for it show up in Selectors 5.

(Oh, and note, the "cascade" in "Cascading Style Sheets" isn't about what you're referring to. It's about a "cascade" of values for a given property colliding on a single element, and figuring out which one "wins". Thus the Cascade module " rel="nofollow">https://drafts.csswg.org/css-cascade/>. It's not the best name, but we're stuck with it. ^_^)

Re: Incomplete List of Mistakes in the Design of CSS

#108

Post by TabAtkins »

_ZeD_ wrote: post #64

it's not a css mistake, per se, but I always found difficult to reason about a way to tell "I don't really care how big this widget is, I care that this widget should be a rectangle with sizes of ratio X"; I want to be able to make a container, put a square on the top left, a 16/9 rectangle on the center and so on...

Yeah, setting an explicit aspect-ratio is on the roadmap. The relevant people (me and fantasai) have too many other layout-related things on our plate atm to deal with it, but it'll show up in the next year or two.

Re: Incomplete List of Mistakes in the Design of CSS

#109

Post by kagamine »

TabAtkins wrote: post #107
kagamine wrote: post #72

If I had to pick a favorite it would be: > descendant combinator should have been » and indirect sibling combinator should have been ++, so there's some logical relationships among the selectors' ascii art Now, where do we stand on the omition of a parent selector? I've seen it mentioned over the years that CSS lacks an all important parent selector, eg: ul where the html would appear thus: ... This goes against the…

CSS selectors always select "down the tree". Or, read in reverse (from right to left), evaluating them only requires information from further up the tree. In HTML, "further up the tree" corresponds exactly to "earlier in the text stream". This means that as soon as an element finishes parsing, we can find all the selectors that apply to it immediately, enabling better incremental display. Of course, that's no longer…

Thanks for the comprehensive reply and correction.

As I noted in my comment the area in which a parent selector would be of use was in a framework where I don't always have access to the parent tag where I could add a class or ID to the html. The way around this, because we got it fixed finally, was not to wish for a css solution but was in fact to have the authors of the framework create a fix inside the framework itself; where the limitation actually occurred. It's of little significance to you perhaps, but it is a point worth noting that the solution lay in fixing the right thing and not adding ill-advised functionality to the wrong thing.

Also, thanks to you and your collegues for your work, especially flexbox, I like CSS a lot (I know it gets a lot of criticism) and I believe it is what it should be.

Re: Incomplete List of Mistakes in the Design of CSS

#110

Post by andrewmcwatters »

TabAtkins wrote: post #99
andrewmcwatters wrote: post #35

The term "blend mode" specifically refers to color blending. It isn't just "blending" nor does the addition of the word "mode" at the end of the property indicate some sort of redundancy in the attribute name. This single slip up as an indicator of the author(s) not being familiar with a particular graphics industry term makes me question the validity of every other claim of "mistake" on the page. > rgba() and hsla()…

trolololol The term "blend mode" is a term of art in the industry, yes. But "mode" is always redundant - lots of properties switch "modes", particularly the ones with keyword values. For example, we could have had "display-mode" rather than "display", but that would definitely have been redundant. The word "blend" isn't used for anything else reasonable in CSS's wheelhouse, so using it by itself would have been fine.…

Every argument you made you counter-argued using my own points within your own post.

1. > The term "blend mode" is a term of art in the industry, yes.

2. > For example, we could have had "display-mode" rather than "display", but that would definitely have been redundant.

3. > The few exceptions are things like pre-multiplied RGBA, where the RGB components depend on the alpha. But these are rare.

Yes, because RGB isn't RGBA. If anything it should be RGBA with an optional alpha. Because you know, that's how the _structs are formed to begin with._

And separately,

> Given that the CSSWG's membership is largely browser implementors, I'm pretty sure we have a handle on what the fuck our graphics stack does.

Yes, as far as the people who actually write the portions of browser code that involve placing pixels on the screen. You however, clearly do not.

I'm not sure what you're doing in a spec committee; you don't sound like a person who has any experience writing low level code regarding these systems. Given this, it's worrying because I'd wager that you'd make uneducated decisions affecting others based on this lack of experience.

Post reply on HN