The Internationalization Working Group has published a First Public Working Draft of Requirements for Hangul Text Layout and Typographyand is looking for feedback.

This document describes requirements for general Korean language/Hangul text layout and typography realized with technologies like CSS, SVG and XSL-FO. The document is mainly based on a project to develop the international standard for Korean text layout.

Please send comments to public-i18n-cjk@w3.org ( subscribe , archives) by 14 June

.

A Korean versionof the document is also available (한국어 텍스트 레이아웃 및 타이포그래피를 위한 요구사항), but the English version is the authoritative version.

A report summarizing the MultilingualWeb workshop in Romeis now available from the MultilingualWeb site. It contains a summary of each session with links to presentation slides and more detailed scribing done on site in Rome. Links to video for each session will be posted soon.

With approximately 150 attendees, the Rome Workshop focused on the theme “Making the Multilingual Web Work” and emphasized information about the best practices and standards that help content creators and localizers ensure that the World-Wide Web lives up to its name, across boundaries of language and culture. Attendees heard from a variety of perspectives, with fruitful dialogue between various stakeholder groups involved in trying to expand the multilingual scope of the Web.

Taking place over two days (12 and 13 March, 2013) at the headquarters of the UN’s Food and Agriculture Organization (FAO), the Workshop featured twenty-four conference-style presentations, seven poster presentations, and an “open space” discussion that featured six breakout sessions focusing on key topics that emerged during the Workshop. In addition, it showcased technology implementations of the forthcoming internationalization Tag Set (ITS) 2.0 standard.

The Workshop was sponsored by the EU-funded QTLaunchPad project and Verisign . It was run by the MultilingualWeb-LT Working Group.

FEISGILLT 2013 will showcase the upcoming Internationalization Tag Set 2.0 standard, together with closely related, core localization standards like XLIFF. FEISGILTT 2013 is the preconference event of Localization World, London 2013

. W3C members will get 20% discount for FEISGILTT. FEISGILTT participants are entitled to a 10% discount when registering for the main conference. However, registering for the main conference is NOT required to register for FEISGILTT.

Unicode Bidirectional Algorithm basics is a repackaging of the initial part of “What you need to know about the bidi algorithm and inline markup” as a standalone article. It provides a gentle introduction to the behaviour of the Unicode Bidirectional Algorithm, and helps you understand why bidirectional text in Arabic, Hebrew, Thaana, Urdu, etc. behaves the way it does.

The deadline for position papers is 30 April 2013. Please submityour (brief) position paper soon to ensure you have a place.

eBooks & i18n: Richer Internationalization for eBooks on 4 June 2013 in Tokyo, Japan, will investigate international requirements related to eBooks that needs to be added to the Open Web Platform. The Open Web Platform includes core W3C technologies such as HTML, CSS, SVG, XML, XSLT, XSL-FO, PNG, RDF, and many more, that are used extensively in eBooks and eBook production.

The goal is to make the various eBook reading platforms suitable for electronic books that use the printing and typesetting traditions of different cultures.

See the Call for Participationfor details.

UPDATE 2013-04-23:Brian Kardell has posted a related follow-up titled Off With Their Heads: Disband the W3C?. I recommend reading it.

These are some personal thoughts on Matthew Butterick’s “The BOMB in the GARDEN” talk at TYPO San Francisco“. They do not represent an official W3C position.

• The W3C doesn’t “adopt” standards; the market does.
• The W3C doesn’t really even create standards for Web browsers; browser vendors do.
• The W3C brokers the creation of standards by providing a place for browser vendors and others to get together to reach agreement on details of new browsers technologies in such a way as they’re willing to actually implement them.
• The W3C has zero means for “enforcing” standards for browser technologies.
• Browser vendors make their own choices about what to implement and what not to, and when to implement, and how long they take to get around to implementing.
• The plan Matthew Butterick seems to be proposing in this talk is that browser vendors quit working together to get agreement at any standards body & instead do… something else.
• The only alternative he puts forward for that something-else part is a vague vision of “a web that’s organized entirely as a set of open-source software projects”.
• He suggests Linux, Apache, Perl, Python, WordPress as precedents. None of those really have anything at all to do with client-side browser technologies. None of them is a model that could be used as a replacement for developing standards for browser technologies.
• Standards are more than just software; they require very detailed, unambiguous specifications in order to achieve interoperability (if we have learned nothing else during the last 20 years, we have learned that—the hard way). And tons and tons of testing, too. And they require a lot of tough, time-consuming work to reach agreements on.
• Getting agreements among implementors is the really hard part, and there’s no magic to make the process of reaching agreements quick, easy, and painless.
• People disagree. Organizations disagree. The task of us all working together to try to overcome our disagreements is time-consuming, often very frustrating, and almost never easy.
• Nowhere in Matthew Butterick’s talk is there a real proposal for how we could get agreements any quicker or easier or less painfully than we do now by following the current standards-development process.

