...the only thing I really need to say, is that every couple months, on Hacker News, where a lot of really smart people hang out, a new top-voted story comes up about how to center a div. With tons of comments and discussion too. And it's not even a joke.
What more is there to say?
Those two faces are because of two simple facts.
1. CSS is a really good way to set properties.
2. The properties are shit.
The part of the properties that is most gloriously broken for layout is that the X and Y dimension behave differently. That's _really_ not what a lot of websites want.
I experimented a while back and came up with a model for placement like this
http://www.fingswotidun.com/gunk/boxtest.swf
If you had properties like these you could center, proportionally center, left/right/top/bottom align and handle growing in the direction the user wants.
What CSS needs is a new generation with all new properties, a full modal change so that it doesn't have to be backwards compatible and interact with archaic properties.
It feels like it is a solution directed at specific problems, whereas I always felt that was much of the problem with CSS properties. They solved their target problem and if your problem was different to their one you might be out of luck. If the properties were defined to be more general I think a lot of those problems would never have appeared.
#div[center-x] == #container[center-x];
Floats were meant for other stuff (placing pictures in the flow of text and such). They are just as much as an abuse as using tables was for layout.
But tables, at least, had one thing going for them: they are an almost feature full layout system for most needs, with sane defaults, and familiar (from all grid layout systems) behavior. So both CSS and tables were abused for layout, but at least with tables they picked something appropriate to abuse.
Now, finally, CSS has some extra functionality (flexbox, multi-column etc) that was added later as specifically intended for layout. Which, of course, is not fully supported and implemented yet.
Btw, the whole idea of "semantic html" is another cargo-cult -- people conflating the webpage (a presentational output) with some intermediate format, forgetting that REST, JSON, DBs et all are far more appropriate for that repurposing of content.
Basically a bunch of designers who knew nothing about computer science, taxonomies, RDF, etc, thought it would be very sophisticated to adopt this "semantic" word. So, they started building pages caring about the naming of elements and such, as if webpages are meant for screen-scrapping (some hand waving always included support of "reading devices", who nobody of course ever tried to actually test with his pages -- they'd found out they're specially adapted to work with regular noise webpages).
The nice thing about semantic HTML is that any metadata and structured data is a part of the document itself instead of hidden away somewhere else through an API. This has its disadvantages (I'd rather interact with an API than scrape a website, even if it's all tidy and semantic) but it absolutely also has advantages. The usual alternative to semantic HTML is not a well-designed API, the alternative tends to be nothing.
Sure, but nobody called for "a dozen nested divs". You can ease the same number of divs, semantically or not. Just make the styling targets are encompassing as they can be.
Which is neither here nor there regarding the validity or not of what I say, and a little rude to boot.
>The nice thing about semantic HTML is that any metadata and structured data is a part of the document itself instead of hidden away somewhere else through an API. This has its disadvantages (I'd rather interact with an API than scrape a website, even if it's all tidy and semantic) but it absolutely also has advantages. The usual alternative to semantic HTML is not a well-designed API, the alternative tends to be nothing
Which is fine too, since the usual case also is that nobody is consuming the raw html anyway except the browser.
Exactly right. The semantic content is structured data, not HTML. If you want to decouple semantic content from presentation, that's what your API is for. HTML is a presentation format.
HTML is a MARKUP format. The document you're meant to read is it's rendered output in the browswer.
In fact the original TBL's HTML vision included tools to work on the HTML, not manually editing/reading the code.
http://inspectelement.com/wp-content/uploads/2013/03/Q3cUg29...
To be fair, the majority of comments tend to either be ones like yours, or ones elaborating on the "CSS is somehow well-designed" front.
As others have noted, tools like flexbox make what the article is trying to accomplish easy. The issue is that lots of users run really old browsers, so if you want a single solution across your user population, you're going to have to resort to the same really old hacks.
It's silly to say that "nothing has changed", when what you're really saying is "nothing has changed in the browsers that haven't changed". I'm not sure that should be surprising.
[1] It makes it 'easy' by introducing yet another weird box modelism that doesn't really fit anything else that's already there. It's really as much a symptom of these problems as a solution, imo.
- CSS 2 was originally published as a recommendation in 1998. CSS 2.1 was pushed as a recommendation in 2011. Maybe something was wrong?
- "Ignored by vendors" is a bit of an understatement, because your "close to 20 years" includes 5 years of the vendor with 90% marketshare not releasing anything at all.
- FWIW, what became flexbox was useable (assuming polyfills aplenty) in Firefox and Webkit browsers 5 years ago[1]. It took some time to standardize, but while frustrating in the present, it's ok to take time to make sure the spec works, because it will be (in theory) around for quite a while.
> It makes it 'easy' by introducing yet another weird box modelism that doesn't really fit anything else that's already there
What many people don't appreciate about layout in general (and WRT to the web, dynamic layout in particular), is that it turns out to be difficult (and sometimes extremely computationally expensive) to implement an expressive layout system that does what we intuitively think it should. A good example is word wrapping, which is easy to tell when it "looks right" (at least to a trained eye), was done by hand by many when printing was done more manually, but turns out to be difficult to assign a metric that handles all use cases, especially when you're trying to be computationally efficient.
Web layout is like a whole set of word wrapping requirements, expected to get along and paint a page in real time. The process that birthed CSS is nowhere near what you'd turn to if you wanted to develop a cohesive styling whole, but it's how history usually plays out. If it's any consolation, I personally don't think there's a comprehensive theory of everything for styling anyways, so there are always going to be aspects that need to be learned, not inferred.
In any case, flexbox is pretty straightforward if you spend an afternoon with it, just a constraint-based layout system that maps pretty well to how you would describe a layout like that.
Well yes, that is exactly my point. It's not like the desire to center things vertically came about a mere 5 years ago, it was a thing that people were doing in 1996 when CSS was first propagated.
I don't really get your point. You seem to be arguing that people shouldn't have been frustrated for the last 17 years by CSS' inability to do basic and non-novel tasks simply because it's starting to become possible now.
> You seem to be arguing that people shouldn't have been frustrated for the last 17 years by CSS' inability to do basic and non-novel tasks simply because it's starting to become possible now.
The standards process is frustrating. For the CSS working group in particular, there was until relatively recently a stubborn clinging to monolithic CSS standards even with nearly a decade of evidence that holding up everything people agree on until people agree on everything is not a winning strategy. That's how you end up with being unable to center a div for so long.
Flexbox's particulars aside, however, my point is that there is a difference in kind, not degree, between "trying to express this in CSS makes me want to murder the universe" (the case in 2008) and "this thing does not work in a browser from 2008" (the case today). If your point is that it's taken a ludicrously long time to get there, I don't think you'll find anyone to disagree with you.
I don't see the GP comment saying that, what are you respondng to?
It's unbelievable just how annoying CSS can be for seemingly simple things.
So I think I'm agreeing with you.
Where I work at the moment I'm required to comply with WCAG2 AA at a minimum.
I just hate the part where they act like CSS is a good alternative in practice.
I think you're right there. When I've set colours, fonts, etc in CSS it's always worked first time, but getting layout right it feels like I'm fighting against the system all the time.
I wonder if it wouldn't make sense to build a tool that abstracts out the layout part of CSS? I once built a tool in python that lays out Tk/Tkinter GUIs[1] which I may have a go at adapting to produce CSS/HTML output.
XSLT was interesting in providing some of this kind of restructuring power, but was far too heavyweight for pure layout manipulation.
Of course, this is also what flexbox tries to do and I think we'll be groaning about its lack of relative power in this area in the future when it's more established. It feels like a bandaid to me.
<html>
<head>
<title>Testing making a footer with CSS</title>
</head>
<body>
<div id="divpage">
<div id="divcontent" style="overflow: auto; height: 60%;">
This is the content area.
</div>
<div id="divfooter" style="overflow: auto; height: 30%;">
This is the footer.
</div>
</div>
</body>
</html>Whereas what I instinctively want to do is something more like a conditional absolute positioning. If the content fits above the fold, then have the footer absolute at bottom:0. Else, have it relative to the content div. It can be done in JS of course, but I feel it should be a lot easier to do in CSS.
The LOC just grows exponentially, when you approach 100% non-quirky cross-browser uniformity.
I will say this; CSS is a great lesson in humility for every hacker and programmer who try their hand at it. And you can learn a lot about someone by how they describe CSS and the front-end developers who make a living working with it.
Using CSS and JS you can do the same thing, respond to events and re-position your elements.
The problem is, people get preachy about how you shouldn't use JS for this, because websites should be progressive and degrade gracefully. Native code doesn't have this problem as much as it's not only accepted, but viewed as cool when you only support the latest OS version (iOS7).
I do like UI programming, but like many of us I am a bit lacking in the design area.
Native toolkits allow me to ramp up pretty quickly UI thanks to components and layout managers. When something is missing I can drop down to pure graphics programming.
With web designs, it doesn't matter how much I try, without the help of a designer guy on the team, I always end up hacking around until something kind of works, repeating it ad nauseum for all required platforms.
Does anyone have an alternative to CSS that tries to take on a problem this big?
(not trying to make the case for CSS being good)
I'm pretty good at CSS I suppose, and it's not something you can learn logically and progressively. You have to learn all the weird nuances and quirks of it as well as the syntax.
EDIT: speaking of CSS, if you want to know true pain and nothingness, try making responsive emails that look good at three sizes on several clients in CSS.
position: absolute;
top: 50%;
transform: translateY(-50%);
Translate is processed at the end, meaning it is based on the final element height. This means it works with any element, even dynamic heights. Of course it only works on relatively new browsers, but translate is well accepted and on the path to being ubiquitous. The style is also easy to understand and isn't hacky.
I think the parts of CSS that are designed are well designed (considering how hard the problem space is). However, lots of CSS just wasn't designed at all. It was just everyone throwing in their conflicting specs and implementation without any coordinating. But that was pretty much all of the web. All things considered, I think we're not too bad off considering how crazy things were in the early days.
Also, any time anyone complains about CSS, I just show them some pre-css code with `<font>` tags and `bg-color` properties and insane tables. That gets them to shut up pretty quickly. :)
Nothing is insane about "tables". It behaves as a classical grid based layout system, even though it was not intended as such. That's why it was such a good fit.
As for the "font" tags and bg-color properties, nothing strange about them either -- at least nothing worse than a style="" tag. Besides, that's the formatting part, which CSS is quite good add, we're talking layout here.