
Humans are not constraint solvers - miguelferreira
http://amigueloferreira.pt/humans-are-no-constraint-solvers/
======
ridiculous_fish
Disclaimer: I was the owner and maintainer of autolayout at Apple for a few
years. I think the article makes a fair point, but focuses on just a detail.

The article criticizes what it calls "source-order independence" where "you
can have two unrelated components be involved in a constraint." We called this
"cross-cutting constraints," and discouraged their use for exactly the reason
the author gives. Most constraints attached to you should be to yourself, a
sibling, or a parent. Cross-cutting constraints are not a primary benefit of
constraint-based layout.

So what do constraint-based layouts give us? A key one is that constraints
regularize layout under a uniform language. You are given a handful of
properties (width, height, two centers, four edges, and baseline) and
constants, and can relate them using equalities, inequalities, and priorities.
From those primitive elements, you can build a lot of stuff that other
frameworks handle in an ad-hoc manner.

Want to set a fixed width? Equate the width to a constant. Make it a minimum
width? Change the relation to >=. Right align? Equate the two right edges.
Centering? Equate the two centers. Two containers ought to have equal widths?
Relate their widths to each other. Aspect ratio? Relate the width to the
height. All this stuff just falls out naturally, requiring no special support.

Compare to CSS, which supports many of these features, but in a completely
arbitrary, ad-hoc way. Right-aligning requires setting a position, but center-
aligning requires setting margin-left and margin-right, and vertical centering
requires a completely different set of hackish techniques. Or compare to
Android, which has lots of ad-hoc methods to achieve specific layout tasks
(setMeasureWithLargestChildEnabled, setBaselineAligned, etc).

Autolayout has its share of problems: it's verbose, has a steep learning
curve, works poorly with grid-type layouts, struggles with nonlinear layouts
like text reflowing, and more. But its approach of a uniform layout language
is powerful and elegant, compared to ad-hoc "bag of properties" layout
mechanisms.

~~~
protonfish
Actually CSS is not arbitrary. I don't know what you mean by "setting a
position" but if you use float to right or left align an element, it will
cause text to wrap on the opposite side. How would text wrap on float: center?
It doesn't make sense, that's why you'd just want blank space on each side
(hence margins.)

Everything else works well with absolute positioning. Need something
vertically aligned?

    
    
        position: absolute;
        top: 50%;
        margin-top: (1/2 height of element)

~~~
ux-app
as mentioned in another comment this only works if you know the height. Your
example is exactly the issue that the original comment was talking about.

Your intention is to align both centers. Why do we need to be dealing with
'top' and 'margin-top' to achieve this? It is a poor way to describe your
intention.

It's much easier to say:

    
    
      box1.center == box2.center
    

The cassowary solver allows you to specify exactly your intentions in relation
to the edges and centers of boxes. It's easier to reason about and doesn't
require the bag of weird tricks that are needed in CSS (eg. margin: 0 auto; to
center??? wtf?)

------
lisper
CSS has one main problem w.r.t. layout: it does not have a universal way of
specifying whether the size of an element should be determined by its contents
or its container. So you can say, for example, "Make this element take up the
remaining horizontal space" (that's the default for display:block) or "Make
this element just wide enough and just tall enough to contain its contents"
(the default for display:inline) but it is not possible to say, "Make this
element tall enough to consume the remaining vertical space." The result is
that some simple layouts (e.g. a fluid layout with same-height columns
underneath a header with dynamic content) are not possible in CSS. All this
could be solved by simply allowing the user to specify width and height of an
element in terms of either the element's contents or the element's container
(or, of course, as a fixed size).

~~~
vertex-four
> it is not possible to say, "Make this element tall enough to consume the
> remaining vertical space."

As of just a few months ago, it is. Look into the now-almost-standardised
(last call working draft) version of flexbox, which is implemented in recent
versions of Firefox and Chrome, and also IE11.

An example of what you say is impossible, in just a few lines of CSS:
[http://philipwalton.github.io/solved-by-
flexbox/demos/sticky...](http://philipwalton.github.io/solved-by-
flexbox/demos/sticky-footer/)

