The Role Attribute

However, I think a lot of aspects of the HTML4 strict DTD are impractical and unnecessary, specifically the content models.

I’m curious. Do you mean things like, anchors not wrapping blocks sort of thing?

Sure, that could be one of them. One of my main complaints would be, for example, the fact that FORM’s content model only allows elements from the %block entity: http://www.w3.org/TR/html401/sgml/dtd.html#block

More elements should have been afforded the ability to accept the %flow entity’s elements as their content model. There’s no reason for it not to be so. HTML5 fixes this.

More elements should have been afforded the ability to accept the %flow entity’s elements as their content model. There’s no reason for it not to be so. HTML5 fixes this.

Ah, that explains why the HTML5 forms I’ve seen often do
<form…>
<label…>…
</form>

I thought they were just copying all the bad “HTML4” code out there, and then wondered if it was just like their
<a href=“foo”><div> ssstuff</div></a>
stuff.

Yes, my point is, it doesn’t allow label or any form controls as a direct child of the form element. Which is why you end up having to use a wrapper div or wrap every label or input in a <p> element. It’s unnecessarily bloated markup, (and yet deathshadow60 has the nerve to say that HTML5 is bloated).

edit: fixed. misread your post at first.

So 50% or so of browsers deployed in the wild being unable to use it without fat bloated javascript assistance that breaks horribly for most people stuck on legacy browsers isn’t enough?

Did I mention Document Type Declarations? No, I mentioned STRICT, which is a document TYPE, but it’s not the declaration…

Though honestly I don’t get where the hate for having something at the top of the document to actually say WHAT version of the specification is being used comes from… Like that’s magically a bad thing. Sure I’m not wild about it having the full URL in there, but honestly I prefer it to the lip service just slap five million different rulesets in there randomly like it was still HTML 3.2 garbage that HTML 5 tries to use.

Of course, just like HTML 3.2 god forbid we have rules for doing this stuff and then be expected to SHOCK FOLLOW THEM!?! But of course the endless hordes of people who need to do the world a favor and back away from the keyboard now just slap an HTML 5 doctype on their 3.2 instead of HTML 4 tranny. Who knew the future of HTML was 1997?

You do know the difference between a DTD and a Doctype right? One is the specification, the other is just a declaration of which one you are using.

Of course that statement of yours is spoken like someone who NEVER understood the point of Strict – being the ACTUAL HTML 4 as opposed to the “let’s just sleaze along the people who can’t pull their head out of HTML 3.2’s backside”. Simpler clearer rules, less tags, less attributes, eliminating redundancies…

Which again the pacifying the people who never understood STRICT seems to be the point of the steaming pile of manure known as HTML 5. STRICT got rid of not just presentational tags like CENTER and FONT, but redundancies too. EMBED and BGSOUND weren’t accepted into it because they were redundant to object. APPLET was deprecated as redundant to OBJECT. IMG was on the chopping block for the REAL HTML5 (before that was pitched in the trash and they went with the WhatWG idiocy) for also being redundant to OBJECT.

So what do they do with HTML 5? EMBED, CANVAS, VIDEO and AUDIO – all redundant to OBJECT.

DIR and MENU were deprecated for being redundant to UL… Now MENU is back but in some wierd twisted form (that I still can’t figure out what it’s even in there for!)

… and of course you have section and NAV, which for all the accessibility talk are next to useless compared to a .jumpto menu done properly with titles and accesskeys, and seem to exist just to mollify the people who insist on slapping wrapping DIV around elements that shouldn’t have them in the first place, and the people too STUPID to figure out how to use a heading tag properly or JHVH forbid have a document structure that actually makes SENSE.

Of course your statement also shows you never understood the point of validation either – because testing to see if you actually opened and closed all your tags properly, nested them properly in terms of block-level and inline-level, used tags and attributes that actually EXIST on the elements you declared them on has to be “pointless” – RIGHT.