Creating HTML Pages in Arabic, Hebrew and Other Right-to-left Scripts
This tutorial has been modified to bring it in line with the current tutorial format. Rather than contain duplicate content, it now introduces the novice to key concepts and points off to useful further reading in an organized fashion. It has been completely rewritten.

Text direction and structural markup in HTML
This article has been created from material formerly in the tutorial “Creating HTML Pages in Arabic, Hebrew and Other Right-to-left Scripts” and augmented with information about new HTML5 markup constructs that are beginning to see adoption. It should be regarded as a new article, focusing on applying bidi markup to document- and block-level content, including forms.

What you need to know about the bidi algorithm and inline markup
This is an update of an existing article, but it has been almost completely rewritten. The most significant changes are the new parts describing how to apply the new HTML5 constructs which are beginning to see adoption. Additional changes will be needed as HTML5 bidi markup is finalised over the coming months. The article also proposes a simpler way to approach markup of bidi text, particularly useful for those with less experience, that relies less on a deep understanding of the issues involved.

Visual vs. logical ordering of text
This is a new article created from material that has been removed from the previously mentioned articles. It was removed into a separate article because visual ordering is much less important these days, and to avoid duplication. Only a few changes have been made to the content itself.

For Mobile World Congress 2013, W3C worked with several developers including Tomomi Imura (Nokia), Steren Giannini (Joshfire), and Dominique (Dom) Hazaël-Massieux (W3C) on two Web applications to demonstrate some of the new capabilities of HTML5 and related technology. I asked some of them about their experiences creating a camera app, a photo gallery app, and the server-side technology to stitch them together. The resulting demo worked as follows:

• The camera app takes pictures, displays them on the camera, and can post them to various sites, including W3C's own server.
• The W3C server receives the photos and publishes a feed that is updated as new photos arrive.
• The gallery app reads the feed and displays the photos useful on a variety of devices, in our case: smartphone, tablet, television, and laptop.

The camera project began in the Core Mobile Web (Coremob) Community Groupas a way to illustrate both the current capabilities and limitations of the Open Web Platform (OWP).

Ian: Tomomi, when did this project start?

Tomomi: Originally, the app was nothing more than a prototype I wrote for fun. John Kneeland, from Nokia also wanted to work an app that would showcase the capabilities of the OWP. The Coremob CG seemed like the right venue, and we developed the specsin the fall of 2012, shortly before a Coremob face-to-face meeting.

Ian: The Open Web Platform intends to lower the cost of cross-device development (see the related interview with Todd Anglin on the Kendo UI survey). As you built the camera app, what did you find was relatively easy to make work across devices? What was difficult (and how did you solve it)?

Tomomi: Creating a user interface that is platform independent is one of the keys to cross-platform development. When I created the UI for the camera app, I designed it to be independent of the platform's look-and-feel, so a common CSS was all I needed. Non-trivial CSS works fine on all targeted smartphone browsers so I can say that designing the UI was the easiest part. Also, canvas works as expected on most browsers so I did not need extra workaround to support cross-platform.

However, to be honest, it was not as easy to make it cross-platform as I initially expected. A big reason is that the app was meant to showcase new features, which means it relies on new Web technologies that are in the early phases of standardization and not yet broadly interoperable. I found there was no browser that implemented correctly all the APIs I used in the app. In particular, I struggled to use IndexedDB to write photos to local storage. At the time I was coding, only Firefox and IE10 had implemented IndexedDB according to specification. Chrome 18 (was the released version at that time. Now, finally Chrome 25 is out of beta) supports basic IndexedDB, but was using an older version of the specification with no blob support for the database. I had to write extra code to make the demo work on Chrome.

