Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The ﹤main﹥ element

html5doctor.com

Post reply on HN
Print view View original

51–60 of 93 posts

Re: The ﹤main﹥ element

#51

Post by eksith »

hpaavola wrote: post #11
SCdF wrote: post #4

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…

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: lorem ipsum search 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: search I either have to do some hacky position:absolute things, crazy floats with negative e…

Actually, you can have nav inside article and still get the important stuff.
You can additionally include a "skip to content" link up top.

Re: The ﹤main﹥ element

#52

Post by talmand »

verisimilitude wrote: post #47
rorrr2 wrote: post #40

Earlier quoted context omitted.

Could you show us one of your websites "without divs, spans"?

Not easy, but doable, especially on a straightforward design: e.g. http://tumbledry.org/

Straightforward design meaning a never-ending single column of content? I would be shocked for such a page to require any creative usage of divs/spans whatsoever.

Also, just curious, what's the point in having a footer that I can never properly see because new content is injected as I scroll down the page?

Re: The ﹤main﹥ element

#53

Post by joe5150 »

aroberge wrote: post #34
Kiro wrote: post #19

I still haven't found one good reason to use any of the semantic HTML5 tags instead of just good old divs. This didn't convince me.

The nightmare of divs makes it hard to find the end div unless someone is disciplined enough to indent the code consistently OR if comments are inserted at the end of divs as in ... Using semantic tags makes it much easier to see the structure.

I indent religiously, and I comment, but I use a lot of static site generator-type software and I've yet to find one that doesn't completely ruin the indentation in the output, even with the various kinds of HTML-prettify plugins.

Re: The ﹤main﹥ element

#54

Post by mmatants »

codeka wrote: post #17

Somewhat interesting, perhaps, is the fact that this page itself has the following markup: ... I, too, have tried to use semantic markup. Unfortunately, except for the most straight-forward of layouts, it's very hard to do. Though I guess there was also a time when non-table-based layouts was considered harder than it was worth...

Semantic = for developers. I.e. not in the "make it nice for web crawlers" sense, but for readability of template code.

So for my own workflow, I have been quite comfortable being a "semantic stickler", where markup is written first and with only a general wireframe. CSS classes are added sparingly, to mark separate areas of concern for LESS/SCSS grouping. And then styling work begins, during which I try to avoid adding presentational fluff to markup at all costs. It's hard, but CSS3 allows a surprising amount of power.

The rule of thumb is: clean template code is worth dirty CSS hacks. CSS is going to be shit anyway, due to its inherent qualities as a language. So might as well make templates awesome.

And again, this is for developers' sanity more than anything to do with "semantic web" or whatever.

Re: The ﹤main﹥ element

#55

Post by talmand »

hober wrote: post #22
Kiro wrote: post #19

I still haven't found one good reason to use any of the semantic HTML5 tags instead of just good old divs. This didn't convince me.

… header {…} is slightly shorter than … .header {…}

It's easy to present a special use example as a benefit over the current trend. It doesn't mean it would hold up over multiple comparisons.

Although, any example that I could provide that would show the exception would also likely be a special use example. So it turns into a your mileage may vary situation.

But, I've not always seen a slightly shorter amount of typing as a benefit to this sort of thing.

Re: The ﹤main﹥ element

#56

Post by hpaavola »

eksith wrote: post #51
hpaavola wrote: post #11

Earlier quoted context omitted.

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: lorem ipsum search 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: search I either have to do some hacky position:absolute things, crazy floats with negative e…

Actually, you can have nav inside article and still get the important stuff. 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.

Re: The ﹤main﹥ element

#57

Post by eksith »

hpaavola wrote: post #56
eksith wrote: post #51

Earlier quoted context omitted.

Actually, you can have nav inside article and still get the important stuff. 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.

Re: The ﹤main﹥ element

#58

Post by MLR »

phpnode wrote: post #10

it's annoying that it can't be used more than once per page. It would be useful to also have a element, e.g. ... ... ...

Maybe using section there would be acceptable, it's the closest thing I can think of at least.

Re: The ﹤main﹥ element

#59

Post by peferron »

Thanks for posting this. I just replaced the I was using on one of my projects by a . In the context of this project, this particular container was always meant to be unique anyway; and it had been bothering me a bit these past few days to know that I wasn't using quite as intended. Using a wasn't a very sexy alternative either.

Quite sure that when I read the list of HTML5 elements a while back, wasn't in the list! Glad it got added.

Re: The ﹤main﹥ element

#60

Post by mvzink »

This is great news. However, all this discussion of "semantic this-or-that makes my site look like shit" or "semantic tags are just for template clarity" and "well at least web crawlers and Readability can make use of it" is really annoying.

If you think exists to make SEO easier for you, I'm willing to bet that around 7 million blind people in the US alone won't bother trying to use your site. Why? Because their screen reading software won't be able to make it through your mess of markup and get to the part that matters, for one.

It's hard enough getting people to care about accessibility at all, but trying to drive ARIA adoption must be a complete nightmare. is taking one of the most obvious, simple, and useful pieces from ARIA, which just happens to fit in quite sensibly with existing "semantic" tags, and allowing you to remove an important accessibility hurdle without even knowing about ARIA!

I, for one, am extremely glad that I can now make my sites a bit more accessible with almost no extra effort.

Post reply on HN