The WHATWG Blog

Please leave your sense of logic at the door, thanks!

Archive for the ‘Elements’ Category

(X)HTML 5 will have the only usable implementation of ruby markup

Tuesday, August 14th, 2007

One of the misconceptions about the (X)HTML 5 effort is that there will be no noticeable benefits compared to HTML 4 or XHTML 1.0. Here is one thing to prove this wrong. (X)HTML 5 will have the only practically usable implementation of ruby markup. While this maybe won't make too much of a difference in Europe and America, it sure is good news to a pair of billion people in Asia - and a few thousand theologians and historians.

Ian Hickson, the editor of the HTML 5 specification, said on the WHAT WG mailing list just recently: "I have in fact already begun looking at exactly what the parsing and semantic requirements for <ruby> will have to be. It should be added to the spec in the coming weeks." Currently the only browser that natively supports ruby is Internet Explorer, at least somewhat. This should be great news for Microsoft. For once they will actually have a lead compared to Gecko based browsers, Opera, Konqueror or Safari in supporting a part of the HTML 5 spec.

Keith Bowes, in a recent comment on Molly's blog, says:

Personally, I don’t see the point of HTML5. HTML 4 was a big improvement over HTML 3.2: better internationalization, better support for style sheets, more structure and less presentation, some of the more questionable things were removed or put in the dust bin of de facto obsolescence, etc. But I really don’t see where HTML5 is better enough.

A pair of billion Chinese or Japanese speaking people will beg to differ - and a few thousand theologians. Ruby is a big improvement for them. But wait, I may hear. Ruby is not new. It has been part of XHTML 1.1 for many years now. To which I retort: My point exactly! XHTML 1.1 is namely useless! Here is what its spec says: Content must be served with an XML MIME-type, and we all know that one specific browser with a huge market share does not support true XHTML!

If I want to use ruby markup I can (a) serve XHTML 1.1 as text/html, against all rules and have all IE users benefit, or (b) serve it as it should to users of Gecko based browsers, that can support ruby through an extension, or to all CSS savvy browsers using dedicated CSS-rules. But I can't do both!

Since (X)HTML 5 will have two serializations, this problem will cease to exist. I may use ruby markup and still send my content as text/html.

But there is one more lesson to be learned from this. I am a strong advocate of accessibility - after all I am a theologian first and web developer second - but I see that some of my friends have mistrusted HTML 5 because of accessibility features not yet documented in the spec. Ask questions! I did for ruby. If I had gotten a not so positive response I would have argued my case strongly. But please withhold negative judgments for a while. The process is not over yet. The war is not lost.

Finally, how does ruby benefit theologians? As I see things the best way to produce interlinear reproductions of ancient texts - the kind that we grapple with all the time - is to use ruby markup, where the relationship between the ancient word and the translated word is made explicit also within the markup.

Posted in Browsers, Elements | 5 Comments »

Automatyczne wykrywanie feedów (Polish)

Wednesday, June 27th, 2007

This is a Polish translation of Feed Autodiscovery, translated by Sebastian Snopek.

Ostatnio dodaliśmy typy linków do HTML 5. W szczególności zdefiniowaliśmy mechanizm do automatycznego wykrywania kanału syndykacyjnego. Automatyczne wykrywanie (Autodiscovery) stało się rozpowrzechnione i szeroko stosowane od momentu swoich narodzin w 2002 roku, stosując element link z powiązaniem alternatywnym i atrybut type określającym rodzaj kanału.

<link rel="alternate" type="application/atom+xml"
      href="/feed.atom" title="Atom Feed">
<link rel="alternate" type="application/rss+xml"
      href="/feed.rss" title="RSS Feed">

Jeśli chodzi o kompatybilność wsteczną musimy zachować wsparcie, a szczególnie, zdefiniować tę metodę. Jednakże, istnieją dwa główne problemy z zastosowaniem powiązań alternatatywnych:

Aby poruszyć tę sprawę, wprowadziliśmy nowe powiązanie kanału, które wskazuje na to, że dokument jest kanałem syndykacyjntm. Pozwala to teraz na linkowanie do wielu kanałów zawierających treści, które nie są koniecznie alternatywnymi wersjami strony.

<link rel="feed" type="application/atom+xml"
      href="/feed/comments" title="All comments">
<link rel="feed" type="application/atom+xml"
      href="/feed/summaries" title="Article Summaries">

