Live data from Hacker News

CSS is unnecessary given a layout language

pchiusano.github.io

51–60 of 183 posts

Re: CSS is unnecessary given a layout language

#51
Graphical layout is one of the most underestimated challenges in computer science. Programmers instinctively look at the problem and thing "oh, this is logical, I'll just whip up some basic principles and layout primitives and I'll have this solved in no time!"

No, you won't. Designing a layout framework is really, really hard. Designing one that is simultaneously expressive enough to handle all of the crazy corner cases that pop up on a daily basis AND simple enough to allow "normal people" to actually use and extend it is quite difficult. For example, the Android layout system is suitably expressive but totally mystifying to anyone who hasn't spent a year reading the source for View/ViewGroup/FrameLayout/ViewRootImpl.

The OP's suggestion that there is some singular, beautiful, composable layout system that we could drop in to replace CSS is, frankly, a pipe dream. Or rather, I would be far more convinced if he actually pointed to a spec or pre-existing system that we might base our new system off of [1].

I see only three real possibilities going forward, in order of increasing likelihood:

1. Someone does indeed come up with the One True Layout System (very unlikely).

2. We finally shove bytecode-level runtimes into a browser and let a thousand flowers bloom (even odds).

3. We keep incrementally improving CSS, adding support for various layout relationships that people need (probably).

[1] Elm's system looks neat, but it's not there yet.

Re: CSS is unnecessary given a layout language

#53
post #51

Graphical layout is one of the most underestimated challenges in computer science. Programmers instinctively look at the problem and thing "oh, this is logical, I'll just whip up some basic principles and layout primitives and I'll have this solved in no time!" No, you won't. Designing a layout framework is really, really hard. Designing one that is simultaneously expressive enough to handle all of the crazy corner c…

I used to work with whacky designers who would always come up with ideas that broke the layout system for whatever toolkit we were using, so I quickly "adapted" by using canvas and doing it all myself. To that end I created Bling:

http://bling.codeplex.com/

The idea is that layout in WPF is so ridiculously complicated, yet data binding could be made so ridiculously simple (hey, they are almost constraints!), that it is often easy to just "do the math" for the layout you want rather than configuring a high-level layout component to do it. The same principles probably apply to ReactJS also (which provides a nice databinding system like WPF). Elm doesn't provide for constraints directly, I think (rather without behaviors, you'd have to compose various events to simulate them in an inelegant way, but please correct me if I'm wrong).

Re: CSS is unnecessary given a layout language

#54

So what does it look like to define a layout in elm?

This is what he is saying is better than CSS? I don't think so. http://elm-lang.org/edit/examples/Intermediate/Form.elm

When I opened this page up, I found a form oscillating violently in Chrome (until the scroll width was adjusted). I'm not sure if that's what you were referring to :)

Re: CSS is unnecessary given a layout language

#55
post #37
post #17

Earlier quoted context omitted.

Suppose you want to create the largest possible square div inside the rectangle of another div. Any layout language that can't let me satisfy such a simple and obvious layout constraint is a travesty. CSS will not let you do this, even with flexbox.

Huh? Flexbox will certainly let you do this: http://plnkr.co/edit/taXhuM4tetbNTlaKyjDr?p=preview (you shouldn't see any of the red box, just the green box) Am I misinterpreting what you mean?

> Am I misinterpreting what you mean?

Yes. The red one should be a rectangle and the green one a square. In your case the red one is also a square.

Re: CSS is unnecessary given a layout language

#58

I actually like CSS as it is now, and it's getting better ( cough , flexbox). Am I the only one who finds CSS incredibly hard to master, though? I've been writing CSS for years and I still feel like a newbie sometimes, and feel like I'm just tinkering with random attributes until it looks right.

I don't mean to be rude[0], but what do you find so difficult about it? The box model makes a lot of sense, and once you understand that you're most of the way there. I still Google for less-common syntax (e.g. adding a strikethrough style to text) from time to time, but most of it is internalized by now[1]. Code School[2] was great when I was first ramping up as a developer. I do also have a great memory[4] for tiny…

The motivations behind CSS are good. And the implementation is OK for the most part. But the "usually-trivial bits of data" are examples of it's failings. Let's talk examples:

* You want to overlay a to the bottom write of a container. You can use "position: absolute; bottom: 0; right: 0", but that puts it at the bottom of the page instead. You have to add "position: relative" to the container. Understanding why you'd need this property means understanding implementation details. Which defeats the purpose of being a declarative language.

* You want to float a to the right of an another. Just add "float: right", to the right? Whoops, that doesn't work. You'll need to add "overflow: hidden" to the as well. Why should the overflow mode (which really should affect a node's contents) affect the layout of a sibling?

* You have a element which extends the width of a content column. You want it to stay fixed within the page so give it "position: fixed". Now all of a sudden it's forgotten how wide it should be and shrinks to the width of it's content.

* You have a second element with "width: 100%". You make it fixed too. Instead of retaining it's original width -- or shrinking like the other header -- it extends from its original position on the x-axis off the side of the screen so that it's 100% of the width of the page.

Sure, you can learn all of these special rules, but that isn't really a productive use of your time. I work with React a lot, so the approach we use is to create generic layout components that can do all of this stuff in a consistent way.

Re: CSS is unnecessary given a layout language

#59
post #31
post #17

Earlier quoted context omitted.

Suppose you want to create the largest possible square div inside the rectangle of another div. Any layout language that can't let me satisfy such a simple and obvious layout constraint is a travesty. CSS will not let you do this, even with flexbox.

GSS will though! http://gridstylesheets.org/

Does GSS work with Reactjs? If so, I might give it a try.

Re: CSS is unnecessary given a layout language

#60
post #21

I'm not really sure I understand what the point of this message is. The point of separation between CSS and HTML is not that "designers" are idiots. Nor is it that developers are poor designers. The idea is strictly to keep the data separate from any other concern. This is broken all of the time by all sorts of grid based elements and such. But the idea does seem decent, if a touch naive. That is, to Spolsky's credit…

> That is, to Spolsky's credit, the point of HTML being completely layout free is supposed to be the compelling feature. Except that it isn't. If you want to do anything entirely non-trivial, you have to annotate your HTML with classes and ids, and then hook into this using a complicated declarative language. But, at this point, there is no abstraction gain from ... over floating_figure(...) Functions are fine abstra…

  > But, at this point, there is no abstraction gain from
  > ...
  > over floating_figure(...)
There is no abstraction gain, because you are using a presentational class name. It should not be "floating_figure", "big_red_text" or anything of the kind. What it could probably be is "feynman_diagram" or something simmilar describing what's so special about this particular element, not the looks or placement of it. And then it is up to your CSS to decide should it be floated, fixed, or hidden altogateher.
Post reply on HN