Grid Style Sheets – Replace CSS with a Constraint-Solver | Hacker News Reader

Grid Style Sheets – Replace CSS with a Constraint-Solver

gridstylesheets.org

199 pointsaeontech96 comments

As GUI dev who worked with Apple's AutoLayout extensively I can confidently say constraint-based layout is a trap. It looks like more intuitive way to go on simple examples, but complexity spikes quickly as number of controls goes up. It's more complicated, more resilient to changes (harder to maintain), easy to get wrong, hard to understand and debug, bugs generally look uglier (what would be minor misplacement in CSS often becomes overlapping or clipping). It does not support word wrapping without hacks and restrictive assumptions about width. It is a real mess to insert/remove controls dynamically.

Compared to previous experience with Qt, I don't see any advantage of constraint-based layout over box-based layout.

I saw the headline , didn't even read the article and came here to say this and saw your comment.

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 :

http://stackoverflow.com/questions/25766747/emulating-aspect...

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.

Perhaps the right approach would be to still use constraints to describe the layout, but to infer those constraints from examples provided interactively by the designer. The workflow would be:

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

Some sort of genetic constraint generator, where the fitness function is examples provided by designers?

The examples are meta-constraints. The fitness function is the parsimoniousness of layout constraints, under the constraint that they reproduce the examples.

Yes. Even though I understand the math and the concepts for iOS's constraint based layout, I have found it amazingly difficult to use in practice. In IB, if you set one thing wrong suddenly many of your view's just disappear ... "undo" (or just starting over from scratch) is frequently employed. Debugging is a nightmare ... some cases I never figured out:

http://stackoverflow.com/questions/28550692/auto-layout-of-v...

I agree with your assessment, but for certain use cases, I've found it to be pretty useful. Box-based layout forces you to arrange your view hierarchy in a Towers of Hanoi kind of way, whereas constraint-based layout lets you define relationships between free-floating sibling views directly. Here's[1] a little test I recently worked on; the amount of code to do this was pretty small and conceptually simple.

[1]: https://github.com/archagon/ABExpandingViewController/blob/m...

Agreed.

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.

https://designgridlayout.java.net/grids.html

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.

When I first heard of GSS I thought it was the holy grail of layout systems for app (not document) layout. On the surface, and as you mention, with simple examples it is deceptively alluring. However it quickly becomes apparent that the issues with regard to bugs and broken/cyclical dependencies far outweigh any benefits the system brings.

Maybe a hybrid approach would be best? Constraint-based for the broad strokes and then regular box-based layout within these blocks.

My wife and I had a big fight several years back because of photoshop. She was a photographer and she wanted to know the constraints of an image in inches and resolution. I told her that those didn't count for screen use and to just use the height and width in pixels. She had not understood until she googled it and watched a youtube video.

Interestingly, @vjeux specifically preferred flexbox to a constraint solver (cassowary) for react native: https://twitter.com/nikitonsky/status/561941079038390273

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

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 with flexbox.

So I'll pass on similar constraint-based approaches to HTML layout, thanks!

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 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.

> 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 two buttons is eight.

That's almost exactly what designers' specs look like in my experience – screenshots annotated with lines with numbers on 'em.

> 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. :)

>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 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!

Moved beyond grid systems? I can't agree with that.

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.

>Moved beyond grid systems? I can't agree with that.

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.

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.

You're right. The drawing canons are, in a way, constraints.

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.

Designers almost always work in grid systems, not in collections of arbitrary measurements between screen elements. I suspect one of the reasons that Bootstrap has become so popular is that its grid system makes it fairly easy to implement the grid-based layouts that designers typically employ. Things like Bootstrap and flexbox make implementing grids easy. Constraint systems are at entirely too low a level of abstraction for this.

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.

You don't need to use React Native to use flexbox with iOS apps:

https://github.com/robb/FLXView https://github.com/joshaber/SwiftBox

I'd say the percentages are reversed.

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.)

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?

Sass might make it more complex, but after learning it you save an extraordinary amount of time. I also don't find CSS that hard to work with anyway though.

I can't tell if you're complainin about inherent difficulty in this stylesheet language, or just about introducing a new stylesheet language with a learning curve. If the former, I would disagree—it seems easier and much more useful than CSS to me. If the latter, well, any new language or technology has a learning curve, and it's rarely easy to know whether it will be worth learning.

>'cause if you're on my team, i'll slap you

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?)

> Because you're so macho, right? And anything you don't understand shouldn't be used.

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.

Way to overreact to some shallow taunting. You read a lot of things into this that aren't there.

Look at how he/she tacks some feminist pandering onto the end of the post. It's just one step away from accusing the original commenter of creating a hostile work environment.

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).

