| SitePoint Sponsor |
In xhtml I would use DIV tags to layout my pages, then hook it into my css. But with HTML 5 I now have section and article tags I am kind of confused when to use each. I like the header, nav, and footer tags in HTML 5. When laying out main
sections or sections within sections. Would it be a good practice to continue to use DIV tags or should I use the new tags? And long term will it really affect my page?
At the moment they are of no real value... HTML5 is still a draft and will be for another several years at the earliest. Plus it is in constant flux but if those few elements are basically only main reason you want to experiment with HTML5. Then either use HTML5 correctly (and include them).
Else a more sensible approach might be to use a fully normative markup language like; XHTML 1.0 markup that actually is semantically rich and is better supported by browsers, and search engines will already know how to analyse effectively, etc.
};-) http://www.xhtmlcoder.com/
Thinking Web: Voices of the Community
> March 2013 - SitePoint forums: Spot the Error 3: Calling all Sleuths! Winner Announced!... She knows how to spot simple <code> errors but do you?
Maybe this will help. http://html5doctor.com/you-can-still-use-div/
Where can I learn about HTML 5?Originally Posted by lancewatson
It often seems like the people writing the spec are confused by it too, which is why I have no plans to use HTML 5 for markup any time in the near future... I'll probably wait for HTML 6 Strict which will deprecate all the pointless BULL the steaming pile of manure the "whatWG" barfed up.
My advice, forget that HTML 5 idiocy altogether, it offers ZERO improvements over HTML 4.01 STRICT / XHTML 1.0 STRICT, and in many ways with its' loosening of structural rules, new tags for NOTHING, it just pisses away all the progress we've made over the past decade. The only people who might see benefit from that moronically stupid nonsense are the people who just two years ago were vomiting up HTML 3.2, slapping a tranny doctype on it and having the cojones to call themselves skilled in the field... It certainly isn't meant for anyone who grasped the intent of STRICT, the advantages of semantic markup, or practiced ideas like separation of presentation from content.
The link Dashman gave to html5doctor.com is an excellent resource. And if you read their articles, you'll see exactly what Crusty and xhtmlcoder are talking about: they are still deciding themselves when to use which elements, and it still hasn't settled for many of them.
Regarding section and article, you might specifically want to read up on the HTML5 Document Outline which while still not doing anything yet today, does give you a better idea of how section and article differ. There's also a specific article page about <article> and <section> elements that helps show the difference between the two and (for now) when to use one or the other.
From what I hear, their goal is to create a "living standard" and get rid of the versioning, which is why you get that catchall doctype with no version reference. Don't hold your breath for 6 strict if that is the philosophy.It often seems like the people writing the spec are confused by it too, which is why I have no plans to use HTML 5 for markup any time in the near future... I'll probably wait for HTML 6 Strict which will deprecate all the pointless BULL the steaming pile of manure the "whatWG" barfed up.
I figured the "living standard" junk was in a sort of political retribution for the W3C finally abandoning XHTML2 and announcing that "if there's going to be a new version of HTML, then we should be involved". So today, the W3C has HTML5 and the WHATWG has "HTML the living standard".
Why versioning is a Good Thing: it allows developers to talk to each other about support and behaviour of software like UAs with an actual vocabulary. Like,
"HTML4 forbids inline elements as direct children of form elements, but HTML5 lets you throw anything in there". How do you say that any other way without being a gazilliong times more wordy and confuzling?
Similar with Firefox: they will abandon versions, so at some point you'll be describing a bug and you'll be like, "uh, I have firefox". Right.
Oh I agree about the versioning. But with the minimalist doctype, it pretty much eliminates that in practice right?
Hm, not really.
I guess the doctype was a sort of sign for developers which rules the page is supposed to be following; otherwise, only the validator ever cared. Browsers never did. That's why the "new" doctype works all the way back to IE5 or earlier. Turned out, browsers hadn't been reading them anyways.
What's happening now is, vendors are building browsers who have a (rudimentary since the stuff's still in draft) HTML5 parser. Any documents sent to them as text/html are parsed with that parser, no matter what doctype you use.
But as HTML5 starts becoming real spec, and as random new stuff gets added here and there (sorta like how the modules of CSS3 are being brought to Release Candidate bit by bit), you gotta wonder how the validator will be updated, and will it matter if browsers fall behind?
If a browser decides to follow something new in the spec that does undo something that used to be legal, how does the browser deal with it? The validator? Web authors? A pain in the butt is what it will be.
Meaning: if there is no versioning, something else will, by necessity, have to take its place. It just won't be shown by the doctype anymore.
Ok, I thought the doctype was a declaration to the browsers what rules you were following, and that if you didn't follow those rules, things could break. Which led me to believe that with the new doctype, the browsers will accept everything, and therefore, rather than versioning, the new recommendations will will not have rollouts to completion but additions (like new tags) will be updated gradually as the browsers accept them. Is that not right?
I'm not as pessimistic as poes is. Browser vendors will always make sure that deprecated code will still be rendered correctly and that their new versions will support new additions/changes to the spec as much as possible. Hey, even IE will have a new version every year from now onWhen the <time> element suddenly disappeared from the spec, no browser vendor had any intention to remove it.
On validators: they try to do a good job but don't depend on them. They are machines. Right now I only validate my code when something unexpecting is happening (like I forgot to close an element or something, or made a typo). And eventually they will catch up with changes...
Nope. I mean, sure, that was the original idea: browsers would read the link to the DTD in the doctype and go look up the rules they needed to correctly parse the page. This was exactly the idea for the zombified XHTML2 spec. This was where you and I were going to be making our own tags and stuff. Hahaha. Which you can still do with XML of course...Ok, I thought the doctype was a declaration to the browsers what rules you were following, and that if you didn't follow those rules, things could break.
Of course, imagine how much slower everything would be if all browsers had to go grab a set of parsing rules for every page they loaded. And now imagine one web site might run several different namespaces too. Lawlz. But everyone has high-speed internets now don't they? (sarcasm)
Well, yes and no. No, you can't make an old browser learn new tricks. IE5 sees the <!doctype html> as a full doctype (actually that doesn't even matter, IE5 doesn't have any concept of Quirks Mode or Doctypes much anyways... but IE6 does, and most other browsers since 6 do, even Firefox etc), but it doesn't mean or say anything about the rules.Which led me to believe that with the new doctype, the browsers will accept everything, and therefore, rather than versioning, the new recommendations will will not have rollouts to completion but additions (like new tags) will be updated gradually as the browsers accept them. Is that not right?
As far as rules go with adding new things, all you can know is whether a particular version of a particular browser (again, this will suck hairy dirty monkey balls when Mozilla stops revealing version numbers won't it?) supports a particular feature. We pretty much have this now with CSS3.
If we need to know if someone supports, say, <header> tags (and what does support mean? I'll get to that), now you have to go look it up on some website like caniuse.com or quirksmode.org's compatibility tables. Some browsers will support it and some won't, meaning more and more tags (and attributes and CSS properties) you the developer have to decide who you're going to leave behind, or who you're going to bloat up your code with polyfills for, or whatever. So there, you're right: vendors decide when they think they have a correct implementation of something, and release either versions who later no longer fit the (changed) spec, or conform with the spec. So like remember when webkit and Opera implemented WebSQL? Mozilla and IE didn't. Later WebSQL was dropped. What does this mean? It means if Mozilla and IE ever had the possibility of being convinced to also support it, that possibility is long gone now. And eventually webkit and Opera may remove their support if it gets in the way of other new things or bloats the browser up too much.
Browsers only have to keep backwards compatibility with something they've shipped in the past that has been formally deprecated. Since HTML5 for example is not formally deprecating longdesc or table summary attribute for example, whatever support browsers might have had might just vanish in the next version. They are not required to support it, similar to all the things in the older specs that nobody or one vendor once supported maybe. Also part of the HTML5 idea of "insist on support of what browsers/authors/users already work with".
Support: With HTML5, it's lovley. Some browsers (well, here I guess I just mean IE) have an internal list of acceptable tags. Anything else you throw in there in angled brackets like <foo> which are not on that list, simply do not exist. They are not added to the DOM.
This is why versions of IE who don't know the new HTML5 tags like <header> need Javascript to add those tags to the DOM in the first place. I'm not sure if I think IE was doing the right thing here, or if the other browsers' tolerance to "well it's in angled brackets so let's add it to the DOM even though we're not really sure what a <foo> is" is better. Certainly the latter is easier :)
Then you get everyone else who doesn't know what the tag is: it's added to the DOM, but not part of their default stylesheet. Since browsers are sometimes picky about who's really (in HTML) an inline and who's a block (mostly IE tho :), this kinda sucks, but not so bad. So here's why we're taking all the new tags and setting them to display: block in our stylesheets, because most of these tags are meant to be block elements. Also, because browsers in real life often ignored the HTML4/XHTML1 rules about blocks and inlines anyway (you could always have inlines as direct children of forms and blockquotes, and you could most of the time get away with wrapping anchors around divs filled with stuff, and browsers did their best to figure out what that meant, and mostly figured it out quite well), HTML5 has thrown a lot of those rules out anyway. This, an example of HTML5 trying to be descriptive as well as proscriptive. They wanted to write a spec based on vendor implementations, rather than theoretical rules that didn't physically exist.
The last level of "support" we don't have yet: semantic meaning of the new tags. <header> means nothing to anyone yet, but the idea is that some day it will allow other software and machines to recognise what a document header is. Or what <time> means.
However, so far as I know only one browser had even implemented it (Opera). Suppose, like WebSQL, it was permanently removed from the spec. This means the other vendors get to think about it. They can decide not to support it. After all, it's out, right? Opera, on the other hand, would be unlikely to remove it. Hixie wanted to instead use a broader, less useful <data> element. Suppose that had gone through, and Opera was sitting there with <time> elements with pubdate attributes while everyone else got hip with the jive and implemented <data> elements with no pubdate attribute? It would probably mean we as authors would not use <time>. (One of the arguments against removing time wasn't that it was actually supported anywhere, but that people who build blog and CMS systems (pretty much mostly Drupal and Wordpress in this case) had taken something from a Draft Spec and just added it because they thought it was useful. So in other words,When the <time> element suddenly disappeared from the spec, no browser vendor had any intention to remove it.
"SOMEONE TOOK A DRAFT THINGIE AND ADDED IT SO NOW WE CAN'T TAKE IT BACK OH NOES!"
This is something the spec writers are dealing with anyway. As vendors attempt to implement draft things (which they need to do at least to find out how well or not the new thingie works at all), people start running with it whether it's good or not, doable or not, causes a crapload of new problems or not. If enough people use it, you get <embed>, which is in the HTML5 spec because... everyone supports it. Lots and lots of sites use it. Leaving it out of the spec simply means there a popular HTML tag out there that has zero documentation. So long as browsers support it, people will use it, and there's nothing but a whiny nerdy validator message to tell them otherwise (and the kinds of people who use tags not in the spec are the same kinds of people who don't bother validating anyway, so...). HTML5 wants HTML completely documented.
Why I like vendor prefixes with CSS: the prefix means it's still experimental, and so when it turned out the rest of the world didn't implement something called
display: inline-box;
we could all safely stop using the
display: -moz-inline-box;
stuff we'd been using, and stick to
display: inline-block;
instead.
With HTML, the closest you could do there is use Javascript to detect support and then add tags when supported. I'm not a huge fan of that, but I understand why people do it.
Last edited by guido2004; Nov 23, 2011 at 03:49. Reason: disabled smilies
I really, really, really, REALLY hate the freaking default smilies in my posts. I hate needing to go remember to click that damn checkbox. It should be off by default.
Anyway I just fixed a crappy problem that seems to be an HTML5 issue: I had some form inputs who are being looped through in Javascript and we Do Stuff to their values.
It seems browsers who support input type="number" (who show a spin box, though Safari4/Win isn't showing a spin box and it also didn't work) don't seem to consider those as real inputs, or not added to the nodeList when you do a document.forms.elements call. They all got skipped. Bleh. Back to type="text" for us then. Sucks.
Off Topic:
You write smilies, you get smilies. Oops, sorry ;)
Guido - Community Team Advisor
Do you know where the (database) error is? Add it to the list!
Thinking Web: Voices of the Community
Blog - Free Flash Slideshow Widget
"this will suck hairy dirty monkey balls"
If I was Beavis or Butthead, I might not have been able to retain anything but that
When I build my own browser, it will be named that.
Which is EXACTLY what ***** every last one of us with the IE5 broken box model and other issues with IE prior to 9. When they were released IE 5, 5.5 and 6 were the most advanced and standards compliant browsers available -- it's easy to forget that today... they got there by implementing CSS2 before it was out of DRAFT... and we're STILL paying for that today. M$ is repeatedly faced by the challenge of "break compatibility with sites written for the browser when we implemented the spec before it was done, or break all of them."
... and it's really funny (and so PATHETIC) to watch people making the SAME MISTAKES TODAY.
Which is part of how HTML 5 then ceases to be a specification; the difference between authoritative and informative. Telling people "don't use that old crap" is a good thing, anyone telling you otherwise needs to go shtup themselves with a massive vunshtoklr.
"people are using it" is NOT a reason to put it into a SPECIFICATION... But again, you read the W3C specs, it's obvious none of them have any sort of engineering backgrounds.
Do I want to know what that is?with a massive vunshtoklr
Posting Permissions
Reply With Quote
Bookmarks