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.
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.
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.
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)
> 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.
Question: is there any evidence that search engines actually use/respect semantic tags like <main>, <footer>, <article>, etc.? Or anyone here who knows firsthand from Google?
Just because, if I were writing a search engine, I would already have a bunch of "AI"/heuristics logic to tease these things out, since most sites don't use semantic HTML5 -- and it would probably do a solid job, since it's easy to compare a bunch of pages from a single site and figure out what parts are changing.
Then, if I actually started assuming that <main> or <article> was always the main/article part, it makes it easier for people to "game" the search engine with keyword-stuffing, etc. So, if I ran a search engine, I'd probably just ignore them completely and rely on my own heuristics.
(For example, Google completely ignores HTML language attributes: "Keep in mind that Google ignores all code-level language information, from “lang” attributes to Document Type Definitions (DTD). Some web editing programs create these attributes automatically, and therefore they aren’t very reliable when trying to determine the language of a webpage." [1] So I wouldn't be surprised if semantic HTML is the same deal.)
I've heard it endlessly repeated that semantic HTML helps SEO, and that's why you should use it. But I've never seen concrete evidence of this -- is there anything that actually backs it up?
From what I understand, the short answer is "No, they don't". The long answer is "They don't yet, but if we keep telling people they do and everyone starts using semantic HTML, they will".
A few years ago I worked on a digital library system and we would sweat over including proper metadata about articles in meta tags (derived from the Dublin Core attributes entered by the authors). That was until we met with someone at Google who worked on Scholar. He said there was no harm in including that metadata, but they usually had more success inferring things like authors, title, etc from the HTML content of the page so they ignored it for the purposes of indexing. Things may have changed, but basically I think you're right that semantic markup is easy to game so probably doesn't affect SEO. Doesn't mean it's not worth doing though :)
Offtopic, but I'm not sure <article> means what you think it means. It could be an article like in a magazine, but according to the spec it's for any "self-contained composition in a document" like a widget or a comment. Each page could have many <article>s. It's definitely not intended to indicate "this is the main content of the page."
Lots of people are confused though. This is one of the many problems with semantic markup in the real world.
Why are people hating on HTML semantics? I fear it is out of some fundamental misunderstanding of how semantics work on the web...
First let me be clear that there are (at least) two types of semantics on the web, one for machines (bots and screen readers) and one for meat (humans!).
In writing HTML, the goal is not to use every semantically-rich tag available and avoid everything else like the plague. Where you can convey extra semantic meaning, use the most appropriate tag available; where you cannot, use a div or a span or something else. Use of divs does not make your page less semantic - it is not deductive. However use of the correct semantic tags will make your page more semantic - it is additive!
In writing CSS, the goal is not to avoid classes/IDs altogether to keep your HTML "clean". The machines care not if your HTML is rammed full of classes; though you will certainly care when it comes to maintaining your pristine HTML. When writing CSS the goal isn't even to strive for "semantic" class names. CSS classes convey no semantics, at least not to machines. CSS classes should be used to convey semantics to the meat bags reading the code - devs, interested users etc. Nothing else matters with CSS, write it how you like, in as maintainable a fashion as possible and forget semantics in that domain.
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.
I was honestly a little baffled to come into this thread and discover people were having trouble with semantic HTML. It's not hard to use, you just need to be inventive with your CSS. A page without divs, spans, strongs and bigs should be everyone's goal.
The ARIA roles ideas seem to address the semantics/accessibility issues much better than semantic tags.
Plus with the direction that the Web Components stuff is going, I think they should probably scrap all the semantic elements, just stick to a smaller set of HTML elements that are "functionally" different. Then tell everyone to create their own tag-semantics by extending the basic elements for their use-case and use the standard roles taxonomy to describe the intent of the user-created tags.
It feel a bit like parts of the groups are not talking enough :)
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 <main> 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. <main> 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.
For tools which simplify/standarize webpage presentation (e.g., Pocket, Instapaper, Readability) this makes parsing easier.
I'm leaning strongly toward favoring a browser model which just says buggerall to the site's layout and applies a user-specified preference of styling consistently. I'm already pretty much doing this myself via my own CSS mods using Stylebot, and in most cases it makes sites vastly more readable and less distracting.
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
<div class="header">
...
</div> <!-- header-->
Using semantic tags makes it much easier to see the structure.
Thanks for posting this. I just replaced the <section> I was using on one of my projects by a <main>. 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 <section> quite as intended. Using a <div class="main"> wasn't a very sexy alternative either.
Quite sure that when I read the list of HTML5 elements a while back, <main> wasn't in the list! Glad it got added.
The header goes inside of body now? If so then now header no longer means header. For that matter, main seems to be doing what body is supposed to do? Personally I think it should be:
This is completely off-topic, but I wanted to say I love the font used for the headings on this site. "Quicksand," is it? Nice and playful without being completely unprofessional, very good pick.
[+] [-] SCdF|12 years ago|reply
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.
[+] [-] hpaavola|12 years ago|reply
But since the common way of presenting blog is more like this:
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.[+] [-] smackay|12 years ago|reply
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.
[+] [-] coldtea|12 years ago|reply
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?
[+] [-] Pxtl|12 years ago|reply
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.
[+] [-] stan_rogers|12 years ago|reply
[+] [-] designofhomes|12 years ago|reply
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/
[+] [-] rimantas|12 years ago|reply
[+] [-] JonnieCache|12 years ago|reply
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.
[+] [-] crazygringo|12 years ago|reply
Just because, if I were writing a search engine, I would already have a bunch of "AI"/heuristics logic to tease these things out, since most sites don't use semantic HTML5 -- and it would probably do a solid job, since it's easy to compare a bunch of pages from a single site and figure out what parts are changing.
Then, if I actually started assuming that <main> or <article> was always the main/article part, it makes it easier for people to "game" the search engine with keyword-stuffing, etc. So, if I ran a search engine, I'd probably just ignore them completely and rely on my own heuristics.
(For example, Google completely ignores HTML language attributes: "Keep in mind that Google ignores all code-level language information, from “lang” attributes to Document Type Definitions (DTD). Some web editing programs create these attributes automatically, and therefore they aren’t very reliable when trying to determine the language of a webpage." [1] So I wouldn't be surprised if semantic HTML is the same deal.)
I've heard it endlessly repeated that semantic HTML helps SEO, and that's why you should use it. But I've never seen concrete evidence of this -- is there anything that actually backs it up?
[1] http://googlewebmastercentral.blogspot.com/2010/03/working-w...
[+] [-] frenchy|12 years ago|reply
[+] [-] whubr|12 years ago|reply
[+] [-] eli|12 years ago|reply
Lots of people are confused though. This is one of the many problems with semantic markup in the real world.
[+] [-] steveklabnik|12 years ago|reply
[+] [-] WickyNilliams|12 years ago|reply
First let me be clear that there are (at least) two types of semantics on the web, one for machines (bots and screen readers) and one for meat (humans!).
In writing HTML, the goal is not to use every semantically-rich tag available and avoid everything else like the plague. Where you can convey extra semantic meaning, use the most appropriate tag available; where you cannot, use a div or a span or something else. Use of divs does not make your page less semantic - it is not deductive. However use of the correct semantic tags will make your page more semantic - it is additive!
In writing CSS, the goal is not to avoid classes/IDs altogether to keep your HTML "clean". The machines care not if your HTML is rammed full of classes; though you will certainly care when it comes to maintaining your pristine HTML. When writing CSS the goal isn't even to strive for "semantic" class names. CSS classes convey no semantics, at least not to machines. CSS classes should be used to convey semantics to the meat bags reading the code - devs, interested users etc. Nothing else matters with CSS, write it how you like, in as maintainable a fashion as possible and forget semantics in that domain.
Excellent article discussing the fallacies around semantics: http://nicolasgallagher.com/about-html-semantics-front-end-a...
[+] [-] codeka|12 years ago|reply
[+] [-] mmatants|12 years ago|reply
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.
[+] [-] Swizec|12 years ago|reply
[+] [-] brokenparser|12 years ago|reply
[+] [-] ajanuary|12 years ago|reply
[+] [-] nilved|12 years ago|reply
[+] [-] rorrr2|12 years ago|reply
[+] [-] chrisfarms|12 years ago|reply
Plus with the direction that the Web Components stuff is going, I think they should probably scrap all the semantic elements, just stick to a smaller set of HTML elements that are "functionally" different. Then tell everyone to create their own tag-semantics by extending the basic elements for their use-case and use the standard roles taxonomy to describe the intent of the user-created tags.
It feel a bit like parts of the groups are not talking enough :)
[+] [-] mvzink|12 years ago|reply
If you think <main> 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. <main> 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.
[+] [-] Kiro|12 years ago|reply
[+] [-] dredmorbius|12 years ago|reply
I'm leaning strongly toward favoring a browser model which just says buggerall to the site's layout and applies a user-specified preference of styling consistently. I'm already pretty much doing this myself via my own CSS mods using Stylebot, and in most cases it makes sites vastly more readable and less distracting.
In particular crap such as Buzzfeed (I call my styling "unbuzzed"): https://plus.google.com/104092656004159577193/posts/G6pzJBLK...
[+] [-] aroberge|12 years ago|reply
[+] [-] hober|12 years ago|reply
is slightly shorter than
<div class=header>…</div> .header {…}
[+] [-] peferron|12 years ago|reply
Quite sure that when I read the list of HTML5 elements a while back, <main> wasn't in the list! Glad it got added.
[+] [-] jpswade|12 years ago|reply
They have all mapped the ARIA role="main" to the <main> element so assistive technologies can now recognise the <main> element without issue.
[+] [-] wiradikusuma|12 years ago|reply
The bad thing is if the robot is a search engine spider, people will use try to serve different 'main'.
[+] [-] jebblue|12 years ago|reply
[+] [-] dukerutledge|12 years ago|reply
[+] [-] thezilch|12 years ago|reply
[+] [-] phpnode|12 years ago|reply
[+] [-] hober|12 years ago|reply
[+] [-] MLR|12 years ago|reply
[+] [-] Andrex|12 years ago|reply
[+] [-] derefr|12 years ago|reply
[+] [-] pestaa|12 years ago|reply
[+] [-] robinduckett|12 years ago|reply
[+] [-] insertnickname|12 years ago|reply
[+] [-] WayneDB|12 years ago|reply
[deleted]