Beside the workaround code, I used PhoneGap for Windows Phone 8 because IE10 for mobile lacks HTML Media Capture capability, although all other features worked fine. This is a hybrid app that, I think, is useful for illustrating how to work with HTML5 in a transitional mode where features not yet available on certain platforms.

Ian: What would you like to do next with the camera app? It's an open source project - are you looking for help from the community on specific aspects?

Tomomi: We have a bunch of things in the pipeline, notably writing tutorials on all aspects of building this app (like providing camera access using HTML media capture, storing pics in IndexedDB, etc.). We also have a nice table with all the key features required to build this app and how well (or poorly) they are supported in different browsers. I definitely want to share our experience in more detail with developers. Before doing that, I plan to simplify some of the code (to remove some hacks). This will cause more browser incompatibility, but my goal is not to promote hacks and tricks, but rather working with Web standards.

Ian: Steren, Joshfire volunteered to be part of this project because you already had a Web-based gallery app. What has been your experience so far (generally) getting your app to work across different devices? In particular, the app works on some televisions. What has been your experience so far with Web technology on televisions?

Steren: Joshfire is creating tools to build applications for today's devices and the ones coming tomorrow. For us, Web technologies are the logical solution to build a multi-device application that is sharing the same codebase on all these devices. The Web Gallery was developed under this model: 80% of the code is shared by all the versions of the app, and the remaining 20% is just for layout adaptation, view hierarchies, and user interactions.

Web technologies have been selected by TV manufacturers as the official tool to build applications for connected TV. That's a good thing and their browsers are now getting better. It was not the case in 2011, where some TV browsers had critical bugs and suffered from major performance issues. Today, it is more easy to develop for TV, I would say it is similar to mobile web development.

Ian: From your perspective, what are the priority features of the Open Web Platform where you think we need to make progress in order to close the gap with native platforms?

Steren: I think developers need features, frameworks and documentation that will help them to build rich client side applications more easily. And to close the gap with native platforms, they also need to be able to access device specific sensors and features (as enabled by projects like Phonegap). Native platforms have application ecosystems that are more than simple URLs: they ask permissions, install locally and auto-update in background. I think the Open Web Platform should provide the same mechanisms. An important priority is also to identify browser problems in the implementation of the specifications. Today, developers notice too many implementation differences that do not appear to be a priority for browser manufacturers.

Ian: Dom, you built the server that hosted the camera and the gallery apps. What were your priorities in building the server? What solutions did you adopt?

Dom: As in any other project, my priority was to do as little as needed. In this case, the server mostly had to act as a go-between for the camera and gallery apps, receiving pictures from the former to display with with the latter.

I chose to develop a node.js-based solution, since I was confident it would let me assemble the various pieces I needed easily; also, one of the features that we were likely to use, Server-Sent-Events, is much easier to implement in an asynchronous environment such as the one provided by node.js.

Ian: We set up this apps to run in a local environment (that is, not on the Web). If we wanted to make available a Web version of these apps, what would you have to change in the server configuration? How would you deal with security? Privacy? Flooding our server with photos?

Dom: There are two options for having the app run in an open environment:

1. Put some sort of access control in front of the upload feature, where only selected users would be allowed to upload pictures, or
2. Put some sort of moderation in place so that any picture would need to be validated before being pushed to the gallery.

The first approach would require some changes in the camera app and the server-side component. The second would require a new client-side component, and would also benefit from different kinds of Denial of Service attack protection (e.g., rate limiting the number of pictures that can be uploaded, using techniques to avoid robot-based submissions, etc.).

I would probably handle privacy issues at a different layer. We would need a policy and a process to determine when and how a given picture can be posted (e.g., asking the submitted to vouch they're not posting a picture of someone without their agreement), and how pictures could be taken down.

Ian: Thank you all for the insights, and good luck with the evolution of these apps!

The CSS WG published the first Working Draft of CSS Overflow Module Level 3