I thought personal attacks weren't allowed on HN?

EDIT: And apparently calling you out on it leads to immediate downvotes. Wow, this really is turning into reddit.

People don't like meta-discussion. It's not punishing you for calling out someone they like, it's about burying discussion topics they don't want to see derail the conversation.

I did not vote down.

What about your point here?

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.

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.

> WTF is this voodoo?

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.

Tone of comment aside, I do have to agree that that sample is fairly hieroglyph heavy.

Demos were all slightly wrong on Android chrome until I rotated screen at which point they completely broke. Using js to augment layouts with useful functionality is a great idea, but relying on it for core styling is a terrible choice.

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 logs I wonder if non-javascript users just don't even get logged by the javascript-for-everything brigade?

Actually there is oftentimes a static "non js" tracking-image embedded within a <no script>-tag.

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.

tl;dr You get locked (most of the time), but you can block this (most of the time) as well.

A company I worked for years ago actually had an analytics tool they sold that just used a transparent tracking gif. We managed to sell pretty expensive subscriptions way after Google analytics completely pwned its capabilities thanks to industrial companies being strangely un-web-savvy.

How would one block this?

It's typically an image hosted on a 3rd party domain that's on every anti-tracking plugin's filter list. (uBlock, Ghostery, Disconnect, ...)

Thanks. I guess anyone that does not enable javascript is running a anti-tracking plugin anyway...

There are unlikely to be more than about 100 people who would do that, it is just that most of them post here.

Well there is an addon for firefox (no script) that assists with it... I guess that that only has 100 users?

You are a minority. Perhaps not here (HN) because "I disable Javascript" seems to be a pretty trendy thing to say (:P), but in the world at large you are.

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. :)

You don't really have to 'worry' about those things, you just follow best practices and - for the most part - they get dealt with automatically. Following the standards always gets you additional benefits that the "javascript required" crowd always gloss over. As a trivial example (there are many more), using a non-existent fragment identifier as a link target and capturing the click event doesn't just break when javascript is unavailable, it also breaks opening that link in a new tab.

For text and images and videos (which is what a webpage is for after all) if one sticks to a simple html and simple set of css do you need to worry about all those issues? Or do they just go away? e.g could a simple html version served to e.g. screen-reader using users also work for non-javascript using users?

>literally every site uses

Ironic that you would post that on a site that works without it...

You have to make your site accessible to search engines, so as long as you're not doing something weird like using javascript for styling and layout, just treating users who have disabled javascript as search engines should work just fine.

Google has been working pretty aggressively at learning to crawl JS-framework-powered apps lately. I'd still play it safe and serve up HTML when possible, but JS isn't the SEO black hole it once was.

>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".

Yes but that 0.001% are within the influencial 1% of users. I've literally had people see what webpages look like in my browser and then ask for no script installed. I didn't understand why until a few minutes ago but I do now.

>Yes but that 0.001% are within the influencial 1% of users.

No, they just believe so about themselves.

Possibly. I do not claim to have ever driven social media traffic or made a trending hashtag or a viral video or even shared a "top 10 reasons why" article with anyone. However, I do get people asking what devices to buy/what programs to use/how to do stuff quite often.

So in reponse to all the javascript brigade here I just tried to view some websites I commonly visit without blocking to see what I'm mising...

I do not know how you browse with javascript enabled! WOW the experience is poor! My computer is a standstill with two tabs open. Stuff keeps flashing at me. The pages load and then after a few seconds everything gets moved around again. Simple functionality doesn't work as I'd expect anymore (every website seems to be different in how things work). Adverts everywhere (and everytime an advert refreshs I can see my computer slowing down).

EDIT and now (some) videos start autoplaying when I scroll past them. I don't want that!

I watched video of a talk by one of the guys who made this - he said they thought about making a static website generator like jekyll or something which would use the in-browser version to let you preview things live, then they'd have a tool to autogenerate with mediaqueries different versions of the stylesheet for different common screen sizes so you don't need JS. Sounds like a pretty cool compromise to me!

edit: the video I saw is actually that o'reilly video that's linked in the GSS website

> 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...

"javascript should be optional"

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.

I go to the demo, resize the browser window, and the layout falls apart. Not a good advertisement.

http://i.imgur.com/KkxICEw.png

Constraints are the right approach to layout. This should have happened years ago. The important concept here is defining layout like this:

    #elmA[top-left] == "area"[top-left];
    #elmB[bottom-right] == "area"[top-right];

The trouble with this is that it's expressed as a programmer's approach; everything is about variables, not geometry. Constraints should be input from a GUI, like Dreamweaver. To see what this looks like done right, try sketch mode in Autodesk Inventor, where you can draw lines, circles, and arcs and constrain them to each other in various ways. Designers would love it if they could do layout that way, and we could lay off a few thousand Javascript programmers.

