Home E-mail Subscribe

Showing all entries with tag: html5 Subscribe

WebKit adds support for the HTML5 <ruby> element

If you don’t know what the HTML5 ruby element is, you might want to take a minute to first read the section about the ruby element in the HTML5 specification and/or the Wikipedia article on ruby characters. To quote from the HTML5 description of the ruby element:

The ruby element allows one or more spans of phrasing content to be marked with ruby annotations. Ruby annotations are short runs of text presented alongside base text, primarily used in East Asian typography as a guide for pronunciation or to include other annotations. In Japanese, this form of typography is also known as furigana.

I give a specific example further down, but for now I want to first say that the really great news about the ruby element is that last week Google Chrome developer Roland Steiner checked in a change (r50495, and see also related bug 28420) that adds ruby support to the trunk of the WebKit source repository, thus making the ruby feature available in WebKit nightlies and Chrome dev-channel releases.

A simple example

The following is a simple example of what you can do with the ruby element; make sure to view it in a recent nightly or dev-channel release. Note that the text is an excerpt from the source of a ruby-annotated online copy of the short story Run, Melos, Run by the writer Osamu Dazai, which I came across by way of Piro’s info page for his XHTML Ruby add-on for Firefox (and which I mention a bit more about further below).

きのうの豪雨で山の水源地は<ruby>氾濫<rp>(</rp>
<rt>はんらん</rt><rp>)</rp></ruby>し、濁流
<ruby>滔々<rp>(</rp><rt>とうとう</rt><rp>)</rp>
</ruby>と下流に 集り、猛勢一挙に橋を破壊し、どうどうと
響きをあげる激流が、<ruby>木葉微塵<rp>(</rp>
<rt>こっぱみじん</rt><rp>)</rp></ruby>に<ruby>橋桁
<rp>(</rp><rt>はしげた</rt><rp>)</rp></ruby>
を跳ね飛ばしていた。

If you don’t happen to have Japanese fonts installed, here’s a screenshot of the source for reference:

ruby source markup

Notice that the actual annotative ruby text (which I’ve highlighted in yellow in the source just for the sake of emphasis) is marked up using the rt element as a child of the ruby element, and the text being annotated is the node that’s a previous sibling to that rt content as a child of the ruby element. The final new element in the mix is the rp element, which is simply a way to mark up the annotative ruby text with parenthesis, for graceful fallback in browsers that don’t support ruby.

So here’s the rendered view of that same text:

見よ、前方の川を。きのうの豪雨で山の水源地は氾濫はんらんし、濁流滔々とうとうと下流に集り、猛勢一挙に橋を破壊し、どうどうと響きをあげる激流が、木葉微塵こっぱみじん橋桁はしげたを跳ね飛ばしていた。

And here is a screenshot of how it should look in a recent nightly or dev-channel release:

ruby rendered view

Notice that the annotative ruby text is displayed above the ruby base it annotates. If you instead view this page in a browser that doesn’t support the ruby feature, you’ll see that the ruby text is just shown inline, in parenthesis following the ruby base it annotates. So the feature falls back gracefully in older browsers.

If you’re not accustomed to reading printed books and magazines and such in Japanese, you may be feeling underwhelmed by the example above. But for authors and developers and content providers in Japan who want to finally be able to use on the Web this very common feature of Japanese page layout from the print world, getting ruby support into WebKit is a huge win, and something to be very excited about.

Support in other browsers

Current versions of Microsoft Internet Explorer also have native support for ruby, and you can also get ruby support in Firefox by installing Piro’s XHTML Ruby add-on (and for more details, see his XHTML ruby add-on info page) — so we are well on the way to seeing the HTML5 ruby feature supported across a range of browsers.

WebKit destined to get its own content sniffer

Web/browser-security maven and coder Adam Barth has been working on implementing a content sniffer in WebKit, based on a content-sniffing algorithm that was originally specified in the HTML5 draft, but that’s now specified as a separate IETF draft that Adam is editing and that’s titled, Content-Type Processing Model.