Only to those building with incomplete knowledge. Fieldset, one thing you could use.

Just because you end up bloated due to insufficient knowledge, it doesn’t mean p or div where intrinsic to forms. It means you need to dig more and especially it means don’t use your knowledge-less to falsely depict absent problems for those with complete vision over web dev.

The reason you are supposed to use a block level container is so that you have FIELDSETS with LEGENDS – tags that exist for ACCESSIBILITY and SEMANTICS. It’s called accessible forms! Of course much like TH, TBODY, THEAD, CAPTION, LABEL, OPTGROUP it seems like FIELDSET falls into the category of tags that you are SUPPOSED to use and people just sleaze out a DIV or omit it entirely… putting it squarely in the same category as the people who do absolute dipweed nonsense like:


<table>
	<tr>
		<td colspan="4" align="center"><b><font size="+1">Table Title</font></b></td>
	</tr><tr>
		<td>&nbsp;</td>
		<td class="heading">col1</td>
		<td class="heading">col2</td>
		<td class="heading">col3</td>
	</tr><tr>
		<td class="rowHeading">Row1</td>
		<td class="rowData">1-1</td>
		<td class="rowData">1-2</td>
		<td class="rowData">1-3</td>
	</tr><tr>
		<td class="rowHeading">Row2</td>
		<td class="rowData">2-1</td>
		<td class="rowData">2-2</td>
		<td class="rowData">2-3</td>
	</tr>
</table>

Any of you out there who don’t know what’s wrong with the above snippet – might be time for you to learn how HTML actually works.

There are other tags you’re supposed to use – and they are NOT bloat – idiocy like HEADING and NAV are redundant and for most elements ARE bloat since they are extra containers for NOTHING. They seem to exist for the sole purpose of making the people who right now seem to slap DIV around their H1 and UL#mainMenu for no good reason happy.

At least screen readers can make use of fieldsets.

I apologize in advance for the wall of text. Lot’s of things to address here…

What you present here is misleading: By “50% of browsers”, you mean IE - I don’t know why you didn’t just say that. (FF 2.0 is irrelevant now as it comprises an extremely negligible percent of the market share). Your arguments aren’t cohesive. Even once HTML5 reaches recommendation status (which you claim is necessary before using a spec), obviously IE8 and below will still not be able to render HTML5 naturally. You seem to switch your argument from “its not recommended” to “browsers don’t render it correctly anyway”.

Not to mention, one line of code is hardly bloat, and seeing as theres no user-friendly option to disable scripts on IE, I think you can count on it working.

I don’t think there has ever been a conception of a document type that didn’t correspond to a DTD or have a doctype declaration by which to select it. So I guess now you’re referring to the general philosophy of “strictness” (?), which is also faulty if it’s anything like the strict html4 DTD.

Also, you did say STRICT, but you also in the very same sentence mentioned slapping dissenting document type declarations onto html documents:

I don’t know what I’m supposed to gather from that if not the strict doctype and corresponding DTD.

I’m glad you mentioned this. HTML doesn’t require a versioning mechanism because it is and must remain backwardly compatible. Why would you want a versioning system? Why would you want user agents parsing versions of HTML differently? This only increases the amount of nonsense user agents would have to pack in to their parsers. It would only make things more convoluted. We have 3 (technically 4) different rendering modes right now, and you want a versioning system on top of that?

Personally, I wish people would stop calling it the html5 doctype. There is no “html5 doctype”, the html5 spec only requires a blank doctype, lacking any identifiers, for legacy reasons. If doctypes had never been linked to rendering mode switching in the first place, HTML5 documents wouldn’t even have or need a doctype declaration right now. (The language used to describe the doctype in the original html5 draft was much more accurate than it currently is, but it was removed due to worries that it may confuse authors if they didn’t understand the history behind it.)