As a non-designer, I disagree. I played around with FreeCAD a bit, and I was constantly wishing "just let me enter the damn formula" while messing with those graphical constraints. Or could be it's just implemented badly there...

Newest XCode does this in the right way I think. It lets you do most of the stuff from the GUI (and detects conflicts), but you also have the power to enter constraints manually in the code.

This is coming.

https://medium.com/@almonk/design-like-it-s-1999-48ce5f5be14 https://medium.com/bridge-collection/modern-design-tools-ada...

Version control for graphical objects is rare in the open source world, but it exists in the commercial world. Autodesk Drawing Compare, which is part of Autodesk Vault, is an example. For film and game work, there's Alienbrain. A game has many non-text assets - maps, motion capture data, 3D models - and they all get revised. The systems which can pull all that together can display, and difference, many graphical formats.

XCode does it this way - constraints, but expressed graphically in Interface Builder. It's still a pain in the ass. I'd much rather work with Flexbox than figure out why my iOS layout isn't resizing properly. Even if you get your mental model right perfectly, there's still a large mouse-twitching problem with auto-layout in XCode where it's hard to select exactly which element you're lining up with.

Auto-Layout is the worst. I used to spend so much time trying to figure out why things didn't line up or behave like they are supposed to. Luckily pods like Masonry and Paper make things easier but still, it is frustrating. To have it in CSS sounds like an absolute nightmare.

Autolayout is great once you've spent the first three days pulling your hair in anger.

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.

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".

If your layout system's site looks like complete arse on a major browser like IE, your layout system deserves to be ignored.

+1. Unusable on IE. Screenshot for those not on Windows: http://i.imgur.com/oFoAbAS.png

Looked even worse on my tablet http://i.imgur.com/tP5YSTu.png

Same on Windows Phone. So i guess its not usable for production?

Kudos!

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).

Not sure what you mean that "css is hell", although I understand from working with a lot of programmers (I do front end they do back end) that CSS is seen as something you might also want to learn but not really because it isn't proper programming. CSS as it is now is incredibly powerful and works almost as it should (almost int he way all languages/technology are works in progress).

I can see this (GSS) as having its place amongst a developers list of tools, but ultimately I can't see how it is better than Flexbox, or why I would want to a javascript library to do layout, or who in their right mind would want to pass a project using this on to someone else.

> http://puu.sh/igQ03/9d6f0ffcb5.jpg

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.

That profile card demo completely breaks if you reduce the browser height a bit:

http://i.imgur.com/MLhaheD.png

Perhaps this is why the web uses box-based rather than constraint-based layout.

None of the demos work correctly on safari iOS

Just tried a few demos on iPad 3 running iOS8, works fine for me.

Yes, because the iPad has a large screen. It doesn't work well on iPhone-sized screens.

Yep:

http://i.imgur.com/flVGSe4.jpg http://i.imgur.com/IemE3cm.jpg

I must admit a certain trepidation anytime I hear the phrase, "and replace it with a constraint solver!" Not that they aren't useful and powerful tools. That's exactly the problem, they're very powerful tools. I'm not entirely convinced that doing website layout should require so much computing power.

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.

I found the picture at the top to be a funny reflection of the problems of layout. The bird (I believe that's a cassowary as on the book cover) in a spacesuit is an interesting juxtaposition artistically, but the helmet face plate won't be able to rotate down over the birds beak and seal the helmet. A 'layout' case that the image didn't consider. Layout is hard.

I don't trust a layout engine whose webpage advertising the engine has centering issues... iPhone 5s in portrait does not center the section starting with 'Polyfills' but does so in landscape mode; I'm pretty sure this was not the expected design.

The bottom is cut off as well. Where it says e-mail address and then something else but you cannot see it. Like this idea but this looks a bit bad for someone offering a solution to css bad parts :/

Heh, I'm looking at React Native with Flex Box precisely because of difficulties I've had with AutoLayout.

What is up with that logo? That's a terrifying chimeric space thing that I don't want on my machine.

Lol, I have a post from years and years ago where I rail against 960 gs and the like "grid style sheets" for not being semantic, and about a year ago one of the authors of this emailed me asking me to amend it specifying that I wasn't talking about this. I declined, and went on to comment how the use of JavaScript for layout was even worse, lol. I was a little irritated at the hubris of the guy and may have gone a little overboard.

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

Your response delighted me. It was a good lesson you give him about accessibility and UI.

Could you post it on pastebin?

Its funny that you post that, he comes off a lot better than you in that thread.

> I was a little irritated at the hubris of the guy and may have gone a little overboard.

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.

Reply on news.ycombinator.com