browsers, standards, html5
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:
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:
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.
2009-11-13 ·
mobile, browsers
Alessandro Portale has announced the “Tower” release of the Qt for S60. He writes that “there are three fresh modules: Phonon, QtSql and QtWebkit”, and adds that “QtWebkit on S60 is still considered experimental. However, You should already be able to start developing QtWebKit refined applications for the pocket.”
QtWebKit is a port of the WebKit browser engine to the Qt cross-platform application-development framework, and Qt for S60 is in turn a port of Qt to the Symbian OS, widely used on mobile devices.
2009-06-26 ·
browsers
Chris Jones just posted a Multi-process Firefox, coming to an Internets near you write-up to his blog, about the Electrolysis project (coordinated by Benjamin Smedberg, with Joe Drew, Jason Duell, Chris himself, Ben Turner, and Boris Zbarsky) that will add multi-process (one tab per process) support to Gecko. Chris’s blog posting has a video demo that’s worth watching, and last week Ben Smedberg posted a Electrolysis: Making Mozilla Faster and More Stable Using Multiple Processes write-up to his blog that’s also worth reading.
For details on status on the ongoing project, see the Content Processes page on the Mozilla Wiki, or go talk with the developers in real time on the #content channel on irc.mozilla.org.
2009-06-23 ·
comments off
browsers
A recent WebKit bug comment from Gavin Barraclough gives some insights into the rationale for the layered architecture and MacroAssembler used in the current JavaScript engine in WebKit. Some excerpts from that comment:
The abstract code generation layer (MacroAssembler interface down) is layered like a traditional compiler. In a traditional compiler, it is common to have an assembler layer completely independent of the compiler (often a separate application). The compiler takes a source code file, compiles it, and produces an output file of assembly code.…
Layering the compiler on top of an assembler in this fashion provides a number of benefits. For the compiler developer, layering the compiler on the assembler separates the instruction selection from the minutiae of machine instruction encoding. For clients of the compiler providing a well defined language for machine instruction generation is useful if the compiler provides facilities to bypass the higher level language, and directly emit a specific sequence of machine instructions…
The assembler interface within the JIT is designed to closely mimic that of the assembler layer in a traditional compiler…
If that sounds interesting, you can find a lot more details by reading the full text of the comment.
2009-06-22 ·
comments off
browsers, standards, html5
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 »
2009-06-22 ·
browsers, standards
Culled from a recent exchange I had on twitter, the following are some randomly ordered thoughts on privacy protection in Web applications/APIs intended for location-based services (LBS).
- we really don’t want each of N different location-aware applications on a device showing their own Nth-different “location sharing active” dialogs to users
- nobody questions the intentions of any of the proposed LBS privacy-protection solutions; they instead question whether the proposed solutions would actually have the intended effective if implemented
- there are legitimate concerns that some LBS privacy-protection proposals, despite intentions, would risk creating a situation ultimately harmful to users
- any proposal being advocated should be judged on its technical merit, not on its intentions
- advocacy is bad when it means continuing to dogmatically promote a particular well-intentioned-but-unproven solution even after that proposed solution has been legitimately and seriously questioned
- any effective solution must start with not trying to pressure (bully) browser vendors into implementing a particular proposal, but instead working with browser vendors (rather than in isolation from them) to develop a general solution that’s actually workable
- building a specific privacy-protection mechanism into one particular API is not a solution to the general problem of protecting user privacy across different classes of applications
- when legal requirements for privacy protection in applications are not in line with market realities and implementation/user practicalities and/or are not enforceable, the market is going to rightly ignore them
2009-06-22 ·
browsers
On the webkit-dev mailing list back in April, there was an interesting thread that Michael Nordman from the Google Chrome team started with a message titled, “AppCache functionality provided by the embedder of webkit” (related to the offline-Web-applications feature in HTML5). Michael begins that message with this paragraph:
I’m working on the app cache for Chrome. We’ve decided to hoist most the functionality provided by the app cache into Chrome’s main browser process, so we won’t be using most of the implementation provided by WebKit. I’d like to work through what changes to make within WebKit/WebCore to allow an embedder pull that off. Any suggestions would be much appreciated.
Darin Adler responded with some thoughts and a question (to which Michael replied) but the discussion about specifics didn’t go anywhere after that (not on the mailing list at least), because in the next message in the thread, Maciej Stachowiak replied to question the general approach — in fact, to question whether the WebKit trunk should be providing mechanisms to facilitate replacements of parts of its own core code:
It’s been a recurring theme for the Chrome team to request hooks to bypass WebKit functionality and replace it with Chrome-specific code that lives outside the WebKit tree. So far this has been mostly for code developed when Chrome was originally a secret project. While we felt it was best to grandfather in the existing carve-outs, in general I believe this is not the best way to move the WebKit project forward. I would not like to see this pattern replicated for newly developed functionality.
Earlier in the same message, Maciej cites a reason why facilitating the proposed general approach can have a potentially negative side effect:
One downside of this approach is that, if the application cache ever needs to change, it may be necessary to make changes to two separate implementations hosted in different repositories. In addition, quality-of-implementation improvements to one version won’t benefit the other.
Read the rest of this entry »
2009-06-22 ·
browsers, standards, html5
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.
2009-06-21 ·
comments off
mobile, browsers, standards
Cameron Zwarich asks on webkit-dev:
For some time now there has been a bug in Bugzilla about adding conditional support for ECMA Script Mobile Profile.
I am capable of reviewing the technical content of the patch, but I don’t know how the greater WebKit community feels about adding support for ESMP and related technologies. To what extent do we want support for them in the main WebKit tree?
There’s some discussion at WebKit bug 24114
2009-04-02 ·
comments off
mobile, browsers
Some news from Gabor Loki on the webkit-dev list:
we are pleased to announce that the ARM port of JIT is finally released.
The port itself is developed from scratch, but we reused the ideas of x86 JIT. So we implemented property caches, stub functions, etc. in a similar way, but the code is optimized for ARM architectures.
We used Qt4 build environment for the development, but we feel that the other build platforms can be easily extended with this ARM port.
For a few more details, see the full text of Gabor’s posting.
To follow progress on this work, see WebKit bug 24986.
2009-04-02 ·
·
Next entries »
