6 ms·

The notion that this feels refreshing enough to be compelling news is a testament to how incredibly convoluted our use of browser technology has become. It's ni

by namuol 11y ago

The notion that this feels refreshing enough to be compelling news is a testament to how incredibly convoluted our use of browser technology has become. It's nice to be reminded of CSS's humbler, less-radioactive days...

nathankleyn 11y ago
I agree. The more worrying thing is that with proposals like CSS Modules, we're going even deeper down the rabbit hole with classes everywhere for everything.
- namuol 11y ago
  Perhaps, but I think we're actually on the right track. With enough tumbling down the proverbial rabbit hole, we might finally just pop up on the other side. Our tools have gotten good enough to allow us to imagine many permutations of a hypothetical future-browser, and the best ideas coming from these experimental technologies are being embraced by companies like Facebook and Google, who represent an obvious power-player in terms of spec influence. In particular the recent trend of eliminating all the global scope/cascade issues (most notably via "CSS in JS" from the React community) is a good sign that our technology is evolving -- not merely mutating.
amelius 11y ago
CSS has always been broken. For example, for many years it was impossible to vertically center an element in its parent (without extensive hacks). And still there are weird things like not being able to select all elements A which have B in them with a single CSS rule. In my opinion, the reason that web technology sucks is that the standards are being created for novices instead of for developers. If the web was a place for developers, we would have seen multiple competing replacements for CSS years ago.
- namuol 11y ago
  As a developer whose job is to deal with the ugly details of implementation, it's easy to forget the original purpose of the technology we're building. Creating something for novices (or humans, as I like to call them) is the noble thing to do. Maybe the standards committee missed the target somewhat, but their goal was to empower anyone to participate in the web. I'm getting a bit sidetracked now, but I highly recommend watching this fantastic talk by Bret Victor; it has really changed the way I think about the work I do: https://vimeo.com/115154289 https://vimeo.com/115154289
  - amelius 11y ago
    > Creating something for novices (or humans, as I like to call them) is the noble thing to do. No, the noble thing to do for a committee is to acknowledge that you (as a committee, no matter how large) don't know what is best for all people, and that there are intelligent people out there (i.e., not part of the committee) who might have more insight than you do. EDIT: Rephrased this a little because from the comments it seems this was misunderstood.
    - namuol 11y ago
      http://www.w3.org/Consortium/join http://www.w3.org/Consortium/join
      - gsnedders 11y ago
        Or just join www-style[1] or public-webapps[2], or there's the WHATWG mailing list for all of its specs[3]. All of these are totally free to join. [1]: https://lists.w3.org/Archives/Public/www-style/ https://lists.w3.org/Archives/Public/www-style/ [2]: https://lists.w3.org/Archives/Public/public-webapps/ https://lists.w3.org/Archives/Public/public-webapps/ [3]: https://whatwg.org/mailing-list#specs https://whatwg.org/mailing-list#specs
        smacktoward 11y ago
        > All of these are totally free to join. This is true, but misleading. It's true that it costs nothing to join a W3C mailing list. However, if you join such a list and actually try to participate, you rapidly discover that: 1) Making a meaningful contribution requires being able to commit enough time to shepherd that contribution through the twin gauntlets of W3C process and internal committee politics; 2) The only people who can justify committing that kind of time are people for whom doing so is their full-time job; 3) Almost all of the people whose full-time job is participating in a W3C list are browser implementers; 4) Browser implementers, unsurprisingly, tend to see the problems and concerns of browser implementers as being inherently more important than the problems and concerns of other types of stakeholders in the Web (e.g. Web developers, marketers/adtech people, privacy advocates, accessibility advocates, etc.). You generally discover this the first time you have the temerity to offer an opinion, at which point you are bombarded with responses about how you don't really understand the issue because you're not a browser implementer and have no idea how hard it is to be a browser implementer because browser implementers have it harder than anybody else in the world including lepers and orphans and seriously you have no freaking idea how anything in the world even works and bro do you even implement we didn't think so thanks for your useless opinion now go away. (Full disclosure: I may still be a little bitter from my participation in the HTML5 process.)
- alwillis 11y ago
  And still there are weird things like not being able to select all elements A which have B in them with a single CSS rule. You mean like this? :matches(A B) { color: blue; } http://www.w3.org/TR/selectors4/#matches http://www.w3.org/TR/selectors4/#matches
  - andreyvit 11y ago
    I think that, no, the point was to style elements A that happen to have B inside, while :matches will apply to elements B that are wrapped in A.

