Compared to previous experience with Qt, I don't see any advantage of constraint-based layout over box-based layout.
I've been struggling with auto-layout for about six months now. I finally get it but there's a certain impedance mismatch between how you want your elements to be laid out and what constraints are required to achieve the same result. Humans beings aren't wired to intuitively think like a constraint solver.
I'm not an experienced developer but my thinking on this issue is that the platform should provide some functionality to achieve the most common boiler-plate layouts and anything more complex should be written in code.
Usually constraints are simple and so are the layouts. But to achieve more complex layouts you need constraints which are at cross purposes to each other but have different priorities. It's not intuitive to work through this stuff.
Here's an example :
The answer there is great but tell me , you could have aspect fitted the view to it's parent in just four lines of code instead of going through this confusing series of constraints.
I was making a tic tac toe game and I decided to try and draw the boxes and lines using auto layout. The constraints were making me tear my hair out and finally I wrote 5 lines of custom layout code and it took me only ten minutes and this was after futzing about with the constraints for half an hour and it did what I wanted to on an iPhone , iPad and for any height or width.
I personally believe in a simplified version of FlexBox for common cases (yes I think it needs to be even simpler) and custom code for anything more complex.
Bringing in all the baggage of a constraint solver to do your layout is like trying to use an Abrams Tank to kill a mouse.
10 designer creates an initial mock-up
20 designer re-sizes the window / uses another device
30 designer alters the style on that new format, re-sizing boxes, changing font sizes, etc.
40 constraint solver finds a minimal set of constraints consistent with the designer wishes
50 goto 20
The correct answer (for desktop) is canonical grid based layout. (1)
I created DesignGridLayout, a manager for Java Swing. You add rows of widgets, the manager figures out optimal placement.
Every time I see mention of grids and CSS, I get a little bit excited. Then I see it's not based on canonical grids and I leave sad.
Maybe I should have "ported" DGL to HTML/CSS/JS, but I haven't figured out how (yet).
For mobile, I reserve judgement. I've heard good things about AutoLayout. But it'll be hard to replace my strategy of creating custom managers as needed.
(1) Except maybe for dynamic insertion and removal of controls. I'd have consider a few cases.
Maybe a hybrid approach would be best? Constraint-based for the broad strokes and then regular box-based layout within these blocks.
His main points:
* you can't express text wrapping which is a huge issue. You've got to do workarounds in order to support it
* the api is very reference based. You need to say that the right of this element is left of this other one. whereas in react you don't want to assign every element you create to a local variable to get that reference the best api with react is one based on containers. <HorizontalLayout>... This is what I started with in react native but then, i realized that this was so close to flexbox that I could just use it instead :) you could use cassowary as an implementation detail of flexbox but that doesn't give you much
* also, when i tested cassowary, the js version, it was extremely slow. The version that we have in react native barely appears in traces for real code that we have
So I'll pass on similar constraint-based approaches to HTML layout, thanks!
As often happens with solutions that are abstractly "right", constraint-based layout engines do a great job of fixing complex theoretical non-problems that nobody was asking to have fixed, while at the same time failing to address real-world issues that impede users' everyday workflows.
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 two buttons is eight.
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.
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.
And some designers tools also let them express it in exactly that way.
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. :)
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!
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.
Good, because I haven't said so. I said we've moved beyond static designs on top of some grid.
When you add different screen sizes, resizing and interaction to the mix, the grid itself gets dynamic, and relationships between items (constrains) matter more than visual placement.
>It's just that it is a detail. It's not layout, it's not the composition.
The thing is that seems to me a relic of print design.
In modern UI design there's no fixed composition as such. Even whole elements might appear and disappear at will, based on the app's state.
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.
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.)
&[top] == &:next[top];
WTF is this voodoo? Less and Sass aren't complex enough? CSS isn't hard enough to work with as it is?
Because you're so macho, right? And anything you don't understand shouldn't be used.
[EDIT] I find the sample code quite readable -- as long as one understands that it does more than constraints in that example, and that you of course have to read on the symbols to get them, like you'd have to read on Ruby's @, C's * and &, on regular expressions, etc.
But this macho talk from "team leaders" I dislike.
What exactly does it try to prove, even "metaphorically"? That the leader is so arrogant that wont discuss but bully his team? How about we reverse it: who would want to work in a team with some slap happy lead? Who'd want to hire that team or acquire that "talent"?
(And would this talk help the IT industry attract more female programmers?)
Or because he finds it so objectionable that he wanted to express strongly how much so it is. You read way too much into it.
> But this macho talk from "team leaders" I dislike.
Why do you assume he's only talking about situations where he'd be the team lead?
> That the leader is so arrogant that wont discuss but bully his team?
How about that other team members should consider the impact of technology choices and discuss them with the team before putting potentially controversial choices like this into use? (and no, not in order to avoid physical retribution, but because some choices are just awful).
> How about we reverse it: who would want to work in a team with some slap happy lead?
How about you don't read way too much into it? Most places I've worked, slapping someone would lead to a minimum a written warning, but more likely would get you fired, and it would not be impossible the victim would call the police to report the assault.
As a result, absent other information, it is quite reasonable to assume that the comment did not imply he would actually slap anyone.
Do you intend to turn a technological frustration talk into a gender (in)equality debate?
Personally I got that he's just expressing how absurd would be to see something as odd/complicated as that code trying to solve a problem that is inherently due to the complexity (inefficiency maybe) the current CSS model/spec.
This is the exact type of person you don't want on your team: thin-skinned, easily offended and expecting the same level of mollycoddling we pour onto children (another problem in itself).
EDIT: And apparently calling you out on it leads to immediate downvotes. Wow, this really is turning into reddit.
I did not vote down.
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.
I got a blank page so I closed the tab.
It's bad enough we have to build websites that work on IE8. We have to worry about screen readers and other accessibility problems, but we also have to worry about a fraction of users that disable a fundamental browser feature literally every site uses? Nah. It'll break and you can expect it to break! Sorry. :)
>literally every site uses
Ironic that you would post that on a site that works without it...
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".
No, they just believe so about themselves.
EDIT and now (some) videos start autoplaying when I scroll past them. I don't want that!
Oftentimes this totally gets forgotten btw. And it is not only GA - it is Adobe Analytics, Heap, every conversion-tracker by Facebook and Adsense and the likes.
SO yeah - we (so called) web analysts know that and even have ideas/means to track the number of people that disable js by default or that block every form of (browser based) tracking.
You get locked (most of the time), but you can block this (most of the time) as well.
edit: the video I saw is actually that o'reilly video that's linked in the GSS website
As should CSS. From what I understand of GSS, it's entirely possible to use it to augment CSS rather than replace it. Granted, with certain layout problems it's trying to solve, that might be tricky/impossible.
#elmA[top-left] == "area"[top-left];
#elmB[bottom-right] == "area"[top-right];
Yet, i would absolutely not use it without the wysiwyg tools xcode provide, such as warnings on conflicts or automatic preview after changing the uppermost container's frame.
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".
I've been thinking about constraint satisfaction solver for layout, and keep it in mind as a possible project for a future. Great to see someone shares this view and went on to implement it.
I haven't studied this concrete project deeply, but the idea in general seems appealing, because CSS is hell.
(The site says this constraint language is used in Apple products - I didn't know that).
I'm opposed to most CSS grid styles as I feel they trade accessibility for a faster production speed. This seems to have neither of those benefits.
Perhaps this is why the web uses box-based rather than constraint-based layout.
Also, ironically, the site looks pretty bad on mobile and the entire left side of the page is chopped off. I don't take any "new ideas in style" page seriously if the mobile (or desktop, or whatever I'm using) experience on that page is bad.
You can't choose such an incredibly generic name though and then expect all existing references to update, that's simply illogical.
Update: http://jdon.at/1cgIw the emails in question
Since you're asking, yeah, you went a little overboard.
The guy clearly didn't "expect" anything, he just made a simple request. He could have worded it a bit better, but it was reasonable enough - not something that deserved such a tongue-lashing.
> This is worse than the grid style sheets I was hating on. Much worse. They simply aren't semantic which was nitpicky whereas this is a literal crime against humanity namely accessibility.
Seriously, a literal crime against humanity? :-) I was impressed that Dan replied as cheerfully and graciously as he did.
Look, I've said nastier things to people myself - it can be so tempting - but it never worked out that well. It took me a long time to learn that it pays to try to get along.
It's great that you're passionate about technology, if you can temper that with keeping disagreements cheerful and sympathetic toward other situations and points of view.
One last thing... Dude! Did you get Dan's permission to publish his private emails to you? He seems like a level-headed guy and probably won't mind, but it's polite to ask first.