5 ms·

I don't think the problem is that CSS is an unnecessary approach to the problem of layout. It is more that it is a poor approach to the problem of layout. A l

by Lerc 12y ago

I don't think the problem is that CSS is an unnecessary approach to the problem of layout. It is more that it is a poor approach to the problem of layout. A layout language is unnecessary given a bytcode VM a chunk of memory, code, and an output. The balance is in capability, performance, and understanding. I have done a lot of CSS wrangling which has given me plenty of time to consider what 'a better way' could be. I doubt I'm alone in that respect. CSS has three parts. Properties, selectors, and values. When someone is talking about how awesome CSS is they have usually done something clever with selectors. When someone is ranting about getting CSS to work right, they are usually trying to figure out what set of values to put into properties. The properties themselves are insane. The legacy of incremental development and serving many masters. The options for values are limited. attr() would help my own usage a great deal but Firefox doesn't support it (see here someone complaining in 2011 that they've fallen behind Internet Explorer on this https://bugzilla.mozilla.org/show_bug.cgi?id=435426#c3 https://bugzilla.mozilla.org/show_bug.cgi?id=435426#c3). Actually Properties, values and Selectors are all limited. Selectors are just the least weakest link. Properties could do with a complete breaking overhall (ie. If a document is in doubleplusgoodCSS mode it only supports the new style properties). property values should be the results of expressions in a pure functional language. Selectors should be another expression system with operators and member-check functions, the selector system is close to what it needs to be already. Just a mechanism for user defined groupings (such as attributeContainsPrimeNumberAsHex("class")) and combinators.

MrBuddyCasino 12y ago
I fully agree with your distinction of selectors, properties and values - not all parts of CSS are bad. When you say "property values should be the results of expressions in a pure functional language" - which I think is a great idea - do you mean to use them to compute layout as well?
- Lerc 12y ago
  When I posted that comment My view was that layout would still be primarily driven by higher level style properties, but after I posted I though about it some more and I realized if done properly you could probably the css value language could theoretically do it all. If it were to generate values for the complete layout, bypassing the higher level layer, effectively telling the display engine that everything was absolutely positioned and in the right place already. I don't think I would advocate for that to be the standard way to implement layout, but it should be at least possible. Similarly I think the system should be capable of specifying a table where each cell has a background colour corresponding to its position in a Mandelbrot set. I don't think people should be doing that normally either, but I certainly think it should be something that is capable.
marcosdumay 12y ago
I see where you are getting into... But not pure, please, but reactive. One creates events on HTML and Javascript (there are a few by default), CSS filters, maps, and uses them.
- Lerc 12y ago
  The part of the system I was talking about would be a static component beneath the level of scripting and events. At that level the document can be considered a static snapshot of the state. The evaluation of each of the property values would be single expressions that could draw upon the state as input and produce style properties as a result. There should be no lifetime of the execution beyond that single evaluation. As an implementation detail, this would be extremely amenable to parralelism and memoization. to make things perform well. Even though you have things like :hover and transitions in a document that can dramatically change what you see onscreen, the Document itself is unchanging. Think of it as a many-dimentional thing. Nothing changes when you hover over an element, but your rendered viewpoint is now drawing the space in which :hover is true. Scripts are things that can potentially change the Document itself. Events are things that happen related to the viewpoint renderer. it would be entirely possible to define something at a lower level to indicate that an event is capable of occurring via the styling mechanism, but what actually happens would be up to the viewpoint renderer. Consider the case of an event occurring on the end of a transition. The triggering mechanism is the viewpoint finishing the transition, and it is up to the engine driving the viewpoint to trigger the event. The styling behaviour would merely indicate that a transition would be requested on certain elements.
  - marcosdumay 12y ago
    Looks like we are almost in agreement, except that I see no reason to separate event handling from the overall style description. Of course, modifying the document is out of the scope of styling rules, events handlers on that level must change only styling, nothing else. What events bring (besides generalizing the :hover-like pseudo-selectors into something more powerfull) is better separation of concerns. Instead of your Javascript touching several elements styles, it generates an event, and you describe how to handle it at the styling sheet.

by Lerc 12y ago

MrBuddyCasino 12y ago

I fully agree with your distinction of selectors, properties and values - not all parts of CSS are bad. When you say "property values should be the results of expressions in a pure functional language" - which I think is a great idea - do you mean to use them to compute layout as well?

Lerc 12y ago
When I posted that comment My view was that layout would still be primarily driven by higher level style properties, but after I posted I though about it some more and I realized if done properly you could probably the css value language could theoretically do it all. If it were to generate values for the complete layout, bypassing the higher level layer, effectively telling the display engine that everything was absolutely positioned and in the right place already. I don't think I would advocate for that to be the standard way to implement layout, but it should be at least possible. Similarly I think the system should be capable of specifying a table where each cell has a background colour corresponding to its position in a Mandelbrot set. I don't think people should be doing that normally either, but I certainly think it should be something that is capable.

marcosdumay 12y ago

I see where you are getting into... But not pure, please, but reactive. One creates events on HTML and Javascript (there are a few by default), CSS filters, maps, and uses them.

Lerc 12y ago
The part of the system I was talking about would be a static component beneath the level of scripting and events. At that level the document can be considered a static snapshot of the state. The evaluation of each of the property values would be single expressions that could draw upon the state as input and produce style properties as a result. There should be no lifetime of the execution beyond that single evaluation. As an implementation detail, this would be extremely amenable to parralelism and memoization. to make things perform well. Even though you have things like :hover and transitions in a document that can dramatically change what you see onscreen, the Document itself is unchanging. Think of it as a many-dimentional thing. Nothing changes when you hover over an element, but your rendered viewpoint is now drawing the space in which :hover is true. Scripts are things that can potentially change the Document itself. Events are things that happen related to the viewpoint renderer. it would be entirely possible to define something at a lower level to indicate that an event is capable of occurring via the styling mechanism, but what actually happens would be up to the viewpoint renderer. Consider the case of an event occurring on the end of a transition. The triggering mechanism is the viewpoint finishing the transition, and it is up to the engine driving the viewpoint to trigger the event. The styling behaviour would merely indicate that a transition would be requested on certain elements.
- marcosdumay 12y ago
  Looks like we are almost in agreement, except that I see no reason to separate event handling from the overall style description. Of course, modifying the document is out of the scope of styling rules, events handlers on that level must change only styling, nothing else. What events bring (besides generalizing the :hover-like pseudo-selectors into something more powerfull) is better separation of concerns. Instead of your Javascript touching several elements styles, it generates an event, and you describe how to handle it at the styling sheet.