The W3C has released a new working draft of XHTML 2.0. New things that are added (not completely sure) include:
IDattribute added to the core attribute collection, which means they can be added to the
HREFLANGattribute that can contain a comma-separated list (why not space-separated, for CSS?) of language codes.
HREFTYPEattribute that can contain a comma-separated list of "media ranges". I believe this is similar to the
TYPEattribute we have now, only this is better. It doesn't cause confusion with other usage of the
TYPEattribute. Furthermore, this one allows multiple values. This, in combination with the new redefined
HREFLANGattribute solve all the problems I raised in
PREVFOCUSattributes help with navigation and the requirements listed in their description will increase usability tremendously I believe.
ACCESSattribute doesn't seem really well defined yet and looks really similar to
REV). Anyone with more knowledge about this?
RESTYPEattribute, which specifies a way to embed a style sheet through the
LINKelement. Although "stylesheet" is not listed in the list of possible values of the
*:visitedfor detecting links.
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
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™'
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 just
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, firstname.lastname@example.org so they can be filled as an issue.
Formal issues and error reports on this specification shall be submitted to email@example.com (archive). It is inappropriate to send discussion email to this address. Public discussion may take place on firstname.lastname@example.org (archive). To subscribe send an email to email@example.com 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
<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.
I think you misunderstood me there. Of course
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. :-)
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'
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.
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.