Comment by mcgwiz | Hacker News Reader

Comment by mcgwiz | Hacker News Reader

Parent Full thread

Let's clarify the question.

"Does anyone have any insight as to why vertical centering of dynamic-height content is the way it is?"

Yes. The original standards committee created a layout model (block, inline, and inline-block elements) that (they felt) adequately balanced language complexity with features. It's easy to idiomatically achieve vertical centering. http://jsfiddle.net/aMMxj/10/

"Does anyone have any insight as to why people that code CSS complain about it so much?"

This is a much deeper question, but one that I think is far more informative. Having done front-end engineering for 10 years, across industries, and in very pricey and exclusive consultancies, I have never found another engineer who had read the bulk of the CSS spec, or even a book about it, for that matter.

Developers, the ones with the mind and experience to bring technical discipline to CSS and create a set of idiomatic patterns (both low-level and high-level), treat CSS as a second-rate citizen. The bulk of the rest of the CSS userbase consists of visual design types (coming from print or graphic design), where the tools of the trade are physical pen and paper, or something from Adobe Creative Suite. The remaining portion of the userbase are equally non-technical hobbyists.

This is the real problem of CSS. Those that have the mindset to devise idiomatic conventions to the community don't think the language is worth it. At best, you have semi-experienced developers duct-taping various non-idiomatic ideas together and giving it a fancy name.

"It's easy to idiomatically achieve vertical centering. http://jsfiddle.net/aMMxj/10/ "

that solution

1. only works for text, which is part of eranation's rant.

2. only works if you know the exact height of the container.

3. isn't even centered: http://i.imgur.com/lz8Mq.png

1. Not true. Could have been an image, or even SVG element http://jsfiddle.net/aMMxj/55/

2. Fair enough. It would be nice to be able to set line-height to a percentage of height.

3. Bug, my bad. http://jsfiddle.net/aMMxj/51/

It's still not precisely centered. Check out this version using a table.

http://jsfiddle.net/nJy8t/

I added a background image with a grid that extends 80px from top and bottom. There's also a small margin/padding/border reset and doctype just to make sure defaults and quirks aren't messing with anything.

Yeah, I concede mine wasn't pixel-perfect.

To continue down this path of the "natural" way to vertically-center, font-size must also be explicitly set. This works http://jsfiddle.net/nJy8t/3/ . Though it's certainly not without it's flaws (we lose font-size cascading).

Your argument might hold more water if your example actually vertically centered anything.

It's 2013 and it's still in many ways easier to do pixel-perfect, scalable layouts using tables than it is with CSS. It's so bad a common CSS 'layout technique' is to force elements to be laid out like table cells! I find that incredibly depressing.

Many of those so-called 'idiomatic conventions' that you blame developers for not devising are avoided because they're needlessly complex, easy to get wrong, and hard to maintain. Nobody likes having to wrap every piece of content in 3-5 nested divs/spans with complex style rules applied to them.

You're right, I had a bug: http://jsfiddle.net/aMMxj/51/

Idiomatic solutions, by definition, cut out the non-semantic document structure. Certainly you will find layouts that cannot be achieved idiomatically in CSS, just as certain software patterns are more idiomatic in one OO language than another (e.g. observer pattern in C# vs Java). But the more scenarios you attempt to address with the language, the more complex it becomes. It's quite possible that extensions to CSS would open it further to the criticism that it's too complex.

Unfortunately, browser vendors do not support any other stylesheet language. Perhaps if this were different, there would be more effort to understand stylesheets from an engineering perspective. Since it's not, we're stuck with poorly-thought conventions and a community that's been trained to despise the language.

CSS is not a happy language, that much I'll agree with. But I find it no more painful than other computer languages. I reassert the lack of rigorous analysis by CSS users and the collective community as the main solvable problem. I have worked at extremely pricey consultancies, and the only thing I learned about CSS from them is that the more senior of a developer you are, the less respect you have toward CSS as an engineerable technology.

genuine question as a non front end engineer- do you recommend reading the CSS spec as a reference guide? im basically asking whether someone learning to be good in CSS should read the spec or pick up one of the recommended books (that appear from time to time on HN).

For example, i never had to read the spec for ruby to get jruby to work.

Does ruby even have a proper spec?

yes - http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_...

there are other community-driven sources - like RubySpec [1], etc. but this is the (expensive!!) ISO standard.

FYI - I had intended it as an example. I'm really interested to know if the most effective way to work with CSS is to understand its spec... which is not the way it works with most programming languages.

But perhaps CSS is more similar to a rulebook (declarative) than a language.

[1] http://en.wikipedia.org/wiki/RubySpec

I think generally speaking, reading the spec is useful when trying to figure out the details of more complex topics, I think this holds true for most languages. I used to pull out the C spec regularly, and even the c++ draft spec on occasion, it gets better for smaller languages, for Scheme for instance, I would pull out the spec rather quite often.

Since I imagine the CSS spec is relatively small (compared to say C++) I imagine it would be useful for solving more adavnced use cases.

I'll admit I haven't read the CSS spec, but I have been reading the canvas element spec in detail, as there's little good, deep reference material for it. It's readable, or at least understandable, but it's challenging compared to more traditional reference books (like MDN's presentation, for example).

There may or may not be Great CSS books out there, but in 10 years, I never found any. They invariably teach you recipes, but not how to to think in the terms the language was designed.

The ruby community is one of the most active and rigorously analyzed in contemporary programming. Blog articles are well vetted, and Google search can reliably point you to decent articles. Further, ruby belongs to a class of languages (interpreted, general purpose, imperative/OO) that is very well understood. Languages from this broader ecosystem include python, perl and even JavaScript, all contributing to a deeper analysis of each.

CSS is a stylesheet system. There are no other popular systems in use. The comparison could be made to Microsoft Word's style system (which has a very different conceptual model). Such a comparison could yield interesting ideas. But such a comparison is never made. Other stylesheet languages for structured documents include the unknown FOSI and DSSSL. When was the last time anyone cited those referenced in a blog post, tutorial, or book about CSS?

I'm not saying the specs are a good teaching device either. But teaching and precise description are different ends. Regardless, because there doesn't exist a good community (incl blogs, books, personalities) to fall back on, the specs are your best bet. Ultimately, they (along with other implementations) are what inform browser implementations.

Would you consider writing a post that explains the high-level (conceptual) differences between CSS, DSSL, FOSI and Word?

Reply on news.ycombinator.com