5 ms·

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

by kayamon 11y ago

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.

hayksaakian 11y ago
Html is tree structures right? Every element is default positioned relative to the previous element.
- kayamon 11y ago
  Uh, yes, I guess? That by itself is not especially useful. That's not what a layout language is for. A layout language needs to be able to specify "A goes 10 px to the left of B".
- est 11y ago
  Unless if you think about it, layout is positioned in a 2D plane (with z-index, it's a 3D space, don't mention time), not a tree structure at all.
  - applecore 11y ago
    Except a tree structure is the only conceptual model that works for composing a user interface (out of simple, largely stateless components). See, for example, React and JSX.
- wavefunction 11y ago
  default is "statically," if I may be so <strong>
epidemian 11y ago
On a similar note, i think this Bret Victor quote captures the frustration of the CSS experience very well: "CSS, a language for specifying visual appearance on the web, is … so complex that it has never been implemented correctly; yet, successive versions specify even more complexity. At the same time, it is so underpowered that many elementary graphic designs are impossible or prohibitively difficult, and context-sensitivity (or anything computational) must be addressed externally. Most CSS lore is dedicated to describing the tangles of brittle hacks needed to circumvent incompatibilities or approximate a desired appearance." http://worrydream.com/MagicInk/#p255 http://worrydream.com/MagicInk/#p255
antod 11y ago
> This doesn't even address the fundemantal design flaw with CSS I don't think CSS layout issues could be described as a 'fundamental design flaw'. CSS originally didn't really address layout at all - it was about styling the content of documents. IMO it's a stretch to say layout was 'fundamental' to CSS. The fundamental parts of CSS are the way multiple styles from multiple places are inherited down a nested tree structure and applied or overridden based on their specificity. For it's time and the constraints it had to work with (ie preexisting HTML handling the structure), I think it was an elegant solution at heart. Especially when looking at it on context of the problems it was solving. Sure the world moved on and demanded more and more from CSS with little help from popular browsers, but that all came later on as the web exploded. > 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. Why do you think CSS only deals with one thing at a time? CSS is all about how the element behaves in relation to it's relatives (eg parents and siblings etc as defined by the HTML). But it is about matching rules against the existing document structure rather than defining the document structure.
olavk 11y ago
Can you elaborate? Why only two things?
- kayamon 11y ago
  Well not _only_ two things, but the idea is that you need to specify _relationships_ between objects. You can't do that by just considering each object in isolation. - "A goes TO THE LEFT of B" - "The header goes ABOVE the content" - "The list goes INSIDE the table" - "The menu goes BEFORE the advert" You could try and combine more than two objects together in a single rule, but it's obviously easier to specify the rules one pair at a time. A layout language without prepositions isn't much of a layout language at all.
TabAtkins 11y ago
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.)

by kayamon 11y ago

hayksaakian 11y ago

Html is tree structures right? Every element is default positioned relative to the previous element.

kayamon 11y ago
Uh, yes, I guess? That by itself is not especially useful. That's not what a layout language is for. A layout language needs to be able to specify "A goes 10 px to the left of B".
est 11y ago
Unless if you think about it, layout is positioned in a 2D plane (with z-index, it's a 3D space, don't mention time), not a tree structure at all.
- applecore 11y ago
  Except a tree structure is the only conceptual model that works for composing a user interface (out of simple, largely stateless components). See, for example, React and JSX.
wavefunction 11y ago
default is "statically," if I may be so <strong>

epidemian 11y ago

On a similar note, i think this Bret Victor quote captures the frustration of the CSS experience very well: "CSS, a language for specifying visual appearance on the web, is … so complex that it has never been implemented correctly; yet, successive versions specify even more complexity. At the same time, it is so underpowered that many elementary graphic designs are impossible or prohibitively difficult, and context-sensitivity (or anything computational) must be addressed externally. Most CSS lore is dedicated to describing the tangles of brittle hacks needed to circumvent incompatibilities or approximate a desired appearance." http://worrydream.com/MagicInk/#p255 http://worrydream.com/MagicInk/#p255

antod 11y ago

> This doesn't even address the fundemantal design flaw with CSS I don't think CSS layout issues could be described as a 'fundamental design flaw'. CSS originally didn't really address layout at all - it was about styling the content of documents. IMO it's a stretch to say layout was 'fundamental' to CSS. The fundamental parts of CSS are the way multiple styles from multiple places are inherited down a nested tree structure and applied or overridden based on their specificity. For it's time and the constraints it had to work with (ie preexisting HTML handling the structure), I think it was an elegant solution at heart. Especially when looking at it on context of the problems it was solving. Sure the world moved on and demanded more and more from CSS with little help from popular browsers, but that all came later on as the web exploded. > 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. Why do you think CSS only deals with one thing at a time? CSS is all about how the element behaves in relation to it's relatives (eg parents and siblings etc as defined by the HTML). But it is about matching rules against the existing document structure rather than defining the document structure.

olavk 11y ago

Can you elaborate? Why only two things?

kayamon 11y ago
Well not _only_ two things, but the idea is that you need to specify _relationships_ between objects. You can't do that by just considering each object in isolation. - "A goes TO THE LEFT of B" - "The header goes ABOVE the content" - "The list goes INSIDE the table" - "The menu goes BEFORE the advert" You could try and combine more than two objects together in a single rule, but it's obviously easier to specify the rules one pair at a time. A layout language without prepositions isn't much of a layout language at all.

TabAtkins 11y ago

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