A DTD is not a specification (it’s much more useless than that). I don’t know where you got that idea. The difference being, a specification is necessary, whereas a DTD is not - it is only a replication of a spec’s instructions, thrown into a context where it can serve as instructions for a parser, but it isn’t even used this way for the majority of html implementations throughout history.

In your post, you said document type, a term which is inextricably linked to either a DTD or a doctype declaration. Like I said, there has never been a conception of a “document type” without a corresponding SGML venture.

I don’t know why you keep mentioning HTML 3.2. It has almost nothing to do with this discussion.

As if HTML5 were reimplementing <center> and <font>??

<embed> wasn’t included in html4 because it was never part of a spec, it wasn’t even considered. It was just a contrived netscape element. Although I do agree, ideally, embed should be dropped. To my understanding, embed was included in the html5 spec because it has a history of behaving better for browsers, despite its lack of consistent fallback capability. More browsers have it implemented. (You should be praising this choice if you’re railing html5 section elements because they aren’t widely implemented.)

You don’t see how <img> is maybe a little bit more semantic than <object>? <object> isn’t descriptive of its content at all. It has to use a vague semantic definition as it can essentially be used to embed anything that is viewable in a browser natively or through use of a plugin. Furthermore, just because something is embedded content doesn’t mean that it should all be handled by one element. That doesn’t make any sense. It’s the <div> of embedded content.

It makes sense to separate <video>, <img>, and <audio> (and other elements that will be natively supported by browsers) from the <object> element. <object> has <param> which is obviously meant for plugins. It’s primarily there to display embedded content that may only be supported by a plugin.

If <object> were used over <video> or <audio>, it would have to define specific parameters to compensate for <track>, and it also doesn’t take into account future practices in which new elements might be incorporated into the <video> and <audio> element’s content models.

Canvas is redundant to object? How could object compare to canvas in any way unless you make use of some poorly coded and unstable plugin that shouldn’t exist on the web in the first place?

<menu> is for defining a menu in such a way that it constructs certain chrome which was previously only available to a browser’s native code. For example, it can be used to create a context menu for a specific form element. Just because it shares the same name as an element that was deprecated in a previous HTML spec doesn’t automatically make it bad. It serves a different purpose now. It also maintains backward compatibility with pages authored to conform to older html specs. It is a list by default.

A <form> element already defines itself as a set of form controls. It doesn’t need an extra fieldset wrapper to explain, once again, that it is a set of form controls. Fieldsets may be useful for different groupings of form controls within a form, but if you’re planning on wrapping the entire contents of a form in a fieldset, what’s the point?

When you require a block element around form controls, authors obviously end up wrapping the content anyway they can. Such a requirement is not useful. A fieldset which wraps the entirety of a form’s content is not terribly useful semantically anyway, even if you’re conforming to html4 standards where you need a legend in every case - this only seems to make it more bloated and arguably, in most cases, it won’t add any useful semantics. The whole point of HTML5 is that it takes a pragmatic and realistic approach to things like content models.

I don’t know what to tell you about your tirade against the sectioning elements. If you think <ul> is more semantic and accessible than <nav>, I really don’t know what to say. You don’t see the benefit in distinguishing <nav><ul>…</ul></nav> from <aside><ul>…</ul></aside>? You say those semantics are useless bloat, but then argue that the (required) use of <form><fieldset>…</fieldset></form> is useful and not redundant?

With regards to divs, I think we can agree that they shouldn’t be necessary.

…but they can’t make use of sectioning elements?

The HTML5 validator algorithm still checks for misnested tags and improperly closed tags. (Unlike html4, The HTML5 spec also makes it a point to define graceful error handling in rendering user agents if someone forgot a close tag or misnested some tags.) The HTML5 validator also still checks to see if content models are being obeyed. However, HTML5 of course has different content models than HTML4, because it’s simply better and more pragmatic. But the HTML5 validator still does essentially everything you say. I don’t see why you’re upset with HTML5 here.

If you think your arguments against html5 can hold their own, why not mention something?