by namuol 11y ago

nathankleyn 11y ago

I agree. The more worrying thing is that with proposals like CSS Modules, we're going even deeper down the rabbit hole with classes everywhere for everything.

namuol 11y ago
Perhaps, but I think we're actually on the right track. With enough tumbling down the proverbial rabbit hole, we might finally just pop up on the other side. Our tools have gotten good enough to allow us to imagine many permutations of a hypothetical future-browser, and the best ideas coming from these experimental technologies are being embraced by companies like Facebook and Google, who represent an obvious power-player in terms of spec influence. In particular the recent trend of eliminating all the global scope/cascade issues (most notably via "CSS in JS" from the React community) is a good sign that our technology is evolving -- not merely mutating.

amelius 11y ago

CSS has always been broken. For example, for many years it was impossible to vertically center an element in its parent (without extensive hacks). And still there are weird things like not being able to select all elements A which have B in them with a single CSS rule. In my opinion, the reason that web technology sucks is that the standards are being created for novices instead of for developers. If the web was a place for developers, we would have seen multiple competing replacements for CSS years ago.

namuol 11y ago
As a developer whose job is to deal with the ugly details of implementation, it's easy to forget the original purpose of the technology we're building. Creating something for novices (or humans, as I like to call them) is the noble thing to do. Maybe the standards committee missed the target somewhat, but their goal was to empower anyone to participate in the web. I'm getting a bit sidetracked now, but I highly recommend watching this fantastic talk by Bret Victor; it has really changed the way I think about the work I do: https://vimeo.com/115154289 https://vimeo.com/115154289
- amelius 11y ago
  > Creating something for novices (or humans, as I like to call them) is the noble thing to do. No, the noble thing to do for a committee is to acknowledge that you (as a committee, no matter how large) don't know what is best for all people, and that there are intelligent people out there (i.e., not part of the committee) who might have more insight than you do. EDIT: Rephrased this a little because from the comments it seems this was misunderstood.
  - namuol 11y ago
    http://www.w3.org/Consortium/join http://www.w3.org/Consortium/join
    - gsnedders 11y ago
      Or just join www-style[1] or public-webapps[2], or there's the WHATWG mailing list for all of its specs[3]. All of these are totally free to join. [1]: https://lists.w3.org/Archives/Public/www-style/ https://lists.w3.org/Archives/Public/www-style/ [2]: https://lists.w3.org/Archives/Public/public-webapps/ https://lists.w3.org/Archives/Public/public-webapps/ [3]: https://whatwg.org/mailing-list#specs https://whatwg.org/mailing-list#specs
      - smacktoward 11y ago
        > All of these are totally free to join. This is true, but misleading. It's true that it costs nothing to join a W3C mailing list. However, if you join such a list and actually try to participate, you rapidly discover that: 1) Making a meaningful contribution requires being able to commit enough time to shepherd that contribution through the twin gauntlets of W3C process and internal committee politics; 2) The only people who can justify committing that kind of time are people for whom doing so is their full-time job; 3) Almost all of the people whose full-time job is participating in a W3C list are browser implementers; 4) Browser implementers, unsurprisingly, tend to see the problems and concerns of browser implementers as being inherently more important than the problems and concerns of other types of stakeholders in the Web (e.g. Web developers, marketers/adtech people, privacy advocates, accessibility advocates, etc.). You generally discover this the first time you have the temerity to offer an opinion, at which point you are bombarded with responses about how you don't really understand the issue because you're not a browser implementer and have no idea how hard it is to be a browser implementer because browser implementers have it harder than anybody else in the world including lepers and orphans and seriously you have no freaking idea how anything in the world even works and bro do you even implement we didn't think so thanks for your useless opinion now go away. (Full disclosure: I may still be a little bitter from my participation in the HTML5 process.)
alwillis 11y ago
And still there are weird things like not being able to select all elements A which have B in them with a single CSS rule. You mean like this? :matches(A B) { color: blue; } http://www.w3.org/TR/selectors4/#matches http://www.w3.org/TR/selectors4/#matches
- andreyvit 11y ago
  I think that, no, the point was to style elements A that happen to have B inside, while :matches will apply to elements B that are wrapped in A.