Oznacza to również, że nie trzeba precyzować atrybutu type , aby link był rozpoznany jako kanał syndykacyjny, a przeglądarki mogą go nadal pokazywać na liście subskrypcji.

<link rel="feed" href="/feed" title="Articles">

Inną korzyścią jest to, że jeśli kiedyś pojawi się nowy format kanału syndykacyjnego to nie trzeba będzie czekać na aktualizacje przeglądarki nowym typem MIME, aby przglądarka traktowała go jako kanał. Na przykład: jeśli czytelnicy twojego kanału mają wsparcie mikrofoormatu hAtom, można przeprowadzić subskripcje dokumentu HTML , który został zalinkowany jako kanał.

<link rel="feed" type="text/html"
      href="/feed.html" title="All comments">

Aby zachować kompatybilność wsteczną, definicja alternate mówi, że jeśli używa się go w kombinacji z atrybutem type z wartością application/rss+xml lub application/atom+xml to jest on również słowem kluczowym dla kanału.

Słowo kluczowe kanału może być również używane w kombinacji z alternate mówiąc, że jest to kanał dla danego dokumentu.

<link rel="feed alternate" type="application/atom+xml"
      href="/feed.atom" title="Atom Feed">

Jednakże, ważnym jest aby nie mylić tego z tym jak działają arkusze alternatywne. Zachowanie rel="alternatywnego arkusza stylów" jest przypadkiem wyjątkowym wtedy, gdy użycie alternate nie oznacza alternatywnej reprezentacji samego dokumentu. Jeśli używa się go z arkuszem stylów, to wartość type nie jest równa wartości kanału.

<link rel="alternate stylesheet" type="application/atom+xml"
      href="/feed.atom" title="This is not a feed!">

Mozilla już raportowała bagi związane z implementacją nowego powiązania feedu a poprawki do rel="alternatywnych arkuszy" są planowanie w nowym Firefox 3.0.

Posted in Browsers, Elements | Comments Off

Feed Autodiscovery

Sunday, December 3rd, 2006

We’ve recently added link types to HTML 5. In particular we defined the mechanism for syndication feed autodiscovery. Autodiscovery has become widely deployed and implemented already since its inception in 2002, using the link element with the alternate relationship and a type attribute indicating the format of the feed.

<link rel="alternate" type="application/atom+xml"
      href="/feed.atom" title="Atom Feed">
<link rel="alternate" type="application/rss+xml"
      href="/feed.rss" title="RSS Feed">

For backwards compatibility, we must retain support for, and explicitly define, that method. However, there are two main issues with using the alternate relationship:

To address this issue, we have introduced a new feed relationship which indicates that the referenced document is a syndication feed. This now allows you to link to several different feeds containing different content which are not necessarily alternate versions of the page.

<link rel="feed" type="application/atom+xml"
      href="/feed/comments" title="All comments">
<link rel="feed" type="application/atom+xml"
      href="/feed/summaries" title="Article Summaries">

It also means that you do not need to specify the type attribute to have the link recognised as a syndication feed and browsers can still show it in the subscription list.

<link rel="feed" href="/feed" title="Articles">

Another benefit of this is that if there is ever a new syndication feed format, you don’t have to wait for browsers to be updated with the new MIME type to recognise it as a feed. For instance, if your feed reader supports the hAtom microformat, you could subscribe to an HTML document that has been linked to as a feed.

<link rel="feed" type="text/html"
      href="/feed.html" title="All comments">

In order to retain backwards compatibility, the definition for alternate says that when used in combination with a type attribute with the value of either application/rss+xml or application/atom+xml.then it implies the feed keyword as well.

The feed keyword can also be used in combination with alternate to say that it is specifically the feed for the current document.

<link rel="feed alternate" type="application/atom+xml"
      href="/feed.atom" title="Atom Feed">

However, it’s important not to confuse this with the way alternate stylesheets works. The behaviour of rel="alternate stylesheet" is a special case where the use of alternate doesn’t mean an alternate representation of the document itself. In fact, if when used together with stylesheet, that is the one case where the type value cannot imply the feed value.

<link rel="alternate stylesheet" type="application/atom+xml"
      href="/feed.atom" title="This is not a feed!">

Mozilla already has bugs filed for implementing the new feed relationship and fixing its bug with with rel="alternate stylesheet" which are planned for inclusion in Firefox 3.0.

Posted in Browsers, Elements | 16 Comments »