4 ms·

i really wish the standards bodies would make a concerted push for a solid advance in CSS (flexbox and css grids are pushing that way but are relatively complex

i really wish the standards bodies would make a concerted push for a solid advance in CSS (flexbox and css grids are pushing that way but are relatively complex), so that we could get rid of DIV-itis. it's like the TABLE-itis of the past, but two letters shorter (i'm exaggerating, but still...). that would not only clean up the html but make both learning and development faster. they should also really advance basic web functionality, like making contenteditable more flexible to build text editors on top of, and adding more (and more stylable) form controls (e.g., a good date-time picker, a true omni/combo box, etc). forms are all over most websites, so let's make those faster and less error prone to develop without a bunch of extraneous javascript handlers or resorting to formidable js frameworks. in short, let's keep the learning curve shallow for web development--that's what made it great in the first place.

pcwalton 9y ago
> flexbox and css grids are pushing that way but are relatively complex Can you describe a concrete solution that is less complex than flexbox while still managing to achieve its goals?
frivoal 9y ago
CSS Working group person here. We're trying. Grid (also Flexbox, but mainly grid) should be a large part of the solution, as it significantly reduces the need for divs that are just there for layout purposes. display:content should also help disconnecting your markup needs from your styling needs somewhat (go shout at browsers if it's not coming fast enough). We've also recently decided to add multiple borders, so that you don't need to add a bunch of nested divs just to have nested borders. The last piece of the puzzle would probably be to be able create boxes (or trees of boxes) without markup, and inject content from the DOM into these boxes. That would be fantastically useful, and has been explored before, but it turns out it is a really hard problem. The first attempt at this is css-regions, which ended up being rejected, in part by Google (because they thought the complexity needed for the implementation was excessive), in part by Mozilla (because they thought the design didn't fit well with how everything else works and would break in too many cases. Also, complexity). A more modest attempt has been outlined here https://drafts.csswg.org/css-overflow-4/#fragmentation https://drafts.csswg.org/css-overflow-4/#fragmentation but it is still only an early draft, and solving that isn't trivial either.
- greggman 9y ago
  the problem is css is tied to and gets it's hierarchy from the html elements. In order to truly separate style and layout from content you need a separate hierarchy and that would be a huge change https://games.greggman.com/game/css-grid-fail/ https://games.greggman.com/game/css-grid-fail/
  - akvadrako 9y ago
    You could use XSLT which was supported by Firefox and IE over 10 years ago.
  - deno 9y ago
    XML had it right with XSLT. It stands for Extensible Stylesheet Language Transformations. Because the language was clearly defined from the start for data not presentation the need for structure transformation was apparent. There’s absolutely no reason why HTML5 shouldn’t reinvent something similar. Make it much simpler, just reuse the existing Web Template spec, which simply defines new elements with slots and selectors. Example: [ was super long so I moved it: https://ipfs.io/ipfs/QmQUszZRdHfdVUZwvQL2tK12XrW54TdJJqXEkm1i7bqDkN https://ipfs.io/ipfs/QmQUszZRdHfdVUZwvQL2tK12XrW54TdJJqXEkm1... ] More complicated transformations, like the toc here (arguably not that complicated but whatever), are better handled by user Javascript. Because let’s be honest XSLT like transforms are too hard. Not immediately obvious is the fact that browsers could simply replace and rerun Javascript on page navigation, instead of rebuilding the entire page, if the templates match. There are in fact many optimizations possible with this scheme. You could mark some regions that share a template as shadow DOM etc. --- You can also provide polyfill for this TODAY using Service Workers. It’s not that crazy.

pcwalton 9y ago

> flexbox and css grids are pushing that way but are relatively complex Can you describe a concrete solution that is less complex than flexbox while still managing to achieve its goals?

frivoal 9y ago

CSS Working group person here. We're trying. Grid (also Flexbox, but mainly grid) should be a large part of the solution, as it significantly reduces the need for divs that are just there for layout purposes. display:content should also help disconnecting your markup needs from your styling needs somewhat (go shout at browsers if it's not coming fast enough). We've also recently decided to add multiple borders, so that you don't need to add a bunch of nested divs just to have nested borders. The last piece of the puzzle would probably be to be able create boxes (or trees of boxes) without markup, and inject content from the DOM into these boxes. That would be fantastically useful, and has been explored before, but it turns out it is a really hard problem. The first attempt at this is css-regions, which ended up being rejected, in part by Google (because they thought the complexity needed for the implementation was excessive), in part by Mozilla (because they thought the design didn't fit well with how everything else works and would break in too many cases. Also, complexity). A more modest attempt has been outlined here https://drafts.csswg.org/css-overflow-4/#fragmentation https://drafts.csswg.org/css-overflow-4/#fragmentation but it is still only an early draft, and solving that isn't trivial either.

greggman 9y ago
the problem is css is tied to and gets it's hierarchy from the html elements. In order to truly separate style and layout from content you need a separate hierarchy and that would be a huge change https://games.greggman.com/game/css-grid-fail/ https://games.greggman.com/game/css-grid-fail/
- akvadrako 9y ago
  You could use XSLT which was supported by Firefox and IE over 10 years ago.
- deno 9y ago
  XML had it right with XSLT. It stands for Extensible Stylesheet Language Transformations. Because the language was clearly defined from the start for data not presentation the need for structure transformation was apparent. There’s absolutely no reason why HTML5 shouldn’t reinvent something similar. Make it much simpler, just reuse the existing Web Template spec, which simply defines new elements with slots and selectors. Example: [ was super long so I moved it: https://ipfs.io/ipfs/QmQUszZRdHfdVUZwvQL2tK12XrW54TdJJqXEkm1i7bqDkN https://ipfs.io/ipfs/QmQUszZRdHfdVUZwvQL2tK12XrW54TdJJqXEkm1... ] More complicated transformations, like the toc here (arguably not that complicated but whatever), are better handled by user Javascript. Because let’s be honest XSLT like transforms are too hard. Not immediately obvious is the fact that browsers could simply replace and rerun Javascript on page navigation, instead of rebuilding the entire page, if the templates match. There are in fact many optimizations possible with this scheme. You could mark some regions that share a template as shadow DOM etc. --- You can also provide polyfill for this TODAY using Service Workers. It’s not that crazy.