51–60 of 99 posts
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 ...
Stop worrying about Javascript. HTML+CSS is Turing-complete [1]
[1] http://lemire.me/blog/archives/2011/03/08/breaking-news-html...
Earlier quoted context omitted.
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…
That might be true for print designers of yore, but we've moved beyond that in the last 10 years or so.
Designers today know that it's not about some static composition on top of some grid. And they also know that individual elements are important (e.g. how a callout or a profile pic responds to a page resize).
Heck, it's the same designers that had to suffer using floats for layout (and if there was ever a "engineering driven idea" and at odds with grids it was that). Compared to that constraints is designer heaven!
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?
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?
It's constraints-based CSS. Of course it's going to look different to CSS/LESS/SASS. It's solving the problem of layout positioning a different way.
> If you inject stuff like this into a project, make sure you're doing it solo.
Well, yes. Project teams shouldn't be jumping on the latest shiny web things just for the sake of it, especially on unproven frameworks.
> 'cause if you're on my team, i'll slap you.
Grow up.
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?
Earlier quoted context omitted.
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…
> 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. That might be true for print designers of yore, but we've moved beyond that in the last 10 years or so. Designers today know that it's not about some static composition on top of some grid. And they also know that individual elements…
Also, I don't really see the connection you're implying between using a grid and having a static composition or not considering individual elements behaviour. I do compose out of a grid system; the best designers (or the real designers) I worked with do the same. And that doesn't mean that we won't specify how the profile pic responds to resize - we do. It's just that it is a detail. It's not layout, it's not the composition. The specification of such details should not be the basis for your layout implementation framework.
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.
Distance between eyes is equal to one additional eye; nose lies on a line that connects it to bottom of the ear; mouth are about halfway between chin and nose; body is about seven heads tall, etc.
I'd say constraint solving is pretty much in line with that kind of thinking.
If your layout system's site looks like complete arse on a major browser like IE, your layout system deserves to be ignored.
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 - learning to draw, one of first thing to learn is proportions. Distance between eyes is equal to one additional eye; nose lies on a line that connects it to bottom of the ear; mouth are about halfway between chin and nose; body is about seven heads tall, etc. I'd say constraint solving is pretty much in line with that kind of thinking.
However, it's not relevant for this, I think. Drawing is very different, goal-wise, from design. Designers do learn how to draw early on their education, but I think it's more a matter of learning how to "see" and developing other useful skills. The approach to drawing doesn't translate directly to the approach used while designing.
Compared to previous experience with Qt, I don't see any advantage of constraint-based layout over box-based layout.