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.
<html><head></head><body>
<article>lorem ipsum</article>
<nav></nav>
<form>search</form>
<footer></footer>
</body></html>
But since the common way of presenting blog is more like this:
<nav></nav> <form>search</form>
<article></article>
<footer></footer>
[1]: https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Flexi...
<html>
<head></head>
<body>
<article>
<nav></nav>
<form></form>
<main></main>
<aside></aside>
<footer></footer>
</article>
</body>
</html>
Why do you think this is "hacky"? This is precisely what absolute positioning is for.
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.
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?
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'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.
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
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.
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...
Eh, I doubt it. The problem with the "semantic web" is that your semantics might not match my semantics. You might use <article> only for the main content of an article-like page, whereas I might use it for each separate piece of text.
Lots of people are confused though. This is one of the many problems with semantic markup in the real world.
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...
<main id="content" class="group" role="main">
<div class="main">
...
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.
<user class="spam">Buy my pills!</user>
<user rel="nofollow">Buy pills
<a href="fizz://example.net/pills">here!</a>
</user>
[0] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/if...
If it sounds hard, remember that people said the same thing about making layouts without tables in the early 2000s. Semantic and compliant HTML means a more accessible website and that's more important than literally anything else in web development.
The actual article area will (should) accommodate the semantic tags well (main, article, aside, figure, etc).
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 :)
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.
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...
<div class="header">
...
</div> <!-- header-->
is slightly shorter than
<div class=header>…</div> .header {…}
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.
Quite sure that when I read the list of HTML5 elements a while back, <main> wasn't in the list! Glad it got added.
They have all mapped the ARIA role="main" to the <main> element so assistive technologies can now recognise the <main> element without issue.
The bad thing is if the robot is a search engine spider, people will use try to serve different 'main'.
<header role="banner">
[...]
</header>
<body id="content" class="group" role="main">
<div id="divcontent1" class="aclass" role="arole">
[...]
</div>
</body>
<footer role="contentinfo">
[...]
</footer>
<article>
<header>...</header>
<content>...</content>
<footer>...</footer>
</article>