Hacker News Reader

Comment by bbx | Hacker News Reader

"why can't we position & size elements relative to each other"

It already exists. It's called margins.

But it might be hard to handle when half of the elements in the page have the following style applied:

  position: absolute;
  margin: 0px;
  top: 0px;
  left: 0px;

If your title needs to have a "width: 1121px" and your container a "padding-right: 377px;" in order for your layout to work, you're doing it wrong.

I seriously don't understand the point of calculating and generating such arbitrary positioning values.

A web page's layout is meant to stay fluid, because it should adapt to the content it's styling. Margin, padding, font-size, line-height... These are all meant to provide rules to position elements relative to both its surroundings and its content.

These Grid Style Sheets might be powerful but they're not for the web. Definitely not.

View on HN

You're mistaking what is for what should be.

CSS is one approach to laying out a page (which ignored grids, columns, relative positions for elements which are not nested, sane vertical positioning, min/max measure (which makes your fluid layouts rather difficult to actually do properly e.g. on this site measure is way too long) and a ton of other graphic design principles which seemed inconvenient to the authors). CSS has been improving, however it is well suited to RFCs and similar articles and not great for more complex illustrated content.

There are many other different possible approaches to styling content, and even if they are not successful they might inform a more effective and succinct CSS of the future which doesn't actively get in the way of designers.

The original Badros and Borning paper on Constraint Cascading Style Sheets from 1999 explains pretty well why something like GSS is needed: http://www.cs.washington.edu/research/constraints/web/ccss-u...

iOS developers have the power of using constraints for their layouts. Why not give the same to web development?

As for fluidity, this is something GSS can provide very easily with the conditionals. Imagine being able to do media query-style rules, but not only for the screen size but also for sizes of other elements. "If the image is bigger than X, change the layout so-and-so".

A little example: open the toolbar layout demo (http://gridstylesheets.org/demos/apple/) in a browser window, and resize that around. See how the button that prefers to be in the center, but even more strongly doesn't want to overlap with the other buttons behaves.

> iOS developers have the power of using constraints for their layouts. Why not give the same to web development?

Because the web is meant for documents first, not applications.

The example who linked to is a nice demo, and I understand how the GSS is meant to be used. But for all the fancy CSS techniques that hit the HN frontpage (and that are usually frowned upon because there is no "practical" use case), there's probably one just as suitable for this particular situation.

A somewhat related example, with just a few JS lines: http://toki-woki.net/lab/fluid-corners/

>Because the web is meant for documents first, not applications.

That train has left the station long ago.

> That train has left the station long ago.

https://www.youtube.com/watch?v=B-DpRcxK_N8

> Because the web is meant for documents first, not applications.

Which is, ironically, why something much better than CSS is necessary. Right now you simply can't have rich presentation and a presentation independent document because CSS just doesn't actually give you that. Need to re-arrange your document's presentation with CSS? You'll have to move your html around to make that happen. Need a grid layout? Throw a bunch of stupid classes all over your html for your ridiculous CSS framework to latch onto. To rearrange them? Switch them around.

A richer presentation layout will help the web be for documents first, not hinder it. And more so than trying to pretend that it's still 1994 and no one's ever tried to do anything remotely complex on the web yet.

http://csszengarden.com/ have been there for years…

Can you explain how that rebuts the parent's point? I can't see it myself.

While we clearly disagree on whether the web is a viable app delivery platform, there is no reason why documents couldn't look beautiful on the web either.

Compare a nicely designed magazine or a book to a typical website. Which one is more readable? The reason why so much of the web is not nice to read is because complex layouts in CSS are hard.

Most books don't have complex layout. What they have is extremely high quality typography and careful attention to how the text appears on a specific page. Book designers tweak prose to avoid rivers (a series of whitespace on successive lines that happen to line up with each other), widows (the final line of a paragraph appearing on its own at the beginning of a page), orphans (the first line of a paragraph appearing on its own at the beginning of a page, or when the last line of a paragraph contains only a single word), and hyphenation.

The web, which doesn't have well-defined pages or even page sizes, precise control over typography, or designers who agonize over how the actual text appears in the context of the layout, lacks all of those. Typography is slowly getting better, but text layout algorithms are still relatively primitive.

Most books have trivial layout and typography - simple, successive paragraphs with a few very minor embellishments such as the occasional large header, page-breaks before chapters, and page numbers in the footer. Preventing widows and orphans is definitely not the norm - just browse your local library or bookshelf. I seriously doubt people worry much about rivers, too.

Books with diagrams and side-notes tend to have more complex layouts, sure - and that's most educational books. Maybe there these typography issues are given more attention, but it's pretty clear that the typical paperback has demonstrated they aren't that important to readers (which isn't a judgement, it's just the way it is), so I wouldn't be surprised if almost no books worry about these issues anymore, beyond perhaps using software which addresses them insofar as they can be automatically.

> Because the web is meant for documents first, not applications.

Where have you been for the past decade? The web is the world's largest app platform, and it's not going away any time soon.

I don't know about the person you replied to, but I have been developing for that very web for the past decade and a half. I agree about web not going away any time soon, and I am not sure about it being the largest app platform, but of one I am sure: it is a lousy platform for the applications. So I do not want it to go away, just to go home. (and let's not confuse the web with the internet).

