Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Should CSS be constraints?

pavpanchekha.com

Post reply on HN
Print view View original

31–40 of 46 posts

Re: Should CSS be constraints?

#31

Post by nicoburns »

araes wrote: post #26
nicoburns wrote: post #4

The problem with a constraint system is that it would likely be even more subject to performance problems than the current setup. IMO what CSS layout really needs is: 1. A "proportion of available space" unit. That is, something like the fr unit in CSS grid except applicable to the width/height properties so it can be used in all layout modes and without an implying content-based minimum size (like fr does). 2. A new…

What CSS needs (opinion, caveat, really far away in advanced features) is: - A way to get values from sliders (type="range") (and style and modify them easily). Really, a way to get "value" from any element. - A way to have radio / checkboxes or labels inside labels work for multiple choices (or something other than making enormous arrays of radio selections and CSS choices) - A way to have indexed arrays of numbers…

It looks like HTML may be getting the ability to manipulate the class/attributes of elements in response to clicks (declaratively, without JS). Which would solve a lot of the interactivity issues (checkbox hack, etc).

See: https://developer.mozilla.org/en-US/docs/Web/API/Invoker_Com...

Re: Should CSS be constraints?

#32

Post by araes »

nicoburns wrote: post #31
araes wrote: post #26

Earlier quoted context omitted.

What CSS needs (opinion, caveat, really far away in advanced features) is: - A way to get values from sliders (type="range") (and style and modify them easily). Really, a way to get "value" from any element. - A way to have radio / checkboxes or labels inside labels work for multiple choices (or something other than making enormous arrays of radio selections and CSS choices) - A way to have indexed arrays of numbers…

It looks like HTML may be getting the ability to manipulate the class/attributes of elements in response to clicks (declaratively, without JS). Which would solve a lot of the interactivity issues (checkbox hack, etc). See: https://developer.mozilla.org/en-US/docs/Web/API/Invoker_Com...

Thanks. Saw this, thought it looked cool. Just could not find what it can do other than "popover" "popovertarget" without using JS.

The examples provided for custom events all seem to use JS anyways. Ex:

  

  ...

  if ( event.command == "--rotate-landscape" ) { image.style.rotate = "-90deg" }
Agree it would be cool, it just doesn't seem to do a lot. Generalized "popovertarget" except that basically means +modal in most of the examples. And all the modal dialogs are almost always "popover". And you can already make "popover" appear over "popover" with multiple onscreen. Maybe there's something with looking. [1]

[1] https://developer.chrome.com/blog/command-and-commandfor

Edit: Here's an example of the overlapping popover functionality. https://araesmojo-eng.github.io/

Main Page -> General Tests Menu -> Open Popover 1 | Open Popover 2

Should both open popovers simultaneously on top of each other while dismissing neither, and also change the state of elements on the page at the same time.

Re: Should CSS be constraints?

#34

Post by Inviz »

jononor wrote: post #29

Grid Style Sheets / GSS was an implementation of this idea. https://gss.github.io/guides/ccss I saw was because I do not think anyone has used or maintained it since the company behind went belly up. But the code is still out there as open source, probably can be learned from. Disclaimer: I used to contract for them, but in other areas.

Hello Jon! This is Yarik. Cool to see you doing all this machine learning work these days.

Re: Should CSS be constraints?

#35

Post by Inviz »

jononor wrote: post #29

Grid Style Sheets / GSS was an implementation of this idea. https://gss.github.io/guides/ccss I saw was because I do not think anyone has used or maintained it since the company behind went belly up. But the code is still out there as open source, probably can be learned from. Disclaimer: I used to contract for them, but in other areas.

If I am to provide a summary of why layout shouldnt be linear constraints, is that it can't faithfully represent content overflowing onto multiple lines. I.e. it's inherently one dimensional. I.e. you can't really have a layout that adaprts to the screen size without creating a lot of separate breakpoints. This is a big limitation, that for example flexbox doesnt have. When I left Grid i immediately went and reproduced a lot of stuff we've been doing in (new then) flexbox layout engine, and i was like: Oh my god, this is so much more powerful.

Re: Should CSS be constraints?

