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

Grid Style Sheets – Replace CSS with a Constraint-Solver

gridstylesheets.org

Post reply on HN
Print view View original

41–50 of 99 posts

Re: Grid Style Sheets – Replace CSS with a Constraint-Solver

#41

Post by coldtea »

paulojreis wrote: post #28
kenferry wrote: post #24

Earlier quoted context omitted.

> appealing to programmers because they seem intuitively like the "right" solution … Constraints don't match the way designers work Interesting, I'd say almost the opposite. These constraints capture almost exactly the same thing as the orange guide lines you see in Keynote (or Powerpoint, or whatever). This is inset from the top right by 10, this button is the same width as the one above, the distance between these…

> That's almost exactly what designers' specs look like in my experience – screenshots annotated with lines with numbers on 'em. Yes, but that's because those designers were asked to specify the layout in engineer terms. :) That doesn't mean that that's the way they think and conceive the UI.

Actually that's exactly the way they think. "These items should be aligned at their bottom ends", "this group of items should have space between them and take the whole width of the page" etc.

And some designers tools also let them express it in exactly that way.

Re: Grid Style Sheets – Replace CSS with a Constraint-Solver

#42

Post by coldtea »

thrownaway122 wrote: post #4
Qantourisc wrote: post #3

I'd love to use this. But in the back of my head I still think javascript should be optional if possible ... not that 99% of the rest of the world cares ...

> javascript should be optional if possible I got a blank page so I closed the tab. Any page that requires javascript and I don't need to use (at the level of do my taxes) or that I don't trust the owners of gets the same treatment. So yeah optional javascript is a thing unless 100% of your audience are absolutely required to use your site. EDIT given that sites today use google analytics instead of their own server…

>I got a blank page so I closed the tab. Any page that requires javascript and I don't need to use (at the level of do my taxes) or that I don't trust the owners of gets the same treatment.

It's not like that behavior matters. That's about 0.001% of computer users.

Might as well say "If it's not available in Gopher format I don't care".

Re: Grid Style Sheets – Replace CSS with a Constraint-Solver

#43

Post by reinviting »

SchizoDuckie wrote: post #7

From their demo: structure.gss @h |-(#message)~-~(#follow)~-~(#following)-(#followers)-| in(#profile-card) gap($sgap) !strong { &[top] == &:next[top]; } } If you inject stuff like this into a project, make sure you're doing it solo. 'cause if you're on my team, i'll slap you. WTF is this voodoo? Less and Sass aren't complex enough? CSS isn't hard enough to work with as it is?

And for all that effort you get an avatar that is horizontally misaligned by 10px and a webpage that falls apart when you vertically shrink your browser window.

Re: Grid Style Sheets – Replace CSS with a Constraint-Solver

#44

Post by panic »

kenferry wrote: post #24
pavlov wrote: post #23

Earlier quoted context omitted.

Agreed completely. Constraint-based layout solvers are very appealing to programmers because they seem intuitively like the "right" solution -- but that intuition is based on the programmer's mental model of user interfaces. Constraints don't match the way designers think and work, so they're not good as a non-programmer's interface. As often happens with solutions that are abstractly "right", constraint-based layout…

> appealing to programmers because they seem intuitively like the "right" solution … Constraints don't match the way designers work Interesting, I'd say almost the opposite. These constraints capture almost exactly the same thing as the orange guide lines you see in Keynote (or Powerpoint, or whatever). This is inset from the top right by 10, this button is the same width as the one above, the distance between these…

Designers have to add these lines and numbers after the fact, and they don't always reflect the intent behind the layout. As screen sizes, typefaces and other layout details change, fixed numbers quickly become obsolete.

The ideal is to encode that original intent behind the layout into your program. As far as I can tell, any set of constraints simple enough to solve efficiently will not be powerful enough to model your designer's intent. The design will eventually become complex enough that your layout will need to be represented as a procedure. Once that happens, the constraint system becomes just another pointless layer of abstraction.

Re: Grid Style Sheets – Replace CSS with a Constraint-Solver

#46

Post by rimantas »

cageface wrote: post #12

One of the absolute worst things about iOS development is struggling with auto layout. Sure there are some things you can do with it that are hard to do in a box layout method but 95% of the time it's just a massive headache to achieve something you could do with flexbox or even Bootstrap in a much more transparent way. In fact, one of the most appealing things about React Native is that it lets you do iOS layout wit…

I'd say the percentages are reversed.

Re: Grid Style Sheets – Replace CSS with a Constraint-Solver

#47

Post by robogimp »

I just watched this GSS intro talk from last year: https://vimeo.com/91393694 It looks interesting, but obviously from this and the demo page it needs alot of work to be ready for the mass market.

One piece of advice for Dan if you are reading HN, you have a nice relaxed speaking style but please stop using the word "crazy" or "it gets pretty crazy" which for me at least parses as: "too complex to work with".

Re: Grid Style Sheets – Replace CSS with a Constraint-Solver

#48

Post by paulojreis »

coldtea wrote: post #41
paulojreis wrote: post #28

Earlier quoted context omitted.

> That's almost exactly what designers' specs look like in my experience – screenshots annotated with lines with numbers on 'em. Yes, but that's because those designers were asked to specify the layout in engineer terms. :) That doesn't mean that that's the way they think and conceive the UI.

Actually that's exactly the way they think. "These items should be aligned at their bottom ends", "this group of items should have space between them and take the whole width of the page" etc. And some designers tools also let them express it in exactly that way.

Yeah, that's the engineer perspective on it. Focusing on the details, on deconstruction, and not on the whole.

It's true that rules such as "bottoms aligned" and "equal heights" exist frequently. And it's also true that there are tools to express these rules (align and arrange tools in Adobe software). However, those are the "implicit" parts, the minor details that one attends to while designing but without giving it much thought. Of course, for the technical guy who implements, those details are important. And that's why they're specified in design specs, so to speak.

But the layout, the major composition, is thought (typically) out of a grid system. And that's what, I believe, a designer focus on. Not on individual element rules, but on the whole.

Of course, if a engineer spends hours making a detail in the implementation look like the design, then he'll think that the designer gave it a proportional amount of attention. Typically, not true. :)

Re: Grid Style Sheets – Replace CSS with a Constraint-Solver

#49

Post by archagon »

cageface wrote: post #12

One of the absolute worst things about iOS development is struggling with auto layout. Sure there are some things you can do with it that are hard to do in a box layout method but 95% of the time it's just a massive headache to achieve something you could do with flexbox or even Bootstrap in a much more transparent way. In fact, one of the most appealing things about React Native is that it lets you do iOS layout wit…

Autolayout is really nice once you figure out what it's good for. And it's certainly not good for everything.

Making a keyboard? Don't even bother. Too brittle, too slow.

Making something with dynamically-loading views? Probably not a good idea. Too unpredictable.

Trying to animate something fancy? Just change the frames directly. Doing it through an intermediary system is just too finnicky.

But the other day, I was designing a toolbar for my app. I needed floating menu buttons all along the top of the screen. Whenever a menu opened, it would grow horizontally and vertically; any existing menu buttons along its edges had to slide out of the way accordingly, or shrink if they hit the edge of the screen (with the distance between menu buttons being paramount). The specifics of the menu's expanded dimensions were left to the menu controller itself, and they could change at any time. For this, autolayout was absolutely the perfect tool for the job.

Whenever you have a small, finite set of static elements that can push each other around, autolayout makes things a lot simpler.

(The programmatic interface is just awful, though, and the visual formatting language doesn't do enough.)

Post reply on HN