> Because the web is meant for documents first, not applications.

What year is it?

>A web page's layout is meant to stay fluid, because it should adapt to the content it's styling.

The content it's styling it's, more often than not, not fluid.

It's a text that has to have a certain number of characters per line, in order to be legible. It's images that the author intents to be a certain size, and only that.

>These Grid Style Sheets might be powerful but they're not for the web. Definitely not

The Web has not been what you desribe for most of it's life. It might have been the intention of Tim Berner's Lee to be so, but that never caught on. And no real reason for it to catch on.

Disagree. I would argue content should fit the layout, and its just frontend ideology that puts a premium on using css as the main way to do it.

Constraint solvers are used in typical (do we still call them fat clients?) gui toolkits, the web is just finally catching up after a decade or so of little to half-baked solutions.

I'm excited that projects like this are finally getting visibility.

> A web page's layout is meant to stay fluid, because it should adapt to the content it's styling. Margin, padding, font-size, line-height... These are all meant to provide rules to position elements relative to both its surroundings and its content.

Which is exactly what GSS's constraint-based approach to stylesheets seems like it does better than vanilla CSS. The name is probably bad ("Grid" doesn't refer to positioning on a grid but is because it, as well as being its own open-source thing, also underlies a bigger project called "the Grid".)

Margins let you position an element relative to its immediate parent.

This alternative scheme lets you position an element relative to any other element on the page.

True indeed. Grids are only meant for architecture and graphic design. If needed, they should only be transferred to websites and apps visually (ie. http://hashgrid.com/). Transferring them programatically is a waste of time. Basic CSS will do just fine.

http://subtraction.com/pics/0703/grids_are_good.pdf‎

W3C has been hashing out new grid-based specs for quite some time now, because as admitted in the Grid Layout Module working draft, "As websites evolved... floats, were not necessarily well suited for application layout."

http://www.w3.org/TR/css-grid-1/#background

Dozens & dozens of CSS grid systems have emerged, but without retooling the internals of the browser's layout engine and adding new CSS language features, such attempts retain the flaws of CSS float & will taint content semantics.

But, of course, the W3C's grid-based efforts is not without flaws, see:

http://www.markboulton.co.uk/journal/rethinking-css-grids

Thanks for mentioning this. I had peeked at those specs, proposals. Looks like a CSS version of GridBagLayout. No mention of canonical grids. (See my other comment.)

> Grids are only meant for architecture and graphic design.

This isn't a grid, its constraint-based layout. the "Grid" in GSS isn't because its grid-based (which it isn't), but because its part of the platform for a stealth startup called "the Grid".

Reply on news.ycombinator.com