Not yet. But some day. Since I must be accessible, for the time being I must remain with HTML4. Readers have waaaaay too many problems today with mixing HTML5 and ARIA. And then I have to keep in mind that people can’t just upgrade the things whenever they want, unless they’re using a free one.

Hmm, I’m not particularly up to date with the state of screen readers, but they certainly have the potential to acknowledge the semantics of these elements. I did say “can’t”, rather than “don’t” in my post above.

I suppose a more verbose way to tackle what I quoted deathshadow60 saying above is to acknowledge that this isn’t an argument against sectioning elements. Screen readers can’t recognize that a <ul id=“nav”/> is a main nav. They can’t recognize that a <p class=“footer”/> is the footer of a particular section, etc. If they don’t acknowledge sectioning elements as these things either, you wouldn’t lose anything by using sectioning elements. You could only gain from using them when people begin to use more recent releases of screen readers, or when more up to date versions are released.

I’d also like to add, even if screen readers do something like parse class and id names to look for semantic keywords like, “nav” or “footer”, this could still equally be accomplished with any element, including sectioning elements.

Hmmm… Forget about html5. Let’s look at this, pretending it’s xhtml2 we talk about:

Screen readers can’t recognize that a <ul id=“nav”/> is a main nav. They can’t recognize that a <p class=“footer”/> is the footer of a particular section, etc. If they don’t acknowledge sectioning elements as these things either, you wouldn’t lose anything by using sectioning elements. You could only gain from using them when people begin to use more recent releases of screen readers, or when more up to date versions are released.

I’d also like to add, even if screen readers do something like parse class and id names to look for semantic keywords like, “nav” or “footer”, this could still equally be accomplished with any element, including sectioning elements.

What’s the difference? Extension. REAL extension. HTML it’s not just about one type of web pages. It’s about different types of content with different structures. XHTML is about extending HTML, semantically, to that regard. html5, on the other hand, is about one single type of content having a specific structure. What do I do when I have a different structure than the html5 template?

Well, you can always have <toc>. As in table of content. You will jump and say: that’s a <section>. Really? Maybe it’s <nav>? Or <aside>? Or maybe <section id=“toc”>?! Or maybe <nav id=“toc”>?! Or maybe <aside id=“talk”>?! :slight_smile:

Where does id and class attribute for your sectioning html5 elements leave screen readers? In the same place div id=“toc” leaves them now. Except you don’t have to worry about false semantics. Or pretend elements.

The main point you don’t seem to be accepting is that html5 is a template borned after years of div id=“…”. A template used for a specific range of web sites. A template that made many believe it’s the sole purpose for html. There is life outside those. And it’s not carbon based :slight_smile:

html5 is for amateur hour. It’s a jump to “Ahhh, this is what you want?! Come to me I’ll give it to you faster than the others”. It will eventually become obsolete. It will never address the needs of serious developers. It is pushed by corporate interests to attract developers of all kinds!, in a battle for candy work, based on a certain common template. And that’s why I, for one, say it will never stick.

Sorry if this comes off as rude, but I don’t know what to make of your posts anymore.

Ijj: earlier in this post there’s some more detailed information re screen readers. Right now, it’s a mess. Hopefully, when the spec gets sorted out, and then the browsers support that spec, and then the AT vendors support the spec AND work with the browsers’ a11y layers, then added semantic tags will be a benefit.

It’s just something that’s not wholly usable beyond baby steps right now. I can use landmark ARIA roles, but not together with HTML5 (due mostly to bugs in either the browsers or the AT at the moment). There is the known issue with NVDA where a role of navigation on a <nav> element made the reader see two “navigation lists”. This stuff will all change in time. Just not now.