WebKit applications/ports for particular platforms all currently need to rely on platform-specific content-sniffer code outside of WebKit. There are some reasons why it’s a good idea to do things that way — but there are also some good reasons not to; as Adam notes, doing things that way runs the risk of creating compatibility and security differences among various WebKit ports. So implementing a content-sniffer in WebKit itself will eliminate those differences.

Read the rest of this entry »

WebKit team is implementing HTML datagrid element/API

David Hyatt just opened a new WebKit master feature-implementation bug on June 19th: Implement the HTML5 datagrid. His first comment there:

This implementation may end up being very different from what’s in the spec.

The goal is to create a simpler implementation that can help improve the spec.

The <datagrid> element is a new HTML element in the HTML5 draft standard, with a corresponding DOM interface.

Elliotte Rusty Harold did a writeup on datagrid for the IBM developerWorks site a couple years ago, describing it in these terms:

What distinguishes [datagrid] from a regular table is that the user can select rows, columns, and cells; collapse rows, columns, and cells; edit cells; delete rows, columns, and cells; sort the grid; and otherwise interact with the data directly in the browser on the client.

The <datagrid> spec has been updated since the time when that article was published, but at a high-level, the feature remains the pretty much the same as in that description quoted above.

It’s great to see a browser project finally starting to implement <datagrid>, because it’s a great feature that I think a lot of Web authors and Web developers are going to be very glad to have.

Examine HTML5 localStorage and sessionStorage data with Web Inspector

View of Databases panel in WebKit Web Inspector, showing localStorage data of a particular Web app

The Database panel in WebKit’s Web Inspector now allows you to examine HTML5 per-origin client-side persistent data (name-value pairs) associated with a particular Web application — both localStorage data and sessionStorage data. That’s in addition to the ability it already had for allowing you examine per-origin/application client-side SQL data.

If you want to play around with it, feel free to play around with this: simple localStorage demo app. That demo app is a copy of one that Hixie set up at the WHATWG site — with one modification: I added a Delete button so that you can remove items (name-value pairs) and see the results reflected in Web Inspector.

It seems we have Nokia’s Yael Aharon to thank for submitting the patch that added this capability. I’d also guess that, as Yael suggested in the the WebKit bug report associated with the change, the Databases panel will eventually simply renamed Storage.

I’d also guess that capabilities will eventually be added for changing the name-value data directly from within Web Inspector (instead of being limited to only examining the data) — similar to the way that Web Inspector and similar developer tools in other browsers already allow you to change CSS properties and contents of the DOM.

Anyway, here’s hoping that developer tools in other browsers will at least also add the same kind of capabilities that Web Inspector now has for examining client-side persistent data.

URI error-handling in HTML5, and documenting the (real) Web vs. reinventing it

Ian Hickson, the editor of the current HTML5 draft, posted an Error handling in URIs message to the uri@w3.org mailing list outlining some issues related to browser error handling behaviour for URIs, and to IRIs and character encodings other than UTF-8 — and asking, “Is there any chance that the URI and IRI specifications might get updated to handle these issues?”.

That posting and question spawned some spirited discussion, with messages from Julian Reschke, Anne van Kesteren, Tim Bray, John Cowan, Frank Ellermann, and Martin Duerst, and provoking some comments like the following one:

That’s kind of what I said already, and why I guess that HTML5 will never fly: It tries to reinvent the Web, if not the Internet.

…and from Ian to the above, the following response:

Actually we’re trying to not reinvent the Web, but to document it, so that browser vendors can write browsers that handle existing Web content in a fashion compatible with legacy UAs without reverse-engineering each other.

(It’s true that this is requiring defining things that are at odds with existing specifications, but that’s mostly because those specifications aren’t in fact in line with real usage…)

Video interview from XTech

Update: An entry about this video interview and the other interviews that Ian did at XTech is now online at the BBC Backstage site:

Backstage Blog: Video interviews from Xtech 2007

Among the videos that Ian Forrester from the BBC shot at XTech 2007 the week before last is an interview with Steven Pemberton and me. We talk about the Mobile Web Initiative, XHTML2, XForms, HTML5, the <canvas> element, and a few other things.

Use the Click to Play link below to watch the video (warning: requires Flash Player 8).