Hacker News new | ask | show | jobs
by SCdF 4667 days ago
Has anyone used all of the HTML5 tags in anger? I've tried a couple of times to build something fully "semantic". I struggle to create something that looks good semantically (ie just reading the HTML) and is also laid out on the page in the way I wanted it to be.

There seem to be lots of situations, even in just mildly complicated web pages, where you need to write HTML code solely for graphics / layout reasons that completely breaks the idea of having a purely semantic document.

In the end it just seemed much faster and cleaner to be more flexible with those various structures and to give up on the whole "semantic" document ideal and smash divs around.

I'm ready to fully accept that this is the tables->css revolution all over again and I'm just crap, though, if that's the case.

8 comments

I think that CSS is the biggest failure here. Let's say I have a blog, so for article page markup should be something like this:

    <html><head></head><body>
        <article>lorem ipsum</article>
        <nav></nav>
        <form>search</form>
        <footer></footer>
    </body></html>
That way screen readers, search engines, etc will get the important stuff first and less important stuff afterwards.

But since the common way of presenting blog is more like this:

    <nav></nav>        <form>search</form>
    <article></article>
    <footer></footer>
I either have to do some hacky position:absolute things, crazy floats with negative everything, or just reorder the markup. Crazy and hacky is not fun to maintain, so I have to reorder the markup. That's because CSS is made for changing fonts and colors, and not for layouts.
Flexbox[1] addresses the issue you're talking about - of course, browser support is still a little lacking (No support for IE9 or below, and IE10 doesn't conform to the current spec).

[1]: https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Flexi...

In other words, it's useless for now, and for a few more years.

God, I wish IE 8 wasn't the latest thing on XP (Still a lot of users on windows XP) and that new features weren't added only in major releases that happens rarely for Microsoft.

Rarely, that is, compared to other vendors on the market.

I give Google a lot of credit with how they set up Chrome. The first thing they built out was a really nice auto-update function.
I think you should try using WAI-ARIA standards[0] instead. That way you can keep your structure the same and give screen readers and such a better description of what's going on in your page.

[0]: http://www.w3.org/WAI/intro/aria

WAI-ARIA support is abysmal, not only does it vary between screen readers but also between various browsers using the same screen reader.
Does anyone know of any specific screen readers that actually take semantic HTML tags into account? Or is this just a theoretical thing? It would seem to me if screen reader software relied on authors of every random site to properly use semantic markup they wouldn't be in for a good time.
Actually, you can have nav inside article and still get the important stuff.

  <html>
  	<head></head>
  	<body>
  		<article>
  			<nav></nav>
  			<form></form>
  			<main></main>
  			<aside></aside>
  			<footer></footer>
  		</article>
  	</body>
  </html>
You can additionally include a "skip to content" link up top.
But that is not was I was looking for. In your example navigation is the first thing in the markup, when content should be the first thing. Also, navigation does not belong to article, it belongs to site. And the same goes for footer.

And those skip to content -links just the kind of hack we should not have to do. There should not be anyhting before the content, markup-wise.

Not necessarily. Nav inside article functions the same as the contents list in a Wikipedia article so if you don't want that, you can remove it from the article. If you want secondary links to other related content, those should go in a different nav in aside. If you want site-wide links, you can create a separate nav outside the article.

Also of note, footer can be for the article or the whole page. If you like, you can put footer outside the article and put the site-wide navigation there in addition to any forms.

Skip to content links aren't hacks, but are in fact part of standard procedure for web accessibility and do solve a problem with fewer steps. Try not to look at things that don't necessarily conform to arbitrary standards of elegance as hacks.

In my example there was a site navigation, not article navigation. And with article navigation, the same problem exists. The article should be before the navigation. But it's not practical at all to implement.

And what comes to skip to content -links, those definetly are hacks. What they mean is "Dear user, we would have put the content first in the source, but since CSS is not a layout definition language, it was not possible, take this link instead."

Actually, you can use absolute positioning to achieve what you want, in a fixed-width layout. You use CSS to add padding to the top of the content which is equal to the height of your navbar/header and give the navbar/header position absolute and top 0.

I haven't figured out how to do this with responsive layouts. It's never worked well for me but I will come up with a solution one day.

"I either have to do some hacky position:absolute things…"

Why do you think this is "hacky"? This is precisely what absolute positioning is for.

Excuse my ignorance, but can you not use div layers to position your data as well as the header / footer tags?
Depends on the meaning of "can" and "div layers". Technically speaking I can do many things, it's just that CSS (before flexbox, as mentioned in the comments) does not have any nice way to say that this element should be displayed before that element and so on.

Not sure what you ment with the layer thing.

In the testing I've done with the aforementioned tags, the display ordering happens correctly on all the desktop and mobile browsers I had to hand, when I wrapped the content in div tags as well as the article et al tags. So I'm wondering if what I've done is: 1) "valid" syntax, 2) would still break in the clients being discussed earlier and thus I was testing the wrong clients or 3) missing the point entirely.

I'm still learning my way through HTML5 (I have had some experience with the markups that proceeded it though), so I just wanted to be clear on the issue :)

