Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Maybe, but preferably a system whereby impossible layouts are detected and reported, not "fixed" arbitrarily, and similarly, where ambiguous layouts are detected rather than implementation-dependant.

Also, I'd really like a system where a little more thought was given to practical layout issues, and GSS is extremely limited - even simple things like adjacency and containment needs to be manually specified in terms of positioning.



Layouts can be possible/impossible depending on screen resolution, available fonts, users default text size preference, zooming, etc.

So, reporting (some) impossible layouts can only be done at runtime. Telling the user "you cannot see this because some constraints cannot be made on this system with the current settings" may not be what users want.


Yeah, there's no black and white answer to this - but GSS really has a lot of those ambiguities. They're called constraints, but they're more like optimization targets, and while in simple cases it's easy to see which constraint gets violated first, in complex cases it's a little too much like spagetti code: theoretically deterministic, but too much to handle.

CSS also has "constraints" and they're also sometimes violated, but most constraints are never violated (e.g. normal flow blocks are always sequentially after each other even if they don't fit. Those that are violated are violated in consistent, predictable fashion: e.g. though a container vertically grows to fit its contents it may stop growing for various reasons, even if its children don't fit.

In GSS? Since every layout reinvents the wheel for the basics, all bets are off. Since the whole point is that there can be complex, multilevel interactions between the components it's not always clear which "constraint" is violated first, nor even that it may be necessary to violate those constraints.

Basically: I think GSS is too hard to reason about, making it admittedly more flexible, but too error prone compared to CSS. Furthermore, because it doesn't integrate with lower-level concepts like actual content, it's sometimes even less powerful that CSS - GSS can't for instance emulate CSS tables or even simple paragraphs that are no longer than necessary; for that (AFAICT) it delegates to existing layouts.

Then there's the fact that CSS breaks cycles quite rigorously. Usually it't not even possible to define them; and where it is the spec is fairly clear what needs to give. In GSS, I can't see any protection - you won't even really notice you've potentially got a problem until constraints do weird things for hard to predict reasons.

So, I think for most layouts GSS is wordier and more brittle than CSS, and where that's not the case I'd rather have a more robust, predictable system. In essence: the stronger, more flexible, closer to turing-complete a language, the worse. Weak is good. Limited is fast, predictable, optimizable, good for tooling.

GSS goes too far.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: