Showing all entries with tag: standards
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 ·
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, 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
browsers, standards
In a recent message to the webkit-dev mailing list, Dean Jackson outlined some details about plans to enable CSS Transitions (and related WebKit-specific CSS visual effects) on SVG properties in WebKit.
Excerpt:
We have plans to allow transitions on SVG properties:
https://bugs.webkit.org/show_bug.cgi?id=21586
I predict that bug will probably get Animations working at the same time (in the engine there isn’t a huge difference).
Of course that will only work for SVG’s style properties, not the attributes (like cx/cy for the positioning of a circle).
Transforms and 3D Transforms were written to be as compatible with SVG as possible. 2D transforms could reasonably apply to SVG (except the SVG specification says transform is an attribute, not a property). 3D transforms are slightly trickier because they could change the SVG rendering model for drawing order. The SVG WG at W3C are currently looking into this - we hope they come up with something that is compatible with what we have proposed.
For more context and a few more details, see the full text of the message.
To follow progress on this work, you can subscribe to WebKit bug 21586.
2009-03-02 ·
browsers, standards
If you don’t know what the getBoundingClientRect method is, you can read about it at the Mozilla Developer Center site or at the Microsoft Developer Network site — or better yet, read what John Resig has to say about it.
WebKit was the last remaining major browser engine that lacked support for getBoundingClientRect (and for the related getClientRects method) — until yesterday, when Sam Weinig landed support for it in WebKit too.
In my book at least, adding another useful supported-across-all-major-browsers feature to the open Web platform is a pretty cool thing. And as far as why this feature in particular is a worthwhile addition, well, you might want to go back on read John Resig’s write-up about it; title: getBoundingClientRect is Awesome.
2009-02-12 ·
browsers, standards, html5
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.
2009-02-09 ·
browsers, standards, events
At the moment, I’m participating in a State of the Web 2009 panel discussion at Web Directions North. Lars Erik Bolstad from Opera is on the same panel and has just announced that Opera has developed a new ECMAScript/JavaScript engine named Carakan that uses a register-based bytecode instruction set and that’s 2.5 times faster on SunSpider than the previous JS engine in Opera, named Futhark.
And by providing an experimental implementation of a mechanism that eliminates the need for a bytecode-interpreter step — by compiling directly into native code — it has the potential to provide even more dramatic speed improvements. On the order of 5 to 50 times faster.
2009-02-05 ·
comments off
browsers, standards, html5
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…)
2008-06-25 ·
·
Next entries »