re "div layers", that was a foobar on my part. I meant "div tags". Sorry for the confusion.

Unfortunately I think it's 3), you've missed parent's point :) They are not saying that HTML5 tags do not order correctly. They are saying that it's difficult to create a semantic document, where the order of the tags suits screen-readers (i.e. article before nav, as the article is the important part) but the resulting webpage (when styled with CSS) suits viewers (nav at left of article).
Ahhh I see. Thank you for the clarification.
You can, and that is how it's mostly done now.

But that isn't semantically correct. A div tag is just a div tag - like all other div tags.

An article tag is "a div tag", unlike all other div tags. It tells that this is the main part of the webpage.

I see. Thank you :)
I've tried and failed miserably (so far) to use the tags also. It seems they are optimized for a single use-case: single, magazine-style, pages or blog posts. Anything other than this and it starts to fall apart pretty rapidly.

The alternative would appear to be micro (macro) formats which would offer more flexibility but obviously the chances of standardization on a widespread basis would appear to be remote.

Given the diversity of web-page content perhaps the goal of a semantic web is simply unattainable - at least in the short-term.

>Has anyone used all of the HTML5 tags in anger? I've tried a couple of times to build something fully "semantic".

Don't. Just use what you need and be pragmatic.

The biggest proponents of semantic markup have been web designers, people that had no idea what semantic meant until they were told by hack W3C people.

They tend to oversell the value of semantic markup, because they feel it makes them sound more intelligent and can help upsell their design offerings.

In real life, nobody cares for semantic markup. Not Google (the main search engine that matters), nor browsers, and of course, not the clients. And as real life experiments with assistive technologies have shown, not even screen readers benefit that much from semantic markup or care about it.

As for seperation of code and content and re-use -- that's what JSON, DBs, REST APIs etc are for. You are not supposed to reuse your HTML as is in other domains.

It's mostly a snake oil business, based on an idea that sounds good in theory, but it's more trouble than is worth.

And it has even less relevance nowadays, when web pages turn into web apps. What's a semantic "web app"? Why do we need semantics here, for something that in the native world we've always done with presentation code, from Interface Builder to Visual Studio?

Yeah, I know we were all excited about the new elements when they were playing about with them, but I was kinda skeptical as a web newbie doing pure productivity apps... I mean, the web is prettymuch an application engine now and we're doubling down on the document metaphor? What?

I still think that CSS in particular maps terribly to its usage as a complete layout system. I mean, you can do it, but you can code in BF or do incredible things with template metaprogramming in C++. Doesn't make it a clean, pleasant way to work, and doesn't really fit the designed purpose.

>I mean, the web is pretty much an application engine now and we're doubling down on the document metaphor? What?

I've been thinking similarly lately too. They're hardcoding semantics into HTML that may or may not change in the future. Better to avoid hardcoding things that could change or have subjective meaning whenever possible.

Instead, keep HTML tags simple and enable optional, flexible semantics via attributes and properties, along the lines of schemas (http://schema.org/). Let the internet standardize among schemas, and replace obsolete ones with new and better ones as they arise. Or, if it's not requirement for your particular app, just don't bother with it at all.

Much of the graphical froufrou can be done using the before and after pseudo elements (which is one of the reasons I'm sort of disappointed that the HTML for the newer designs on the CSS Zen Garden has remained the same, complete with extra divs and spans strictly for styling).
"Has anyone used all of the HTML5 tags in anger? I've tried a couple of times to build something fully "semantic". I struggle to create something that looks good semantically"

I recently ditched Wordpress and decided to learn HTML and CSS by hand-coding my blog. I used many (but not all) of the new HTML 5 tags including main, section, article, nav, footer. Admittedly a blog is quite a structured type of site that lends itself well to simple semantic markup. I am using html5shiv.js to support IE 6-9 and the site renders mostly fine in those browsers. There are some isues with spacing, but the site is perfectly readable which is the main thing.

Here's my site: http://www.designofhomes.co.uk (a blog about housing issues in the UK). Admittedly, it's not the most attractive design, but a reasonably clean and clear layout (I hope!) Any feedback on the appearance and structure is very welcome :-)

Here's what the site looks like in Internet Explorer and Lynx using browsershots.org for testing (this link expires in a day or two)

http://browsershots.org/http://www.designofhomes.co.uk/

If clean and clear is what you're going for, I personally think you've done a good job!
That's great to hear. Thanks :-)

  > There seem to be lots of situations, even in just mildly
  > complicated web pages, where you need to write HTML code 
  > solely for graphics / layout reasons
It depends on the browsers support desired, but for reasonably modern browsers this should be rarely the case, except for really complex layout. Now when we have multiple backgrounds and background images and generated content there is less demand for extra elements.
It really depends on what kind of page you're making. If you're doing a heavily optimised landing page where everything has to be just-so, you might need to smash a few divs.

If you're just making a basic page that's not too designy, you can produce some beautiful looking html. It looks even better in haml. Write some sass for it and you will reach a higher state of markup consciousness.