5 ms·

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

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.

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.