CSS Absolute Centering
codepen.io
codepen.io
It feels like to me, and someone please tell me why I'm wrong, that the amount of hackery that goes into making webpages look the way web designers want them to is astounding. I google for solutions to various problems and the top rated comment on StackOverflow says "...there isn't a good way to do this in CSS, but here is this hack...".
I feel like somewhere in the universal programming ether there exists a beautiful unification of HTML, CSS, and JS that doesn't rely on any ugly hackery, and it's just waiting to be found and start a brave new world of web programming...
It's why it's so frustrating when people treat front-end design with disdain as something trivially easy. Of course, if you only decide to serve the newest version of Chrome and Safari, it can be easy to remember that there people out their who don't - or can't use them.
It's web development you're referring to.
The people writing production-ready HTML and CSS were known as "web developers" or "client-side/front-end engineers".
Edit: since you are a new developer, let me add that "ugly hackery" is what you quickly arrive at once you start doing anything of reasonable complexity (read: stuff that's actually useful). Handling the edge cases is what consumes most of the code in real production applications, and this is conveniently omitted from the beautifully clean code presented in tutorials and examples.
Some material:
http://www.raizlabs.com/blog/2006/09/25/ten-reasons-why-css-...
The user gets what they want, the designer gets what they want, and the only people unhappy are some purists.
why? what about this is wrong?
I do agree though that it is a pain when something is easily achievable in tables but doesn't work in normal CSS. Vertical alignment being one of them.
What does annoy me is when you see people creating "CSS table" systems. I'm not being funny but that is just plain stupid. I saw a whole project dedicated to replicating the behaviour of a table.
I started developing when tables were fine to use for all layouts and I feel CSS was adopted as a layout too early without some very basic things being answered.
Unfortunately the real world hardly ever works like this.
Also remember that not everyone views the web in a browser. Having well structured markup helps those that use screen readers or alternate methods of browsing the web.
I don't think this is true any more than "good print design and good postscript go hand-in-hand".
I don't think tables are the right way either, but they're too often the pragmatic way until CSS gets dramatically more expressive.
The "restraint" you're talking about is not something designers should have to accept —- not least because CSS appears to be being developed with insufficient concern for what designers would actually like to be able to do. If it wasn't, vertical alignment would have arrived long ago.
The HTML table model has evolved from studies of existing SGML tables models, the treatment of tables in common word processing packages, and looking at a wide range of tabular layout in magazines, books and other paper-based documents.[1]
It was only later when table layouts began to be discouraged.
[1] http://community.roxen.com/developers/idocs/rfc/rfc1942.html
It also makes it far harder for other user agents to make the design fit in small spaces: many table based designs are completely unusable on mobile devices for instance. While the alternative might still not look nice in such an environment, it is more likely to not be completely impractical to use.
Of course if you are presenting something that naturally fits in a tabular structure, tables are the thing to use as that is what they are designed for.
Right. Purists like blind people who access your site with a reader, and Google's page crawler.
You can get away with using "display: table-cell;" and the like inside components that are independent of responsive requirements, though.
Sometimes I wish I could get back all the brain cells that I've wasted on the hundreds of "little tricks" you need to know to get things working -- and then working cross-browser.
Short answer: CSS is just a horribly, horribly, terribly badly designed language. It's the absolute worst. Don't let anybody tell you otherwise. It's that, it's what we've got, and it is awfully powerful in many ways. But it's complete rubbish in others, which include a lot of incredibly basic layout things.
I can tell you that I'd much rather use CSS than Android XML layouts, or WPF, or adding layout containers a la Swing or AWT. It's simple, easily understood across disciplines, and very powerful. Elements of a pretty well designed system.
Flexbox isn't the answer either. I had high hopes for it and I'm in the middle of redesigning a web application UI using Flexbox for layout, and I still can't do some basic things like have an overflow:auto content area that expands to fill the space between a fixed left-hand nav panel, a variable-height fixed header, and a fixed footer. I'm still stuck with a bunch of javascript and a window.resize event handler to measure some heights and adjust the sizes of my containers. Maybe the upcoming CSS grids will work, but it'll be another couple of years before support is wide enough for me to use them.
EDIT: I also wanted to say that I've learned xaml in the past few years, and that's absolutely not the direction I'd want CSS to go.
On the other hand, it's 2013 and we're still trying to figure out how to center one element inside another.
In some ways, we are trying to apply desktop application design paradigms to something that started document or content oriented.
Which is exactly the problem. Web development today is a Turing tar pit, because we're using tools that were originally created for very different purposes. HTML is great for static documents, and lousy for apps. Javascript is great for attaching dynamic behavior to widgets, and lousy for large-scale software projects. CSS is great for consolidating style information, and lousy for layout. Yes, after over a decade of hacking by many smart people we've built up elaborate frameworks that sort of do what we want most of the time, but I wish we could have had more appropriate tools in the first place and been able to spend those resources elsewhere.
However we did have that (Java applets), and they didn't take off. I think the web did hit a bit of a sweet spot at the time, but it's time for us to build new technology on top of it. Personally, it's looking like asmjs, inline styles and translate3d divs to me :)
100% this. CSS is a very powerful tool if you know its quirks very well, and there are a lot of quirks. I know a lot of incredibly talented developers who can pick up any programming language or technology in no time at all, but still occasionally waste half a day circle-jerking with CSS trying to make it do something incredibly simple like center one box in another or baseline-align a couple of pieces of text.
A lot of people who are shocked with the complexity of CSS aren't saying this after switching from another better GUI environment, they're getting into visual apps after doing backed work.
CSS is not perfect but I'll take it over previous presentation idioms any day.
You're on. I pick QML.
When the committee responsible for CSS started working in the late 1990s, it seems to have lacked any members who knew anything about layout. Certainly, the browser was a new challenge, but automatic layout engines had existed for decades by that point. TeX, for example. While it is a beast, I have usually found it far easier to get its glue-and-boxes model to do what I want than wrestle with CSS.
To make matters worse, the CSS people considered it a badge of pride that CSS lacks programming features. Allow variables to represent colors so we don't have type #f0c450 all over the place? Nesting constructs? Perish the thought!! That would make it look like a programming language, with scopes! As a result, we now have LESS and Sass which plug up the worst holes, but do nothing about the fundamentally brain-damaged layout model.
For example, centering in CSS is trivial if you're only doing it for one viewport size, font, font size.
CSS has boxes, more or less. It does not have glue in any meaningful way, i.e., it does not give a direct way to specify what happens in between the boxes. Pretty much all the things that are difficult to do in CSS have to do with the difficulty of describing what happens in the negative space.
CSS doesn't really have vertical positioning within arbitrary boxes, which is insane if you think about it. This shortcoming has nothing to do with viewports or fonts or whether it's screen or paper. After all, the rule "box B is to be vertically centered within box A" is not dependent on a particular medium such as print or screen. The rule "box A is to be 100 pixels tall" adds medium-specificity, but that's different.
Rather than providing rich high-level rules to create simple, responsive layouts, CSS makes one jump through hoops to accomplish trivial things like vertical positioning, and gets mired in finicky micro-details and a cumbersome, inflexible layout model. It breaks down quickly; for example, only recently, with the introduction of "box-sizing: border-box", has it been possible apply percentages to box sizes that have padding. (Before, if you had two boxes with "width: 50%", they would wrap if you applied padding.)
As an aside, I am personally not convinced that the CSS promise of separating presentation from content has paid off. In any serious web app, the DOM is visual, and separating CSS from the DOM makes no sense. It's useful as a way to organize code and to share style rules, to be sure, but those benefits don't come from content/presentation separation. I wish we had an inverted model — a visually oriented language concerned only with presentation (think SVG, only not limited to vector graphics), with a separate data language concerned exclusively with data.
I'm talking about things like the way "floats" transformed from a way of wrapping text around pictures (good) to a general-purpose layout mechanism (disaster).
About how there's no way to put a footer at the bottom of your page that stays at the bottom if your content is short, but gets pushed down if your content is long (the normal desired use case).
About how the only way to get two columns of equal height, but that expand to fit the text, is to use a <table>, but that this is supposedly disallowed because it's "unsemantic".
About the complete disaster that float-clearing is, yet how it's central to almost all modern CSS layouts, and fixed only by bizarre byzantine hacks like "clearfix", overflow:hidden (which breaks other things), or the classic "<div style="clear:both;"></div>" which needs to be peppered throughout HTML, negating the whole supposed distinction between HTML and CSS.
And finally, the fact that the width of an element doesn't include its border and padding, making for nesting div's that include border and padding much more difficult than it should be. (Although this is, of course, fixed in newer versions of CSS.)
In the end, it's not really "current language features", but mainly the disastrous decision to adopt floats as a basic layout concept, instead of grids/columns/etc. (Which is, of course, why so many people wind up using <table> in the end, which has its own problems...)
This is incorrect. Using display: table and display: table-cell allows you to achieve equal height columns.
This is probably why the woefully layout-inadequate CSS had to include these hacks to mimic table behavior.
So, it's more like CSS is fooling nobody.
In other words, instead of being able to write any of these
padding: 0 0 0 0;
padding-top: 0;
padding: 0;
If you could only have one mechanism, and you weren't going to lose significant functionality, it would have to be the longhand padding-top, padding-bottom, etc., set.
But I think having the shorthand rule is worthwhile.
The reason I chose the first example over the second is that, if you only ever specify padding-bottom for example, what are the default values for the other unspecified padding properties? This is why we have the CSS reset technique and normalize.css (more hackery).
I would make it mandatory that you declare all four values for the padding rule to remove any ambiguity. That would also mean eliminating shortcuts like
padding: 5px 10px 15px;
padding: 5px 10px;
I forgot that padding required explicit "inherit".
So, bottom line, yes, it would seem to make sense to just have the single-line complete version:
padding: *w* *x* *y* *z*It doesn't make much sense with "padding", but for something like "border: red solid 2px;", how do you override just the color if you don't have the individual components broken out?
padding: 5px;
padding-bottom: 10px;
padding: 5px 5px 10px 5px;Meanwhile, CSS is still a well-designed language in terms of syntax and principles. We just need a few more features that weren't in the original spec as new uses for the web emerge.
[1]: https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Flexi...
On the contrary, it's the box model that's horribly designed. CSS is quite excellent.
We're long past the days of web pages being simple hyperlinked documents, but the browser's layout options haven't evolved quickly enough.
16. When your language is nowhere near Turing-complete, syntactic sugar can be your friend.
Usually developers try to find a way to solve the problem because they are engineers and that is what engineers should do. HTML, CSS and JS wasn't invented to what it has become today. It has evolved thanks to people like you and me who has find ways to use to our advantage. Example AJAX was existed since dark ages (IE5+) but no one used/knew about it. Google used that in google maps in 2004. Now, pirates are using it in usenet/torrent applications (utorrent, sabnzbd, sickbeard etc), or 3d rendering in the cloud (http://home.lagoa.com/).
If you are waiting for something better to be found, i think you will have to wait long time. There is nothing on horizon that is as simple as HTML.
For me, hardest part is in the web development is to deal with designers and product managers.
I get it that HTML is supposed to be for content, CSS for layout and JS for programmatic logic, but the house of cards, duct tape, bailing wire and chewing gum that goes into making a web application is astonishing.
I almost think it would be easier for somebody to come up with an entirely different "web application/dynamic document layout" technology stack with a sane and well-working model all the way through, so that stupid basic things like vertical alignment don't go unfixed year after year after year and we end up with the teetering tower of hacks we have today. We pretty much know what we want out of the web, somebody should just go build it from top to bottom all over again and throw out the huge train wreck we have to deal with today. Sure it would take a while to catch on, but I bet a more efficient set of tools and display environments would rapidly catch on.
We've done it before and replaced older broken technologies with newer, why not do it again?
Yes, but if someone managed to create a logical, concise Web publishing standard that was something other than a can of worms, it would be a proprietary system, most likely patented. Which means no one would voluntarily adopt it.
The advantage of a public, open-source, no-one-in-charge system like we have now is that it's collaborative, democratic, and free. That's also its disadvantage.
For a classic counterexample, look at Apple's products -- they create much more consistent and usable products than the rest of the marketplace. But as many have said, Apple is a walled garden. If an Apple product happens to do what you want with no changes, then fine, otherwise you're out of luck.
Freedom is messy. Democratic technology seems always to veer toward chaos.
Like Guido Van Rossum in the Python world (with the title "Benevolent Dictator For Life"), who seems (so far) to manage his power well. But I think this is a rare exception to a well-known rule about arbitrary power.
The W3C isn't a town hall, it's more like the UN. At best they prevent the web from going back to the chaos of the mid-90s.
That is to say, it's not possible to create any conceivable layout with CSS alone. It might be possible if the thing spits out Javascript as well.
It was called Flash. Or Java applets.
See history.
See this well trafficked "CSS sucks"-type article, Ctrl-F the comments for John Nagle, be tantalized at the hints of how it could be so much better: http://www.raizlabs.com/blog/2006/09/25/ten-reasons-why-css-...
Look up "constraint-based layout" and more specifically "constraint cascading style sheets". You'll find papers such as this one: http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.101.4... and this one: http://csis.pace.edu/~marchese/CS835/Lec7/mmJournal.pdf thoroughly describing such a system.
Find "GSS - Grid Style Sheets" at http://gridstylesheets.org/ , "an implementation of Badros & Borning's Constraint Cascading Style Sheets". This is still half on my todo list, but it seems like the real thing. The catch? Relies on Javascript.
Dream of a world in which this kind of system was built into browsers as the primary way of doing layout <insert Simpsons happy dancing people gif here>.
It’s not that CSS is hard; it’s that CSS is bad. (...) The worst problem with DIV-based layout is that the layout system is too weak. (...) There’s no way to relate a DIV to anything but its predecessor, its parent, or an absolute position. (...) Table layouts allow table cells which span multiple rows and columns. If all tables could do were simple grids of cells, the CSS approach might make sense, but tables are more general than that.
CSS, from my experience, makes it very easy to do web design the right way and very hard to do it any other way. It's just that the right way is often a little different from what people expect. If you accept that <i>the browser is the boss</i>, you'll be a lot happier, and incidentally your users will be a lot happier as well. The trouble is people coming from other platforms or mediums often expect 100% control, and for that it really doesn't hold your hand.
I totally agree. For example, the CSS box model sounds so simple and elegant at first, but when you add dozens of styles and elements to your page, the interaction between different styles can quickly become horribly messy no matter how disciplined you are with your CSS code. Beyond a certain number of styles, CSS inheritance turns into a black art.
CSS simply doesn't scale well for anything beyond relatively simple pages. A huge part of designing web pages is layout and spacing and yet positioning and spacing elements remains ridiculously messy and convoluted (even with CSS3).
You could also argue that tools like SASS and LESS are in effect sticking-plasters for inadequacies in CSS.
I know hindsight is a wonderful thing, but if we were designing CSS today from scratch, I think it would be designed very differently.
It seems like flex-box fixes a lot of this, but at the same time, it could be so much easier.
You're right though. CSS would be so much different and so much more gloriously painless to use. I can even imagine a better styling engine allowing for applications like macaw, dreamweaver to actually generate properly good CSS and thus building sites with a GUI would finally be plausible.
But that's how I center every one of my "modal dialogs" on a site -- the whole modal dialog is inside a <table> with position:fixed and top/bottom/left/right:0. Then, just give the <td> a "vertical-align:middle", and then put your desired visible dialog <div> inside it.
It's annoying to have to wrap something inside of a <table><tr><td> just to vertically center something, but it sure beats using JavaScript to do it. (You might be able to do it just with the display:table-cell property too, but it's been a long time since I checked browser compatibility.)
Browser still has more users than Firefox had some years ago when we started talking about supporting all browsers. Unfortunately.
Also, if you keep supporting older browser, people will keep using them. If they keep using them, they will likely have vulnerabilities. So in a sense, dropping support for old browsers is like tough love.. it's not an easy choice for anyone to lose out on however small a fraction of visitors/users, but sometimes you just have to do it, "for the greater good".
Why the heck would a company stick to IE7? It's not like the compatibility modes of later IE's don't work or something...
when you have to support multiple thousands employees, having a stable environment is key. upgrading becomes an expensive and slow process.
the next load set at that company is currently in testing for the last 9 months (!) and will upgrade to ie9 and office 2010 - both will be around for a few years to come, their extended support periods end in 2020.
I had no idea you could use % within transforms that referred to the size of the element itself (since all other % in CSS refer to the size of a parent element).
Thanks!
> It's annoying to have to wrap something inside of a
> <table><tr><td> just to vertically center something
It is not OK to use table and friends in you HTML just for styling purposes. It's totally OK to use display: table* in your CSS, because CSS has no semantics, its purpose is styling.
Why doesnt CSS just have a property like 'placement: center middle' or something.
Of JS/DOM/CSS in HTML5, CSS is the worst standard. Depreciation is the best we can hope for. I’m sure MS and Mozilla will fight it tooth and nail, but maybe Google will pull a Dart/Go here and give us something decent to work with.
People complain because it doesn't address their specific needs explicitly (e.g. vertical centering) - but that way lies madness; a huge spec that caters for every case explictly, and probably has lots of corner cases and interactions meaning that cross-browser support would be even harder than now.
CSS is limited - and that's a good thing. Would you want to implement complex layout in JS, say? And how that would look when window size changes, or the page is zoomed, or some font isn't available?
The declarative nature of CSS is what makes it work; and the key aspect of declarative here is that it represents a state, not an algorithm - it's not turing complete. You'll never be able to do everything in CSS; and that's by design.
http://stackoverflow.com/questions/10014461/why-does-enablin...
It would be nice to see a complete overhaul of how presentation is done, with what people have sought to do on today's web in mind.
A placement: middle, without a rigidly defined height, would require the layout engine to know about document information after the element requesting a middle placement.
I keep hearing this dogma, don't use tables for layout, but nobody has ever explained to me why it is a problem in practice.
For a change it's actually a close decision that was a good one.
[1] search/indexing bots do look at classes to try to make sense of a page, but only because of tag soup and the lack of structural elements before html5
HTML is meant to be parsed and interpreted by machines too, with no visual representation. Tags are meta-data about their content. A 'table' element says "I contain tabular data", and user agents will make lots of assumptions based on that. One of the consequences of this is you'll be giving bad data to search engine bots, that's why it's bad for SEO.
HTML is also meant to be used by non-visual interpreters, like screen readers. Assistive technology is not only for the legally blind; visual impairment affects 20-30% of the world's population. We don't see high user %s because they just most won't bother, it's too hard, sites' HTML is broken, it is easier to have somebody look it up for you.
Going on a little more over semantics, there are rules for what elements can contain each other, so that a structure can be inferred based on headings and hierarchy. By not following the rules you are wreaking havoc on this, and preventing aforementioned bots and screen readers from providing meaningful navigation and context for your page.
We were supposed to have a semantic web by now, where every piece of information was annotated with meaningful meta-data, allowing for context-aware applications (add this commenter on facebook; where can I buy this product?; add this event to my calendar). Turns out it's damn hard to get everyone to use markup correctly, or even agree to common formats.
Even if layout tables did present a problem, an easy incremental fix convention (say, `<table class="layout">`) might have been a nice addition to user agents for situations where people either hadn't invested in semantic markup + CSS yet ... or for the layouts beyond CSS capabilities.
That isn't to say that I think everybody should be using tables for layout or CSS completely sucks or we'd all be better off if we were doing layout like the Java/C#/Flash/Python library of your choice does it.
I'm just not sure the "tables break things" argument is particularly strong.
I also think that it could've been done pretty reliably by heuristics. A table that mostly has data cells that contain lots of images or block-level markup as descendants is quite likely a markup table. A table that has mostly text or inline-marked cells and has a full summary attribute or <caption> is all but certainly semantic.
I guess with IE 6&7 all but dead, though, it's sortof irrelevant now -- you can mostly count on `display: table-cell` to help you out of a jam.
<table role="presentation">
Have you experienced this personally, or do you have this on first-hand account, or are you repeating the common wisdom?
Because like I said, Lynx had a way of doing this circa 1999. It mostly ignored tables except a few that met some criteria for likely semantics. So you generally got a cell-ordered page, which worked surprisingly well for most sites. Heck, if you've got a copy of Lynx at hand, fire it up right now and browse HN (which is layed out via table, ridiculous though it is for a site with such a simple layout).
If Lynx can do it, I have trouble believing that deliberately assistive software wouldn't be able to. This matches most of the (admittedly limited) discussion I've had with people who use/write it (an aside: I've also heard that, believe it or not frames were sometimes a big boost to assisted usability).
If you've got personal experience or first-hand accounts, though, I'm interested to hear it.
Lynx is a text-mode browser, not a screen reader; it's still visual. Assistive tech has a whole lot more going on. They have a slew of navigation modes and need cues from content to prevent the user from getting lost, you can't just scroll or look back up to where you where. I recommend looking at the resources below, and trying to use an iPhone or mac with voiceover and screen curtain enabled to really experience what it is like.
http://alistairduggin.co.uk/blog/screenreader-resources/ (collection of videos & articles)
http://www.youtube.com/watch?v=izrC4R7SsH4
http://www.youtube.com/watch?v=S4QBqpU1jj8
http://www.youtube.com/watch?v=AmUPhEVWu_E
http://www.youtube.com/watch?v=vK1tlLOavvM (linked by PavlovsCat below)
Sure. The point isn't that Lynx is an assistive UA, the point is that it's at least one UA that figured out how to throw away layout-purposed table markup (which, like some assistive UAs, doesn't make any sense in its rendering context) and still render (some) markup that represented tabular data.
Is it really the only one?
> Assistive tech has a whole lot more going on. They have a slew of navigation modes and need cues from content to prevent the user from getting lost, you can't just scroll or look back up to where you where
Right, but is that really tied up with non-semantic table use? I'd think it's the presence or absence of things like access keys, title/alt text, and I guess at this point aria attributes that makes the difference, not table markup.
You are underestimating the damage bad markup does, and how deeply assistive software relies on semantics/metadata/structure. As I said, just fire up voiceover and try to browser HN. Actually, I'll quickly do that for you:
I'm comparing table-based HN to one of it's alternative interfaces, not ideal but much better. It's a very shallow example, and I'm using only basic navigation commands - experienced users can use more complicated navigation schemes to discover content, out of necessity - but you get the idea. Lots of noise (row x of x, column xxx..), blank cells are "read", etc. Remember HN is a very simple and spartan website, now imagine what a slightly more complex nested table layout looks like.
Also, see WebAIM surveys for actual assistive tech usage data: http://webaim.org/projects/
It is, however, apparently smarter about the use-semantics of table markup than most screen readers, if I'm to take your example as the norm.
> imagine what a slightly more complex nested table layout looks like.
Having spent more time than I care to remember inside the code of complex nested table layouts, I unfortunately don't really have to work too hard to imagine. :/
> You are underestimating the damage bad markup does, and how deeply assistive software relies on semantics/metadata/structure.
I can see/hear from your example that the table markup is a challenge for voiceover.
I'm not sure I was underestimating the damage repurposed markup does more than I was overestimating the ambitions of assistive UI devs. I'm just astounded that voiceover wouldn't haven't implemented at least a mode for making likely distinctions between table markup that's being used for tabular data and table markup that's being used for layout, when making such a distinction is not only clearly possible but has been done.
Then again, I'm astounded that it's 2013 and Adobe still can't install onto case-sensitive volumes, so there's that.
Some examples from an earlier post:
Hacker News itself: http://stylebot.me/styles/2945 Buzzfeed was particularly fun: https://plus.google.com/104092656004159577193/posts/G6pzJBLK.... NY Times and Edge Perspectives: https://plus.google.com/104092656004159577193/posts/NUMQuQUh.... Basically: if it moves, is fixed, is an interstitial, or is just plain annoying, I kill the hell out of it. And with Stylebot, the easy stuff is just point, click, and "Hide". Then it's gone. Bring it on.
No it really wasn't. A small group of people managed to make it orthodoxy and in the intervening years very few of the supposed benefits have materialised.
In the meantime the same arguments that it is pie-in-the-sky have persisted and events have supported them.
The argument isn't even internally consistent as in the real world people are debating one kind of tag soup vs another. If the only way to create a particular appearance is either using several wrapper divs or a table then you're splitting hairs.
<div><div><div></div></div></div> vs <table><tr><td></td></tr></table>
Is that a semantic difference worth fighting for?
The real gains in the semantic web have come from small targeted blocks of metadata and natural language processing. Not waiting around for everyone to figure out <section> vs <article> correctly.
<clarification> I'm not arguing against the benefits of semantic markup - just that a lot of the hand-wavey "this is semantic and this isn't" advice that gets thrown around is either nonsense or adds such a microscopic amount of semantic information that it's not actually providing any benefit to anyone. The real test is to list actual benefits for actual user agents.</clarification>
Practically, the way it's ended up, the semantics of a div is "some stuff". It's evolved into the go-to method to hide a multitude of styling sins. I don't think there's anything hugely hypocritical in limiting any ugly semanticless hacks to a single generic container like divs.
Put as much as you can into semantic markup, and then anything else you really can't fit into that, favour using div soup over breaking the semantics of another tag.
HTML lacks extensibility. If you want to move beyond classical typography you have to make heinous compromises, and there is no reason <table> should be specially exempt.
<div id="rant"> Presumably the goal is to create a strong separation between layout/design and content as HTML is want to do. However, I don't agree with the premise that design is not content even in the context of translating 'content' to different display systems including for the visually impaired. A movie cannot be automatically retargeted to a blind person by just playing the audio, you must actually do the work translating it to a different form such as a novel, or scene descriptions read aloud. Sometimes as with say a Woody Allen film, you wouldn't miss much if you could only hear it, but something like 2001 wouldn't work so well. Like it or not the internet works exactly the same way, all 'content' does.
Layout and design is content. </div>
Ask a blind person how they feel about you not agreeing that they should have access to the same web you do. They actually do 'watch' movies and TV by audio only. A lot of information is lost, but it's better than nothing. And with a web page using correct markup, a good screen reader interface, and some practice, they can navigate and consume information much faster than we can visually.
I absolutely did not say that a blind person should not have access to the web I said the opposite, a designer should be mindful of their various audiences and design for them purposefully and not expect that a file format can do that for them.
I wish there where layout oriented and data oriented table tags, but there isn't so table gets used for both if you want anyone looking at the code to to get what you're doing. I also wish you could designate where the 'content' actually is sometimes its the text sometimes its the imagery sometimes its the layout. Then at least you'd be clear on where manual translation is required.
It's a hard issue, but the goal of assistive technology is to include people with disability, not segregate. If you want to create a specialized version for them, by all means go ahead, but HTML and ARIA were designed with this goal in mind. I don't think there is a better tool for this.
> I wish there where layout oriented and data oriented table tags [...] I also wish you could designate where the 'content' actually is
That's where `display: table` comes in. New elements in HTML5 allow you to designate content, supporting text, images, navigation areas: main, article, nav, figure, aside, etc. This could already be done with ARIA "role" attributes in HTML4/XHTML.
http://www.youtube.com/watch?v=vK1tlLOavvM <-- Léonie Watson, "Design like you give a damn: Practical accessibility for Web Pros" = very good talk, crucial crash course, and includes a great demonstration of the bit of your post I quoted :D
Great talk!
Slight left turn on the topic, but I think people can lose some elasticity in their thinking when they try to be politically correct. Accessibility implies impairment, but that can give you a mental model of "blind people are people too so we should be careful not to exclude them". But that's bottom up thinking you should be thinking what is possible, or top down thinking.
The mental model is completely different if you take political correctness out of the equation. What if we are talking about a person driving a car using a web interface? Now the user can't see because of a situational limitation not a physical one. There is no need for the implication of sympathy.
It's inspiring to me to design for any IO method I can think of. Aiding accessibility is useful to everyone, but I call that user experience and usability. This is why I get bent on some of the thinking behind HTML. Design, to me, isn't a second class citizen when communicating with your user/audience. New devices show the same information but did we just use the same html and css no we reformatted for the devices. What about when we are all using google glass and web enabled watches?
Granted many web pages that where redesigned for 'mobile' would have done better to leave well enough alone, but that's just bad design.
[icon] item name item date [command] [command 2]
[icon] item name item date [command] [command 2]
1) Why is it called "unordered" when there is still an order? Bad naming ...
2) More importantly, how is the above not tabular data? Who becomes the arbiter of what is tabular, then, if the above is not tabular?
Napkins 21-07-2011 14:52 Change Remove
Pitchforks 21-07-2011 14:52 Change Remove
+-----------------------+
| Napkins (21/07) |
| |
| +--------+ +--------+ |
| | Change | | Delete | |
| +--------+ +--------+ |
+ ----------------------+
Unordered lists mean the order they have is not meaningful. It's physically impossible for something not to have an order...
The whole concept of tabular data is a concession to people who insist that they have to use tables.
If you are trying to provide a layout for both mobile and the desktop, putting tables in your html will definitely make it harder. If they are in the CSS, you can use two different CSS styles for mobile and desktop.
Often when I write stylesheets for a site, I like to have a default table style. Type, possibly border/spacing, padding, etc, depending on the site. Even if there are multiple visual "types" of tables to display, typically they will all have a common set of margin/padding at the least.
If you wanted to use a table for layout in a site with default table styles, you would have to have a whole set of style resets to get it back to zero layout, before adding your custom layout stuff. This is ugly, and a pain.
One point of using a div for layout style is that it is always "zeroed", and you can assume when styling one that there's nothing that needs to be overriden.
I love how your example uses 'something-semantic' as the class of the nested divs, as if labelling them semantic makes it so - this is an ugly hack around a deficiency of CSS and not far removed from using tables. It is possible to centre things vertically (with nested divs) or have several columns of freely defined height, but people have to go to extreme lengths to do so and mangle their markup in the process, because CSS is sorely lacking in some fundamental aspects of design. Things which should be simple are hard, and it's impossible to truly divorce the meaning from the form because of bugs and deficiencies in CSS, which leaves us adding nested divs all over the place to get the correct layout.
CSS should have had vertical and horizontal centring for blocks from the start, it should also have had some system of grids and columns and a concept of baselines. It's painfully clear in the design of CSS and the huge gaps in the coverage that it was an ad-hoc reaction to browser developers' problems, not to the problems of designers styling HTML. It could be radically simpler and have far more power if they went back and rethought the foundations of the box model and considered other techniques like grids which have been used for hundreds of years to present information.
Here's a jsfiddle to illustrate it. http://jsfiddle.net/qu5jq/
I've spent hours in the past the past getting correct centring behaviour in CSS, then tried by just putting the whole thing inside <center></center> and had it work immediately in all browsers. But apparently that's "cheating".
It's the standards makers' fault. Needing to center something on either the x or y axis relative to the parent is as common a scenario as you can get.
Articles about how to do this should be summarized like this: "Vertical centering hard/hacky/messy unless you just put it in a table. So put it in a table".
(I do realize the article says this).
BTW, regarding the argument about the damage of using tables wrt screen readers, google themselves used tables to layout very basic buttons on their landing page until very recently. If you use it sparingly and just for this purpose, screen readers will do just fine. Now, using tables for other types of layout can and will break screen readers but a full old-school table-based layout is a long way from having a single TD to center stuff.
margin: auto;
position: absolute;
top: 0; left: 0; bottom: 0; right: 0;
Blocked a frame with origin "http://s.codepen.io"
from accessing a frame with origin "http://codepen.io".
Protocols, domains, and ports must match.
How is localStorage a significant privacy concern? My understanding is that websites only have access to the keys stored by that particular domain.
But, I can remember trying projects with tableless design at that point, and absolutely beating my head against a brick wall attempting things in CSS that required almost zero thought with tables. Then, I'd finally get it right in one browser only to find that it looked like garbage in another.
It was like having a toolbox with a hammer that I couldn't use, instead being forced to nail everything with a screwdriver. And it wasn't just that I was accustomed to tables. They were easier and more natural. When you think about it, layout is nearly always grid-like.
So, I confess that there were times when I said screw it and reverted to tables. I'd solve problems that weren't working after hours of trying with CSS in literally minutes.
And the challenge with CSS is still apparent. Here we are all of these years later, still trying to do something as simple and frequently necessary as center things vertically which, BTW, doesn't work in my stock Android browser.
CSS is a bloated, convoluted mess and just too much work for simple things. That's why I have always found it somewhat draconian that people insisted on CSS as if it didn't have its own significant issues. If there were a tag that operated just like tables, but indicated layout or, as I think someone else suggested, a simple attribute to mark a table as layout vs row/column data, most of the semantic/SEO problems could be solved.
For that matter, I am not convinced that we should be so bent on having html pull double duty as the source for semantic data and the source for a presentation engine's rendering. Maybe a different approach altogether could be more liberating and efficient on both fronts.
Not sure exactly what you mean here. Are you talking about floating divs to wrap elements to the next visual "row" for smaller screen sizes, as in responsive design?
Because I don't find this necessary very often in practice, and certainly not nearly as often as the tons of other general layout that's required. Not to mention, of course, that you can still use divs where "needed".
BTW, on a side note, the jury is still out on responsive design for me. Or, at least as I have frequently seen it practiced today. For instance, many times a site with sidebars (including nav) will wrap the sidebars on smaller displays such that content, nav, etc. are all lined up in one vertical column. Not very appealing or usable IMO.
I really believe that how we treat designing to different formats will change and this responsive wave will pass. And, while I know there are other reasons to wrap elements, I do think responsive design is responsible for a good bit of it.
But, you're right: tables can be used for the same.
Not something I've done much either way. I just don't think its a nice effect. Guess it's just a style preference.
http://www.imgur.com/7JA69Ty.png
Or is the browser chrome considered usable real estate.
You can also do this
position: relative; margin-top: 50%; transform: translateY(-50%);
But overall your point is fair: HN has a lot of people (including me) with weak front-end skills.
If IE8 and down matters, then there are polyfills available for this functionality.
Making any layouts and god forbid centering elements has always been a headache for me. Even by looking at the CSS examples provided by the link my first thought is how random they all seem and how ugly they are not to mention difficult to remember and use. There should be a single way to center an element. It should be an obvious operation given how important and common it is.
Some very useful CSS properties might take a lot of code and be hard to implement in native GUI toolkits like floats, overflow, height/width with percents, text wrapping etc. This is a sweet spot where HTML/CSS shines.
I have been playing with QML lately and decided to implement the Dialog (Absolute center within viewport) that pops after visiting the linked page just for comparison:
Here's the dialog equivalent that just fills the entire screen of an application done with QtQuick 2.0 for Desktop.
Layouting is easily done by anchors. Filling a rectangle to match a parent's container, centering an element inside a parent, etc. Other containers such as Rows, Columns or Grids are also provided. Property bindings are used for centering the dialog even if the viewport changes. Text wrapping is also done explicitly and binding was necessary to limit text width to the ScrollView for it to work.
One big difference compared to CSS is that by looking at the source I can see at glance what the layout structure is and what might be happening with the element.
Another cool thing about QML is that it's as simple as taking the code, creating a new file 'Dialog.qml', adding a few properties, a signal and some functions and we get a reusable standalone component:
that is very convinient to use:
result: http://i.minus.com/iGTQhAxP55bBP.gif (3MB gif)
http://jsbin.com/ezocec/1/edit (25 lines counting the HTML)
CSS has columns and grids, custom text wrapping. These features are available now in >90% of browsers. The `.dialog` class can be used as component without any changes, and we have things like component.io and browserify to package them up with behaviour.
result: http://cl.ly/2w1o3h0i1t0r
Perhaps a tool can bundle resources, but in the end it's still going to be inserted into the DOM and can potentially clash with other code since everything lives in a global namespace. There's also the problem of competing tools and the dilemma of which one to choose. Any other additional library that is meant to augment/fix HTML/CSS is another dependency that can cause problems and needs to be maintained.
QML is meant to be extensive. Not happy with how the drop shadow works? Write your own shader that does it the way you want it. Feeling that there's some primitive like an Ellipse missing? You can write your own in C++ and expose it to QML easily. In fact you can expose any native code to QML.
With HTML/CSS you are constrained to the environment it works in.
QML supports components, animations, transitions, particles, states, bindings, i18n and much more. It's also very smooth, qml is hardware accelerated. In the case of CSS so you get some hardware acceleration only for animating properties like translation, etc.
Here's the dialog I posted before which I changed to support states and transitions and also added an inline shader and particle emitter:
http://i.minus.com/iATg82IRCaMa9.gif (result 4MB gif)
As it can be seen it's highly declarative and it basically contains no javascript logic at all besides setting the states.
Of course a lot of such features are available indirectly in HTML/CSS by piggybacking on third party libraries/frameworks, but wouldn't HTML be so much nicer if it were designed with those things in mind from the very beginning?
Shadow DOM is the specification that will fix the collision/cascading issue, making it possible to isolate components. You can now write your own shaders, use custom masks/clipping etc, and of course, SVG for unlimited vector shapes. If that's not enough, write your own graphics layer with WebGL or Canvas.
http://jsbin.com/ezocec/3/edit
Now around ~80% less code.
This is a fun but pointless showdown of course, these are technologies born worlds apart, with different audiences, purposes and constraints. HTML appeared in 1990, with the sole purpose of marking up hypertext, grew organically and has a hundred other interoperability concerns; QML showed up in 2009 (?), twenty years later, and was designed to solve specific problems. I'm certain the web wouldn't have grown as fast if it didn't have a stack as accessible as html/css.
Details: http://jsfiddle.net/uy64k/6/
This requires no extra markup, but it does require the font-size and line-height to be reset.
[1] http://stackoverflow.com/questions/5009864/using-all-four-po...
If I recall correctly, the original Mac UI guidelines specified that the midpoint of the box should be 1/3 the distance from the top.
Other than that, I'd say that doing this kind of stuff in CSS would by default be much faster in a web page context.
ps. I didn't mean pure javascript solution anyway:)
[1] http://caniuse.com/flexbox - it's in the current version of all browsers (some still prefixed).
I've got to enable assets. and s.codepen.io to see the page rendered.
That appears to be due to the use of an iframe from s.codepen.io for the content.
These have intrinsically sized (autosized) boxes that vertically and horizontally center in some container.