The W3C has released a new working draft of XHTML 2.0. New things that are added (not completely sure) include:
CLASS and ID attribute added to the core attribute collection, which means they can be added to the HTML element.
HREFLANG attribute that can contain a comma-separated list (why not space-separated, for CSS?) of language codes.
HREFTYPE attribute that can contain a comma-separated list of "media ranges". I believe this is similar to the TYPE attribute we have now, only this is better. It doesn't cause confusion with other usage of the TYPE attribute. Furthermore, this one allows multiple values. This, in combination with the new redefined HREFLANG attribute solve all the problems I raised in HREFLANG and TYPE considered harmful!
NEXTFOCUS and PREVFOCUS attributes help with navigation and the requirements listed in their description will increase usability tremendously I believe.
ACCESS attribute doesn't seem really well defined yet and looks really similar to REL (and REV). Anyone with more knowledge about this?
RESTYPE attribute, which specifies a way to embed a style sheet through the LINK element. Although "stylesheet" is not listed in the list of possible values of the REL attribute. Strange.
*[href] instead of *:link and *:visited for detecting links.
SEPARATOR it is.
DI element to combine the DT and DD elements. Great!
There is probably more, just read it yourself. This was just a quick 30 minutes scan of me.
Mmm, very interresting. Thanks for laying it out for us.
I like most of these, but I am still a little worried about hreflang and hreftype being able to have multiple values. This comes back to new languages/types being added all the time and keeping the links updated with that.
I like the new metainformation module, since I think it is pesky to keep external RDF files updated when you change a document. (Believe me, I tried.) Hopefully you can now dump some of the RDF and include that in the XHTML directly.
But like Anne stated, this just makes it even more confusing for more people, and I hope it won't backfire on the specification as being too complex. Although, I do believe that more people will adopt this than RDF.
Very informative. Anne, you are a gem of the standards community. This is the kind of forward looking coverage we need, not to mention we all should be sharing our insights with the W3C before each recommendation is finalized.
According to Arve the ACCESS attribute is a replacement for the 'evil by design™' ACCESSKEY attribute.
Awesome, another spec that will remain ignored for 5 years.
This is odd:
Separators: in previous versions of HTML, the hr element was used to separate sections of a text from each other. In retrospect, the name hr (for horizontal rule) was badly chosen, because an hr was neither necessarily horizontal (in vertical text it was vertical), nor necessarily a rule (books often use other typographical methods to represent separators, such as a line of three asterisks, and stylesheets can be used to give you this freedom). In order to emphasize its structuring nature, and to make it clearer that it has no essential directionality, hr has been renamed separator.
I thought HR was frowned upon because it was a presentational element, giving style to the page. I was surprised to see it make a comeback. I agree with the new name change and what it suggests, but the default styling is the same as HR!
The default style for this break is a horizontal line in Western languages.
Despite that, a lot of this new spec seems pretty good. The NL and L tags are a step in the right direction, along with 'src' being allowed on any element. (Though these were already in XHTML 2.)
Sadly a lot of junk from HTML 4 seems to remain. Tags like 'samp' are surely redundant? (Use 'code'.) And isn't it time to rename 'blockquote'? (Laughable when an inline quote is marked up with just 'q'.)
What we should have is a whole new improved set of tags, not what looks like HTML Plus.
SAMP is still useful. I use it sometimes. XHTML 2.0 creates QUOTE, so that shouldn't be a problem ;-).
I agree that we should have a new set of elements though. But I think you have to look at Web Forms and Web Apps from WHATWG, not at the W3C.
And isn't it time to rename
blockquote? (Laughable when an inline quote is marked up with justq.)
I would rather like to see q renamed to quote (much clearer). And that was precisely what they did. So no inconsistancy there. :-)
Sorry for repeating you there Anne, we posted at exactly the same time it seems. :-)
I still think the whole concept of xhtml2, as it is today, has a problem and that the current spec represents the least innovative new version of the lingua franca of the web the W3C could have done. Just for fun, take a look at the example showing the start of an html instance when an XML schema is declared... In my opinion, this spec should be dropped entirely.
Just to clarify, my view on what ACCESS seems to be stems from a suggestion I posted to the W3C HTML mailing list last year, and should, until someone from within W3C verifies my view, be treated as "educated speculation"
Perhaps I'm just contrary, but I don't see hr as presentational at all. It demarcates between a before and an after. What it does not do is enclose everything before or everything after, but then again, neither do headings. What's the big deal?
Anne, If you have comments, I encourage you to send them to the WG ML for it, www-html-editor@w3.org so they can be filled as an issue.
Formal issues and error reports on this specification shall be submitted to www-html-editor@w3.org (archive). It is inappropriate to send discussion email to this address. Public discussion may take place on www-html@w3.org (archive). To subscribe send an email to www-html-request@w3.org with the word subscribe in the subject line.
Joe, I think that only the name was a big deal.
Karl, I will address the issues mentioned in the post on that list, thanks for the pointer.
Joe: HR is an abbreviation/initialism for Horizontal Rule. While it's use might have been reasonably sane (in the LTR or RTL world at least), it's name isn't.
I am still a little worried about hreflang and hreftype being able to have multiple values. This comes back to new languages/types being added all the time and keeping the links updated with that.
I don't think it's necessary to maintain a list of all available versions of a referenced resource with those two attributes. Quite the contrary. Think of the following example.
There's a map at the URI http://example.org/maps/europe that is being
referenced. Example.org uses content negotiation based on the Accept-Language &
Accept HTTP-Headers sent by the user agent. Suppose the author of the document
referencing said map wants to link to a specific version of the map, say the
french-language-version in PDF format. Without the attributes the author can't ensure
that the reader following the link to the map will get the exact version he's
referring to, because the version sent to the reader would be negotiated between user
agent and webserver, so that the reader could quite possibly end up with an SVG-File
in english language.
I really like the concept of those attributes and think your concerns are unfounded
(Imagine a <hr /> here)
[
Hreftype] can contain a comma-separated list (why not space-separated, for CSS?) [of MIME types]
From my understanding the difference between a space-separated list and a
comma-separated one is that all values of the former apply to the element (take the
class attribute, for example) while a comma-separated list states an
order of preference (for instance the font-family property in CSS or the
face-attribute of the font-element ;) in HTML).
Still, I think you have a point as there is afaik no suitable selector in CSS to match a comma-separated list.
@Gerrit:
I think you misunderstood me there. Of course hreflang and hreftype are necessary when linking to documents on your own site. I was actually referring to linking from your site to other sites which you have no control over. But you still need them. :-)
@Charl
No, I think you misunderstood me. The two attributes in concern are imo unnecessary when linking to resources on a server under your control (e.g. your site), because, well the server is under your control.
It's different when linking to resources on other sites, though. For instance <a href="http://example.org/document" hreflang="nl" /> could be equivalent to <a href="http://example.org/document.html.nl" /> if the server's using content negotiation.
The attribute doesn't mean The resource linked to in the href attribiute has the language 'nl'
but rather User agent, please request the resource linked to in the href attribute with an
(Similar, but not identical logic applies to the Accept-Language: HTTP-Header of 'nl'hreftype-Attribute)
In my view, they are unnecessary for most links in the future. Thus, you don't "need them". They're still useful for special cases and will be used increasingly as content negotiation will become more widespread.
You are right with your interpretation of those two attributes designating language and type of the referenced resource according to the HTML4 spec. Not so with XHTML2 where those attributes have an entirely different meaning and are, imho, very useful.
@Gerrit
Oh ok, sorry I see what you mean now. I didn't actually look at those in the XHTML 2.0 specification. They changed the meaning somewhat of those attributes. Thanks for explaining, very interesting.