~~~
lisper
It looks like you edited your comment. The original link was:

[http://philipwalton.github.io/solved-by-
flexbox/demos/holy-g...](http://philipwalton.github.io/solved-by-
flexbox/demos/holy-grail/)

and now it is:

[http://philipwalton.github.io/solved-by-
flexbox/demos/sticky...](http://philipwalton.github.io/solved-by-
flexbox/demos/sticky-footer/)

The latter is not what I described, and I can't get the former to work even in
the latest Firefox.

~~~
vertex-four
Oops. I read what you said and thought the current one matched what I quoted
better - sorry.

I'm using Firefox 32.0.3, and both examples work for me perfectly. I'm not
sure what the issue is.

~~~
pessimizer
Both work for me fine, too. Latest Firefox on Debian.

According to: [http://css-tricks.com/snippets/css/a-guide-to-
flexbox/](http://css-tricks.com/snippets/css/a-guide-to-flexbox/) Firefox
should work from v22 on.

------
Animats
There are two issues here. One is doing layout with a constraint solver. The
other is the user interface for the person doing the page layout.

A constraint solver interface is a good match to a GUI. It's not a good match
to a textual interface. Web designers should be using a layout tool like
Dreamweaver, not hand-coding constraint expressions.

For an example of a constraint-based tool for a much harder problem, see
Autodesk Inventor, which is a 3D CAD system. It has 2D sketches, and those are
controlled by constraints. You can draw rectangles, and if they have
coincident points or edges when drawn, those are constrained to stay together.
You can explicitly dimension something, and it becomes that length. If you try
to apply inconsistent constraints, the system rejects them. You can make all
constraints visible as icons, then delete any you don't want. Web designers
would probably love the power of Inventor sketch mode, because it's not
restricted to horizontal and vertical lines, or even to straight lines. That
might be overkill for web design, although being able to wrap text around a
curved image would make some people happy. Inventor demonstrates that a much
harder constraint problem than web design has been successfully solved with a
good GUI.

Asking visual designers to write constraint expressions by hand is pounding a
screw with a hammer. Use the right tool for the job.

------
pessimizer
I don't understand the title. Humans are constraint solvers (I have personal
experience in this), although they are not fast at it, so humans also _use_
constraint solvers.

If you don't have a constraint solver in your layout engine, you had better be
a good one yourself, because somebody has to do it.

------
SixSigma
And yet that is _exactly_ the direction that Computer Aided Design - such as
Autodesk Inventor & Dassault SolidWorks - has gone in. And it makes building
things a shit load easier, let me tell you.

------
coldcode
I don't think there is a single way to do layout that is perfect for all
needs. Both CSS style layout and Autolayout work well for many cases and fail
miserably for others.

------
rzimmerman
I never could get onboard with constraint based layouts. It feels like someone
got a little too clever and really over-solved a problem. Realistically, you
want your content to look decent on small screens (phones), medium sized
screens (tablets), and fill larger ones (everything else). In the case of iOS
dev you really have 3-4 specific targets. CSS media queries (or 2-3 nibs with
boxes and springs) solve this problem adequately. Trying to create a system of
linear inequalities that guarantees perfection on every possible resolution is
just asking for mistakes and headaches. I agree with the author that most of
the "power" lays in a space of things you really don't want to touch.

------
dllthomas
Isn't the real question whether humans are good at _generating_ constraints?

~~~
3rd3
* _maintainable_ contraints

~~~
dllthomas
Yes. But that still doesn't necessarily mean solving, provided you can
actually constrain everything you care about, which I'd guess you probably
can't...

~~~
3rd3
It’s a rhetoric device (a hyperbole) which hints to maintainability issues.
That’s how I understood it.

~~~
dllthomas
Yeah, I didn't mean my comment to be a devastating take down. I just find it
frequently useful to try and state things more clearly and correctly when
faced with hyperbole.

------
melloclello
If somebody writes an incomprehensible sentence it's not his language's fault
for him doing so - and the solution is not to simplify English.

------
qwerta
All you need to understand this problem is better language.

All of this has been solved long time ago at Java Swing. Checkout Mig Layout.