#36

Post by pavpanchekha »

rendaw wrote: post #7

> But with constraint-based systems, the layout might be literally under- or over-determined, in the sense that there might be more than one, or less than one, layouts that satisfy your rules. This is under the "what's wrong" section but it doesn't actually say what's wrong. Obviously if over-specified, the extra constraints can't be followed which wouldn't be intuitive (and... css does this constantly, so it doesn't…

Author here. The problem isn't the technical challenge of writing a constraint solver. It's making sure that the resulting layout looks good, despite contradictory guidance from the designer.

Yes, a constraint solver can figure out which constraints it's violating. And for under-specification, it can produce a layout that satisfies the constraints. But the layout the constraint-solver chooses might be really bad—if all the text is placed at 0,0 the result is unreadable. And over-specified constraints might occur for some user on some weird device after deployment, when there's no developer to respond to errors.

Determining whether a set of constraints could be over- or under-specified for some set of parameters is computationally very challenging (this is what SAT and SMT solvers do, basically). But besides the computational challenge, I think it is practically very challenging—this is drawing off my experience doing this for four years—to write non-conflicting constraints for real-world designs. How would you write constraints for text wrapping around a figure? For mixed-font text lining up nicely?

Re: Should CSS be constraints?

#38

Post by dfabulich »

Apple's native SwiftUI framework and Google's Jetpack Compose framework stumbled upon basically the same layout system, "Constraints down, sizes up":

1. Proposal: The parent component proposes a size/constraints to the child

2. Measurement: The child component picks its own size based on those constraints

3. Placement: The parent component then positions the child in its coordinate space

It's all done in a single pass. It scales great. It fits great with React-like reactive UI frameworks. (SwiftUI and Jetpack Compose are based on React.)

This is what CSS needs.

Re: Should CSS be constraints?

#39

Post by pavpanchekha »

troupo wrote: post #5

I'm not convinced about the "edge case" at all. CSS made it an edge case for no reason at all, and made a silly default out of it. If the box isn't big enough to contain center-aligned text, of course it should spill on both sides, because it's both expected and consistent . And now the author pretends "we left-align text and spill on the right" as the only possible default behaviour that somehow makes constraints im…

Author here. This specific quirk of CSS is minor, and probably if CSS didn't have this quirk it'd be fine. But I'd guess that you've at least once in your life been on your phone and been browsing a website which used a really long word (or a really long line of code!) in centered text (maybe a heading) and you've scrolled right to read the whole thing. Are you sure your website doesn't have such a thing, if you have centered text somewhere?

So, yes, CSS could have fewer edge cases and workarounds---what I refer to in the post as less implicit knowledge---and then it would be simpler. But the resulting layouts would probably be worse. And a radical simplification like a constraint system would probably be even simpler and the results (I assert) would be even worse. It's fine to want a better life for browser developers, but I don't think it's unthinkable for CSS to create new edge cases and sometimes-surprising behavior if it also results in, typically, better outcomes.

Re: Should CSS be constraints?

#40

Post by pavpanchekha »

rendaw wrote: post #8
troupo wrote: post #5

I'm not convinced about the "edge case" at all. CSS made it an edge case for no reason at all, and made a silly default out of it. If the box isn't big enough to contain center-aligned text, of course it should spill on both sides, because it's both expected and consistent . And now the author pretends "we left-align text and spill on the right" as the only possible default behaviour that somehow makes constraints im…

> designers are, by necessity, going to rely on implicit knowledge encoded somewhere on what to do in edge cases This seems to be implying that designers rely on quirks like the left alignment thing and not behave consistently... that seems like a crazy assertion to me. And that appears to be the crux of the argument. A more general, consistent system wouldn't provide enough context for the browser to provide specifi…

Author here. I suppose it depends on what "rely on" means, but... have you ever used CSS to center text? Did you think much at all about what happens if the zoom level is high enough and the screen size small enough that the text doesn't fit? I assume not (I don't think I'd ever thought about that before I read that part of the standard), so in that sense you were relying on this behavior. I do think that in most cases where it activates, the quirk implemented by CSS probably improves the layout.
Post reply on HN