Hacker News Reader

Comment by rimantas | Hacker News Reader

  > It's annoying to have to wrap something inside of a
  > <table><tr><td> just to vertically center something

And you dont have to. Because your container does not have to be a table, and you don't need cells and rows. Just use display: (table|table-cell). See for an example: http://css-tricks.com/centering-in-the-unknown/

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.

View on HN

Why is it not okay to use tables for styling purposes? Why is it okay to use multiple nested divs, but not the table/tr/td tags? Are there any practical reasons, besides the goal of making the markup more 'semantic'? Are there any screen readers that can't handle table tags? Or do some crawlers choke on tables?

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.

see http://stackoverflow.com/questions/83073/why-not-use-tables-...

Thanks for this, but of course the question got closed.

I don't see the problem: there's a question, there's a good answer, so it's closed. Not everything has to be an on-going debate.

That's not what happened. There's a question, it isn't the sort of question the stack overflow wants to have, so it's closed.

For a change it's actually a close decision that was a good one.

I used to hear that dogma too. And then all of a sudden I'm reading everywhere that I should check out bootstrap.css, which flies straight in the face of semantic markup by requiring you to use class names that are descriptive of their layout effect. I don't know if there is overlap between the evangalizers of semantic markup and bootstrap.css, but if so, it would seem contradictory.

Classes and IDs have no semantic purpose in HTML[1]. Bootstrap's approach is bad from a developer's perspective, but is not bad as long as you use the right elements.

[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

I used to be against class names that are descriptive of their layout effect, but honestly, it's the simplest way a lot of the time. You can't always think up the exact right name for a random element somewhere on a site, and getting into the habit of using sane oocss can save a bunch of time.

Being "semantic" (your quotes) is not an abstract concept or dogma. This discussion has been exhausted as far back as 2005. A more practical explanation:

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.

If using tables for layout broke non-screen user agents (like screen readers and Google), then the web must have been more or less unusable by them until at least 2005. We know that's not true for Google, at least, and by 1999, Lynx actually had some capability for dealing with them.

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.

If I remember correctly, the summary="", was suggested for layout tables. I never looked into screen reader support for that though.

That's smart. A present but blank summary attribute would've been a great indicator.

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.

What you want to make (modern) screen readers not try and parse the table semantics is to set the role to presentation:

Yes, using a screen readers with a table-based website has always been a nightmare. Google invested heavily on research to be able to make sense of tag soup, that's one of the reasons it could provide way better results than anyone else. It's an ugly workaround, like printing a document and scanning it back instead of copying a file. See rest of discussion above.

> Yes, using a screen readers with a table-based website has always been a nightmare.

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.

I used to work at a company specialized in front-end development, where we used NVDA, Voiceover, Window-Eyes and Jaws extensively while building and testing websites, sometimes for legal compliance.

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)

ARIA provides a solution for the problems caused by <table>.

> Lynx is a text-mode browser, not a screen reader; it's still visual.

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.

Exactly, Lynx is not an assistive UA. Keyword there is `render`. It makes very little use of tags' semantic meaning compared to a screen reader. Alt/title attributes are just a small part of the picture.

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:

http://cl.ly/3l3E2C000419

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/

> Lynx is not an assistive UA. Keyword there is `render`. It makes very little use of tags' semantic meaning compared to a screen reader.

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.

"Turns out it's damn hard to get everyone to use markup correctly, or even agree to common formats" - perhaps because it's damn hard (read: often impossible) to get the intended visual presentation for the majority audience of sighted users to look right without resorting to non-semantic markup.

I've pretty much abandoned many sites' designated markup for either 1) Readability's version or 2) my own CSS using Stylebot. It's relatively easy to make significant corrections quickly, and for sites I spend significant time on (say, G+, HN) it's downright useful.

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.

> Being "semantic" (your quotes) is not an abstract concept or dogma. This discussion has been exhausted as far back as 2005

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.

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>

Amen! For example, what is the practical advantage of using <footer>, <aside>, <artice>, <section>, today? I only ever hear "search engines or screen readers can/could do X", that but nothing about what any user agents or bots actually do. No examples, and no way for me to detect any difference it would make anywhere (other than having to include HTML5 shims for IE). That doesn't do a lot to get me interested in paying attention to that stuff, to move beyond "does it look how I want it to". In short, don't tell me what I should do for the robots, tell me what the robots are doing for me (or other people), with that stuff.

There are plenty of examples, articles, tutorials, videos, presentations on that topic (many linked here in this thread). You won't find what you're not looking for.

"on that topic", or answering the very specific question I asked?

Tables have a well(ish) defined semantics that you're breaking. Those semantics give rise to real practice benefits like navigating via column and row with screen readers or hinting how best to split a table up into multiple pages when printing.

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.

