One of the wonderful ironies of CSS is that after years of puritanical preaching about the evils of non-semantic table elements, the best-practice recommendation for centering a div of unknown dimensions, assuming you want any kind of legacy support, is[0]:
One could make the argument that having table layout behavior decoupled from a specific tag is a perfectly desirable state of affairs. One of the issues with using tables for layouts is the massive clutter of row and cell tags that make the markup extremely difficult to read. Being able to assign those behaviors when and where you need them is the best of both worlds.
The irony is that what we are doing, semantically, is "centering." Yet to express that concept we are forced to refer to the entirely unrelated concepts of tables and cells, only because of the historical accident that table elements were the only way you could do many types of centering because CSS lacked basic facilities for layout.
Also, naming issues aside, we are forced to pollute our markup with pointless, unsemantic container divs simply to achieve a basic style on the contained div.
I doubt you understand what the word "semantically" means.
I don't see how polluting markup with <table> (and tables were often nested), <tr> and <td> is any better, not to mention that often already existing markup was sufficient and no extra was needed.
Also, div's by definition have no semantic meaning, and that's a good thing—those who bothered to care know that tables for layout had their share of accessibility issues.
Alas, now when most race to stuff as much anuglar bootstraps ino their SPA nobody cares about semantics and accessibility any more.
I think he's right. The syntax says "display this stuff as a table and a table cell", but what in fact we mean is "center this thing". The fact that both "style as a table" and "center" attain to the visual aspect doesn't change the fact there is a semantic difference between the two.
Also, if divs have no semantic meaning in the context of the document's structure, it means they serve some other purpose: and that purpose is visual styling (not directly but through a css applied to them). How is this not a violation of the separation between document structure and presentation?
It is in principle a violation of the separation between structure and presentation, but it is not a violation of the semantics of HTML which is a bigger issue. Since div's are semantically neutral in HTML, a multitude of "presentational divs" will not confuse screen readers and so on, as the use of <table>-elements will.
That said, separation between structure and presentation is desirable, and the necessity to use multiple divs to achieve a layout effect means CSS 2 is not as powerful as we could want. The grid model in CSS 3 is much more powerful, and allows things like separating the presentation order from the structural order.
There can be reasons for grouping a set of elements in the DOM with a parent div besides styling. But sure, it's a "violation" but web standards do not say "you must only use elements that are essential to the semantic structure of the document." I'd say the guideline is "start with semantic elements, add others as needed for styling, programmatic access, componentization, etc."
Cute, but in discussing the web, its the semantics of the HTML to be concerned with, not CSS properties or values. There are tons of examples of CSS where a naive reading would not suggest the desired outcome. Maybe that should be improved but generally it's better to have the mess there than in the HTML (or JavaScript).
Yes, it's better to have fewer divs that serve no purpose but to create the desired visual effect. As someone else suggested, in your example you probably don't need <div style="display:table;"> so it only requires adding one container div.
> Cute, but in discussing the web, its the semantics of the HTML to be concerned with, not CSS properties or values.
Why wouldn't the principle be applied everywhere? Expressing your intent -- writing semantically -- is a general principle of clean code, and of clear communication in general.
It's fine if you want to argue it's more important in html than in css, but that doesn't grant a pass to the creators and proponents of pure CSS who peddle the ideal of semantics with religious zeal and then fail to apply the principle to their own language, or even to realize that they've failed to do so because, I suspect, many of them don't actually grasp the true goal of the principle -- clarity and usability.
If they did, CSS wouldn't be the unusable mess of quirks that it is.
You are comparing apples to oranges. Semantic HTML is important because it is a publicly defined semantics and various consumers and user agents are programmed against this semantics. Semantics in class-names, the choice of inline styles vs style sheet etc. are purely for maintainability, e.g. you don't reduce accessibility for anybody if don't use semantic class names, at worst you make it more difficult for yourself, but that might depend on your workflow etc.
There is nothing in your response which is an argument against what I wrote. I grant everything you said is true -- it does not minimize my argument at all.
Who are these zealots you reference that demand semantic HTML and have some influence over CSS specs?
What I more often see is people advocating for using semantic HTML, because it exists, and separating concerns (content & presentation). If there was a choice to use CSS properties and values that better conveyed the presentation intent (what you might call its semantic value), they would advocate for that as well.
I think you have the causality backwards though. Tables were used for layout before CSS existed. When CSS was created, it was designed to mimic exactly what was possible to do in HTML, in order to ease the transition to CSS. This is why CSS has a blink-attribute, and why the float and vertical-align properties based exactly on the layout model of Netscapes presentation html (which was defacto standard at the time). Hence the display:table-* properties which mimics the layout of html tables as designed by Netscape.
> I think you have the causality backwards though. Tables were used for layout before CSS existed. When CSS was created, it was designed to mimic exactly what was possible to do in HTML
That's exactly what I said. I think the difference is in our interpretation of that causality: you see it as an intentional concession in the name of backwards compatibility; I see it as a failure of imagination.
Or maybe the ability to imagine the fate of CSS if it wasn't backwards compatible with the HTML layout model :) That said, I look forward to when CSS3 flexbox becomes widely supported. Still I'm happy that we at least don't need presentational HTML anymore.
> Or maybe the ability to imagine the fate of CSS if it wasn't backwards compatible with the HTML layout model :)
You seem to be misinterpreting my arguments -- I'll assume not deliberately. They could have easily provided the same facilities for backwards compatibility of table behavior while also providing clearly-named and usable methods for doing things as basic as centering.
Is your position that CSS is a thoughtfully, well-designed system for presentation, and that the complaints of 95% of professionals web developers are the result of their own misunderstanding of it? Can you imagine taking such a position on user complaints as the CTO of a private software company?
CSS does provide both - the table model from CSS2 provides parity with HTML tables, the flexbox model in CSS3 provides an easy way to center blocks and other nice flexible layout features.
I do believe most complaints about CSS is really complaints about missing and buggy implementations in browsers. For example for years I have seen people complain that CSS is not as powerful and simple as html tables, when the issue really was that Internet Explorer didn't support the display:table properties from CSS2, which meant you either had to use hacks with floats (which was never designed for this) or use html tables. This gave CSS a bad rep, when it really was IE that was to blame.
Agreed. There is a time and a place for everything. If table markup is used nowhere else in a DOM, it is completely justified for easily vertically centering div content (across platforms) no matter what the container properties are.
I don't think anybody considers inline styles best practice. It is however a very easy way to demonstrate a specific layout fragment. Any front-end developer will understand how to extract the styles to a style-sheet.
In any case, there is no irony here. The display:table-* properties is defined precisely to mimic the layout model of HTML tables (hence the name), in order to allow you to achieve the same layout with pure CSS, so you don't have to misuse <table>-elements.
It seems some people have misunderstood the recommendation against using <table>-element for layout, and thinks there is something wrong with table-based layouts. But table-based layouts are fine, and sometimes the only was to achieve a desired effect. The problem is only misuse of <table>-elements for something which is not semantically a table.
Actually, inline styles are a fad now in React.[1] I've been trying them in my latest project, and am loving it; really solves some of my old pain points with CSS. Haven't been doing it long enough to figure out the new problems it causes, though.
Of course such a project won't work with most non-React web projects. Idiomatic React projects tend to have a large number of small components with extensive re-use. (~5 lines of HTML not counting closing tags per component is my metric)
Because it is not a table, it displays in a tabular fashion (for certain user agents).
I always failed to understand what is hard about the _being_ something vs _being displayed_ as something. I have met so many smart people just failing to grasp this simple dichotomy.
For the sake of public education, here is an example from the article. H1 is for (document) titles, and is so used by auto outliners and Google and Pocket. Document titles are document titles regardless of the way your page is displayed (user agent or current style fashion). If you want to display bigger just use "font-size".
I know, right? I even had a designer implement a table of prices for a page with divs, because "tables are evil". I guess he had only heard of the first half of the admonition "never use tables for layout".
So actually, I think you can often skip the wrapper div with _display_ table as an orphaned table cell generated a row and table around it for layout purposes.
Just use flex-box. And by "use", I mean get ready to study it, change the way you write CSS, give it all of your worldly possessions, and eventually collect money for it at the airport.
I thought the css-tricks page did an incredible job of both explaining the concepts and laying out the information in such a way that it makes a great quick reference once you've gone through it.
This is one of those things you really, really deeply have to question. How much money (via dev time) do you spend on supporting such very old legacy content vs the derived value of said customers? Some people DO have that use case, and for them it is their lot to suffer. But that's clearly not he story presented in the link.
Same deal with mobile OS support, really. You have to have a pretty unusual or long-standing audience to support anything pre-4.2, let alone pre-4.0. iOS7 is also probably not worth the time to target for most products.
You see, kiddies, we used to have programs that did all that for you. There was this program called Dreamweaver. You just opened up a design window and laid out the page by pointing and clicking. Anyone could do it. But if anyone could do it, "web programmers" weren't needed. So CSS was invented to make it more like programming, and especially to make it so complicated that it couldn't be done by pointing and clicking.
DRY notwithstanding, I agree with Animats that design should be done visually, not programmatically. Using code for layout is just as bad as programming by flowcharts. Programming tools should reflect how a programmer thinks about the problem, and design tools should reflect how a designer thinks about the problem. Expensive "web programmers" shouldn't be needed for web design, just as "print programmers" aren't needed for print design.
> Expensive "web programmers" shouldn't be needed for web design, just as "print programmers" aren't needed for print design.
You don't need web programmers for web design. You can export from a WISYWIG to HTML, or design a big ol' GIF and post it on Wordpress. Lots of restaurants do that sort of thing.
But you probably want something that interacts with the user, changes layouts based on screen size, provides information to disabled users, validates and submits information, allows commenting and moderation of comments, etc. Eg, a program. And you do need programmers for that.
Why can't the designer specify that? Because the current tools suck for designers (i.e. they were made for programmers).
> provides information to disabled users
Ditto.
> allows commenting and moderation of comments
There should be ready made solutions for that, usable by non-programmers. If you wanna buy a toaster, you don't go "oh, it's an Electrical Device and we need an Electrical Engineer". A toaster is complicated inside, but it was made with good engineering so users don't have to care.
The web is not like that. The needs of most websites are well understood by now, but somehow we still need programmers to make layouts and comment systems. My only explanation is that the whole system of HTTP/HTML/CSS/JS is poorly designed, in a way that's very hard to fix. Name me one other medium where positioning elements on the screen/page/whatever isn't a completely solved problem. Show me a single game developer who just can't seem to get the crosshair centered vertically on the screen.
But unlike print, the web is never not code. There are still people who design for the web making Photoshop comps that they throw over a wall to "web programmers" to make it work but while some say you should design in the browser, most say the designer making comps should have some understanding of what works on the web.
Print designers also have to think about the platform their design is presented on e.g. what kind of color bleeding will happen in the press when an image is used on newsprint.
I'm talking more about the kind of web that we could have, not the kind that we actually got. There's nothing about the concept of "worldwide set of pages connected by hyperlinks" that stops non-programmers from contributing. Non-programmers can already create printed pages (pretty) and spreadsheets (computational), so with better tech they could create the web as well.
This is an example where the headline on Hacker News is 100x better than the original headline. I do wish Hacker News allowed these kinds of headlines, which draw out the parts of the article that are of most interest to the Hacker News crowd.
It'll be a while, sadly. IE8-10 are still up to 25% of the browsers[0] (caniuse puts them much lower, which isn't surprising for sampling dev oriented sites). IE10 (5% of that) needs a different syntax, and 8-9 don't support it. All three support table layout[1], which is why it is still the best solution if you care about compatibility.
I bet she will when she tries to access her website at school. Schools aren't exactly keeping their browsers up to date nor are they going to install alternative browsers. It's important to think about how her audience will access her content. Since she's a student, the first viewing will almost certainly be through a school computer as she shows it off. After that, perhaps less so, but kids like to goof off at school. That's probably when they will be most willing to visit the website.
A dismissive dev's 'legacy' browser, is 25% of actual web users. You can dismiss them as legacy if you like, but there isn't a minimum age before you get told your site sucks because a quarter of people get crap when they load it.
Those versions of IE might represent 25% of web users, but any given website will probably see them as much less than 25%.
I run multiple sites, and most of them have IE (any version) as under 10% of users. One of them doesn't; IE represents ~13.5% of users on that one.
My untested theory about this is that IE users are generally less adventurous web users, sticking to sites like Gmail, YouTube, local news sites, etc.
TLDR: unless you're working on Gmail or a site where you expect to soon see the world turn up at the doorstep, it might be safe for you to mostly ignore IE.
This is true, but when these particular browser account for less than 1% of your traffic then you can make a call on whether it's worth supporting those users. Perhaps that loss is acceptable.
This, of course, is going to be different for every project and website. Each team would need to look at _their_ browser usage stats and make a judgement on what resources you want to spend on supporting the stats that you're going to see.
I agree; that's where it gets a bit tricky. You're not going to have many repeat customers who can't use your product.
You have to either be enhancing an existing product where you know that the segment in question isn't worthwhile supporting, or be prepared to estimate whether that segment is going to be meaningful for you.
Another thing to keep in mind is that sometimes the result isn't a deal-breaker. Suppose I try to get vertical centering working on one of my sites using flexbox. Perhaps the 5% IE users simply see the content of each div at the top rather than being vertically centered. Not ideal, but not the worst possible outcome, either.
Out of interest, does anyone know how flexboxes break on IE if you try to use them for vertical centering? Does the content actually just sit at the top?
The problem is that 25% of your customers could easily represent 100% of your profits. So by the time you're done with all your fixed costs and still need to turn a profit having a few % more or less users may make the difference between a company that will succeed or one that will tank.
That's why any commercial entity will be very wary of closing the door on paying users no matter how old their setup is.
Yes, if you center vertically with a flex-box, and you aren't doing anything weird with margins or overflow, and that's the only thing you do with it, you'll get non-centered results on IE8-9.
Not a problem.
But if you're only looking for that, then it seems very churlish not to use table layout, since that is the same amount of CSS and works in IE8+. There's no excuse for breaking layout in a browser if the alternative is just as simple and has no downsides.
Once you need to use flexboxes for more than vertical centering, it can cause more problems. Using it in place of inline-blocks, for example (one of its useful applications), can leave your content very weirdly laid out on older IEs.
The market share varies dramatically by niche. If you're running sites aimed at developers, you'll get very different results to a site aimed at teens on mobile, or one aimed at large blue-chip corporates.
Supporting IE < 11 shouldn't be a technical decision, I'd say. It is simply not technically difficult to do (outside of a couple of very niche web technologies). It is a business decision. So, you need to ask the CXOs if they're happy to leave those customers to your competitors to save you however many hours of dev and testing. There's a point where the answer will be 'yes'. Mostly we've passed that for IE6 now, but not always. I'm aware of one company targeting government clients, particularly in the developing world, for whom IE6 support is essential.
They are using a modern browser. Modern => something that was produced in the last couple of years.
That the computer industry still can't get stuff right and forces users into an upgrade (which may or may not work, could quite possibly lead to a borked browser or even a totally borked system leading them to have to 'upgrade' to a more modern operating system, which in turn may require them to shell out money for new hardware) is no reason to push the responsibility for the laziness of web developers onto the end users.
And if they can't upgrade, or won't, or don't want to, or don't trust you to tell them to install something?
We went through this years ago with IE6, there were always plenty of devs with variations of "screw 'em", but blaming or penalising users for their set up is a bit of a dick move, and shutting out or inconveniencing a big chunk of potential market is not a good business strategy.
There does come a point where the cost of supporting a browser exceeds the value of the people using it, but I'd be surprised if most sites have hit that for IE8 (the third most used browser, more than twice the market share of the most used firefox).
Really? You don't think his kid's peers might not have the latest IE at home? Lot's of them will be on mobile, true (though some of them will be on Android's pre 4.4 browser, which also doesn't support it fully), but if they want to check from school, then school machines are neither likely to be the latest, nor the most diligently updated.
I wasn't trying to be a smartarse, I wish flexbox was usable. But IE < 11 is still a very large player.
It isn't a very large player. Most websites will not see anywhere near 25% of IE < 11, even though that may be the global distribution. Even some of our most conservative enterprise clients have upgraded to IE 11. I'm not entirely sure how Microsoft pulled this off, but I'm impressed at how quickly they are pushing everyone to a modern browser.
If you start a new project today, there is almost no reason to care about IE < 11. By the time you get enough users that IE itself becomes a sizeable number, I am willing to bet that IE < 11 will be around 5% of users on the high end.
now just put it in a relatively positioned container and you're done. i thought this was common knowledge by now, i haven't used `table-cell` in years.
Follow-up: Does anyone know how to best host this site?
a) with less than 50 users all-time
b) easily updated daily (blog-style) by a 7 year old
c) is approximately free
Wordpress with her custom theme seems to fail C.
Github pages / Jekyll is failing B
I responded to you on Twitter but I would go for Tumblr. Easy to maintain, and makes it very easy to publish media-heavy posts...which, even if your daughter is the next J.K. Rowling in terms of enthusiasm for the written word, Tumblr hits the right mix of decent flexibility and dead simple UI. I maintained my own Wordpress site but ended up posting much more frequently to Tumblr.
I now am basically 100% Jekyll and Middleman...but having tried teaching Github Pages to college students...I'm skeptical that it's easy enough for a child to hack around with and get the same amount of enjoyment and productivity that she would out of Tumblr or WordPress.
(Apparently Ghost is pretty good too but I've never tried it)
Livejournal is still the best for writing posts and having discussions on. Takes no effort to keep going, and has threaded comments, supports images and videos, and basically just works:
display:table and its kin are the greatest thing I ever discovered in css. No more centering problems and easy to reason about. I'm not sure if people just don't know about it, or there are use-cases where it doesn't work for them. I'll definitely use Flexbox when its more widely supported, though.
They don't wrap when their parent container shrinks, but sometimes that's the behavior you want (navigation bars for example), and media queries get around those issues nicely.
I love "display: flex" so much. I'm working on extensions for modern browsers, so I can use it everywhere. Makes everything so much easier. Also cases where you would normally use ".left { float: left; }" and ".right { float: right; }".
Why isn't this actually an easy, obvious part of CSS? It doesn't seem like there is anything that makes this more complicated to implement than anything else people use daily... it's also an obvious feature. Reasons?
If you know the height of your centered box, it's not that hard. Create a wrapper div whose top is set 50% down the page but has a negative offset which is 50% the height of the box:
.vertically-centered {
position: absolute
top: 50%;
height: 200px;
margin-top: -100px; /* minus half of `height` */
}
If you have trouble, try setting `height` to 100% on the <body> tag and any parents
Actually, it used to be called Frontpage. It was pretty workable, but if you were able to figure it out, you were probably better off just learning HTML and CSS anyway. Creating anything beyond a really basic table layout was pretty maddening, IIRC.
The typical problem with WYSIWYG webpage builders is that the web is not a printed document. If you don't know the underlying concepts of layout you expect things to behave much differently than they actually do. Or at least, that was how it was for me.
A copy of Frontpage in middle school is what got me in to programming, back in the day.
One of my earliest memories of 'coding' (It seems silly to call it that now, but hey, I was 13!) was opening the generated html files to remove the "Created with Frontpage" html comments that were automatically injected.
CSS is about presentation, not semantics, that's the point of it. And the whole point of separation of concerns.
So sad to see stuff like http://csszengarden.com/ being forgotten and the whole web standards movement coming to nothing.