I’m not sure what noonope’s point is exactly, but I do see many of the new tags in HTML5 as being extremely tied in to newspapers and blogs (my opinion). So they’ve made section and article tags, but still no <houselisting> tag or <fineprint> tags… every industry outside news could be happy with their own, more semantic tags (what XHTML promised and failed). Blogs have articles. None of my sites do.
The added stress on being able to have more than one h1 seemed to me to try to answer the problem of the Wordpress setup: one page with no actual content of its very own, but instead a listing of articles, whose titles would be their very own h1’s. Clicking on the header took you to the dedicated page with just that article.
To me that sounds like quite a specific use, but whatever: this means even when I know I can use HTML5, many of the tags will still just have to be divs, because the markup will have to match the content, which is usually very industry-specific in my case.

@ Ijj
No problem :slight_smile: I can’t make much sense of html5 my self either.

@ Stomme poes
Exactly. :tup:

Let’s play present html4 === future html5:

<div id=“nav”> === <nav id=“mainNav”>
<div id=“article”> === <article class=“techArticle”>
<div id=“section”> === <section id=“sectionTop”>

This is what html5 will bring (of course I’m making it biased!). And I’m sure I’m not that inventive as others will prove to be :lol:

You’re referring to the article element, whose semantic description is, “any content that is reusable independent of the site”. While the name of the element may be misleading, names of elements are irrelevant in this context: It doesn’t have to be an article in the strictest sense. The vast majority of content on the web fits this description. The very conversation we’re having (and posting) right now fits this description. I don’t see how it only caters to a small group. Something like <houselisting> actually would cater only to an extremely small portion of the web’s content in comparison.

I don’t know why you see <section> as an industry-specific element either. Any site that uses headings could use the section element.

The possibility of multiple h1’s is brought about by the whole concept of implicit vs explicit sections. The hierarchy of headings can be reset in an explicit section. This can be useful seeing as there are only 6 heading elements. This also makes a lot of sense for the article element. The content in the article element could be viewed independently of the site its a part of, so it might be awkward if it started with an <h4> as its heading.

Are you suggesting that this was only included to benefit WordPress?

I don’t know why you see <section> as an industry-specific element either.

No, section not quite so much… that one I see as more, to differentiate between plain divs-used-to-group-stuff-maybe-mostly-for-CSS-reasons vs “this stuff here should be considered a group of somehow-related content”.

Something like <houselisting> actually would cater only to an extremely small portion of the web’s content in comparison.

Yes, though I’m still touting my <fineprint>… currently I use <small> for fine legalese. I figure it’s small for a reason, not presentation.

The content in the article element could be viewed independently of the site its a part of, so it might be awkward if it started with an <h4> as its heading.

Most of the types of sites I build, don’t have chunks of content who should be considered independent of the page, however I see this on a great deal of blogs, newspapers, article sites (like Smashing Mag) and code repositories. Since blogs and the like are a very large % of the general web, this seemed loosely targetted to me.

It is something to consider when there’s a header for a sidebar (esp a11y-ish headers before a list of different types of lists), but I dunno that I could argue those as h1’s, nor could I reason that some lower header like h2 is somehow a sub-header of the page’s h1… still a markup question I run into regularly.

Are you suggesting that this was only included to benefit WordPress?

No, but I believe these (extremely popular form of web site) were in people’s heads when discussing things like multiple h1’s and <hgroup> possibly as well (I do see the tagline-as-smaller-header thing more often in article-type sites as well).

I could extend this thought to figure/caption. Sure, lots of us have figures with captions (it’s probably great for info-graphics, always a problem for me because somewhere I have to link to a description of the damned thing), but it’s most prominent in newspapers. Not saying it’s only for them, just that you see those more. Most of our terminology for site layout comes from the newspaper industry. I think in those terms often as well.

I guess I’m just seeing a small bias there. It’s not a big deal. It’s not generally going to affect my future markup all that much. And maybe <article> was poorly-named, though what would be better?

Off Topic:

Yesterday I got a copy of Remy’s and Bruce’s book, possibly will explain things better to me

This morning I was walking to work and wondered, does HTML5 want to be descriptive, or proscriptive?