What about inline elements inside divs? Even the semantic correctness crusaders freely resort to abuse of <b> and <i>.

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.

I agree we have to make compromises because HTML has huge shortcomings. My point, and the point of a lot of people advocating semantic markup, is that if you have to resort to hacks, prefer lots of uly generic containers like divs and spans to misusing things that have better defined semantics that are actually of use to people, like tables. I can't think of anything you can do with tables that you can't do with an ugly mess of divs and a little compromise in cross-browser consistency.

The guy who first thought of using tables for layout lamented this back in 1997 in "The Web is Ruined and I Ruined It": http://www.xml.com/pub/a/w3j/s1.people.html

I have the exact same issue. I find it much less semantic as well as less readable and maintainable to use abstract markup (i.e. div) everywhere.

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

It's not the exact same issue, it's the exact opposite. Using meaningful markup (not div) where it shouldn't exist is more harmful than the contrary. Not using tables for layout doesn't mean you can't use tables at all - use tables for tabular data.

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 think we are agreeing, and I don't mean to spin up the same debates. I'm just saying that as it is html presumes that the important content is the text and throws everything else over the fence. It implies that you are done with translating for all displays if you just follow proper html best practices, when in fact you should consider targeting your content for specific displays in many cases.

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.

The problem with that is that 99% of designers (or their boss) would not consider screen reader users as their audience. Designing purposefully for the visually impaired means using semantic markup, ARIA if needed, and being careful to offer annotations where content is mainly visual. Creating a separate experience would mean duplicating your whole site, and nobody would do it because of the cost - or even worse, create a limited, reduced version, like the mobile-specific sites with all their problems we all hate.

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.

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.

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

Bingo! This

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.

It's gotten to such a weird point, though, that when I had data like this:

    [icon] item name    item date     [command]  [command 2]
    [icon] item name    item date     [command]  [command 2]

many web designers told me to use unordered list items! Yes. Ok -- um two questions

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?

It could be tabular data, but it depends on context. If this was an order list, for example:

    Napkins     21-07-2011 14:52    Change  Remove
    Pitchforks  21-07-2011 14:52    Change  Remove

It's not necessarily tabular data, you only have two columns. It could be represented differently without any loss:

    +-----------------------+
    | Napkins       (21/07) |
    |                       |
    | +--------+ +--------+ |
    | | Change | | Delete | |
    | +--------+ +--------+ |
    + ----------------------+

But if you had more data columns and headers it'd probably make sense to use a table. It's about providing meaningful context, relations and hierarchy, there are no hard rules.

Unordered lists mean the order they have is not meaningful. It's physically impossible for something not to have an order...

it's called unordered because the "ordered" list <OL></OL> adds numbers beside the items.

The essential reason non-tabular data shouldn't be represented as a table is because HTML tables coerce a particular presentation, whereas you can use CSS to arrange data in a tabular presentation if you want, or if you want to do it differently, just use a different set of CSS.

The whole concept of tabular data is a concession to people who insist that they have to use tables.

The CSS "display: table" and "display: table-cell" are designed to act exactly like their html counterparts.

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.

Just a small example, as I didn't see it mentioned in other replies.

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.

While I agree it's better to avoid tables for styling, I see why people resort to it as it is much simpler.

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.

http://www.w3.org/TR/css3-flexbox/

Thanks for that link, it is very enlightening. So much of CSS just feels like a total hack. putting something in the middle of an element should not be so hard! negative margins? ...absurd!

Why doesnt CSS just have a property like 'placement: center middle' or something.

CSS is the epitome of design by committee, only worse. It’s worse because some members had a vested interest for the standard to fail. As a result, we get threads like this from designers, and programmers; they're in a worse bind. It’s just not possible to efficiently hardware accelerate CSS.

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.

I've got exactly the opposite opinion: of JS/HTML/CSS, CSS is y far the best standard.

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.

It's not an issue of turning completeness. CSS was never designed to be hardware accelerated. So many implementations run faster in software. Here's a good example:

http://stackoverflow.com/questions/10014461/why-does-enablin...

People complaining about CSS usually complain about the illogic of cascading, which I don't understand. This, however, captures the weaknesses of CSS a lot better. CSS is strong when it comes to styling text, but weak when it comes to doing layout.

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.

That's what flexbox does, mentioned at the end of the post, it just doesn't have enough support yet.

Does flexbox support the centering of elements like the canvas and a webgl context? Does it offer facilities for resizing either of these elements? If not, is there anything out there that allows for resizing these elements with the rest of the page?

Yes, you can use percentage units.

CSS is thought out for it to be possible to implement a fast layout engine. This requires a few concessions. One concession is that it (mostly) requires that layout defined by a partial document is the same when the document is complete (to allow for documents to be laid out on the screen as they come in from the slow network).

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.

Reply on news.ycombinator.com