W3C Team blogs' Galaxy

Fourteen months ago, the US Federal Trade Commission issued a staff report on privacy that endorsed a Do Not Track mechanism; seven months ago European Commissioner Neelie Kroes laid out her challenge to standardize Do Not Track by June 2012. And last week, the Tracking Protection Working Group held its third face-to-face meeting in the iconic Berlaymont building in Brussels: we thank the Commission for their hospitality.

Commissioner Kroes welcomed the group noting the importance of a standardized solution to help with legal compliance — what Kroes's adviser Carl-Christian Buhr labeled "a common tool and approach". FTC Chairman Jon Leibowitz, who observed part of the meeting, praised the W3C practice in his remarks: "an approach that we like enormously invites everyone to the table in an open, public and international consensus-building process". And both the Commissioner and the Chairman noted the breadth of representation at the meeting; we welcomed the participation of browser vendors, online advertising trade groups, analytics providers, data protection authorities, Web publishers, academics and consumers rights groups, among others.

This meeting represents a significant milestone in the group's work, transitioning from mapping out the problem space to resolving significant issues. We had a very full and very productive three days in Brussels, closing more issues than in the prior four months combined. The public can expect to see new and more complete drafts published within the month.

Hard work still lies ahead: remaining open issues include the exact definition of the extent of a "party", the breadth of exceptions for "operational purposes" and details of a JavaScript API. We are excited to see energetic progress and participation within the group and appreciate the ongoing support of both EU and US officials.

Opera announced their TV app store at CES 2012. I took the opportunity to chat with Andreas Bovens, Group Leader Developer Relations and Divya Manian, Web Opener about Opera and the Open Web Platform on diverse devices.

IJ: What are Opera's development priorities on different platforms?

AB: We are on a lot of platforms including desktop (Windows, Mac and Linux), mobile (Android, Symbian, J2ME, iOS, BlackBerry, Meego), and selected TVs. All of these are important to us, so it's not like we prioritize desktop more than mobile - development continues simultaneously on practically all of these platforms.

IJ: How do you maintain market share on so many different devices?

AB: On the desktop we rely on word of mouth. But on mobile, the situation is different, especially with Opera Mini. People like Opera Mini because it runs on a lot of devices and improves performance through compression. Lately we have been striking deals with carriers that see a lot of Opera Mini usage on their networks. The carriers like the fact that Opera Mini uses less bandwidth. And users appreciate the lower costs. Some carriers are even promoting the browser themselves: "With our network you can use Opera Mini." We are driving growth through operators, and that share is growing. Opera Mini has a strong presence in CIS, Indonesia, India, Nigeria, and a large number of other African countries, and we also see fast growth in Latin America and the Middle East.

IJ: Interesting. Why is that?

AB: Opera runs well on all hardware - not only on the latest state-of-the-art devices. In some cases, we've gotten traction with a certain critical group of users, and then adoption spreads virally - this was the case with Opera Mini in Indonesia, which took off and reached critical mass in a short time frame, but there are many more examples.

IJ: Meanwhile, the Open Web Platform keeps growing. How do you manage?

AB: We have our core engine, which runs about everywhere. We built it with mobile and performance in mind, then ported it to the desktop. There are some components that we include on the desktop (e.g., integrated mail) that we don't ship on mobile or TV. But there are no browser concessions across the devices. There are some different behaviors according to the platform (e.g., which video codec is supported).

IJ: Do you find the lack of a single Royalty-Free video codec for the Web a problem?

AB: I think WebM plays an important role. I am not sure whether we need another one. On mobile devices we don't implement the codecs ourselves; we use the support provided by the underlying system (e.g., H.264 on Android).

DM: From where I stand WebM seems to be a robust solution we should adopt. I think we hear more complaints about video from developers than from users. Developers are the ones that struggle. Video codecs are a problem, but that's true for almost all the HTML5 features.

IJ: The Open Web Platform consists of a lot specifications at varying degrees of maturity and implementation. What do you think is critical to the success of the platform?

DM: Developers have been promised a lot of magical things. But when they start to use the features, they find the reality does not yet match the promise. Some implementations may be broken or only half-completed. Or a draft specification can change radically, invalidating implementations and causing confusion among developers. Today some developers are focused on Webkit even though there is inconsistency even among different Webkit rendering engines. When developers optimize for a single browser, they leave others in a lurch. What we need to do collectively at W3C is promote robust implementations. We need to have tests before we start implementing. We should also be quick to drop older implementations (that are broken) before developers come to rely too much on them.

IJ: Do you think implementers are likely to wait for tests before implementing?

DM: This is a persistent issue in the world of implementers. But it is still worth suggesting.

AB: Much of what we see is that developers rely on a specific browser (e.g., Webkit) and they forget about other engines on various devices, including Opera, Firefox, and others. The problem seems most persistent on mobile, perhaps because of Webkit's market share. Things break and developers don't understand why; or they don't notice the problem, of if they do they do browser sniffing to avoid the problem.

DM: The Android browser implementation of HTML5 is pretty broken.

IJ: What can be done?

AB: In our developer outreach we've been trying to warn developers. A monoculture of one rendering engine is likely to backfire as it has in the past. A monoculture of one rendering engine was disastrous for the Web - we're only just getting rid of IE6 now, and China still has 20% IE6 share. A monoculture on mobile will be even worse. Some people rely on Webkit defaults thinking they are standard features.

DM: Some browser vendors are considering implementing Webkit prefixes. But we need more outreach to developers. To developers I would like to say: in your demos, make sure that those demos have the right prefixes. At least when you are showcasing them.

IJ: You opened the Opera TV app store. How do you see the TV market changing?

AB: Traditionally the TV market has been closed. HTML5 apps running on a TV is a new concept that is opening up the market. We'll have to be careful that there's not too much fragmentation.

IJ: Tell me about the store.

AB: The television industry wants people to engage with social networks and access Web-based content from their TVs. We feature access to sites that have been optimized for TV (e.g., 4-way navigation through a remote control).

IJ: What is your vision for multi-screen scenarios?

AB: We are looking into this. WebSockets can be used for these sorts of interactions, and media queries and feature detection play an important role when it comes to adapting content for different devices However, there are other technical aspects to be decided upon - for example, the interaction modes differ from screen to screen: there is touch input, 4-way remote control input, etc. Without a doubt, this is something for implementers and standards bodies to look into and decide on.

IJ: Tell me about getUserMedia: accessing the camera and privacy UI.

DM: If you want to share your camera image you can use APIs to capture images and render them back as a data URI. This will allow people to create image manipulation apps.

AB: The overall effort is towards real-time communications and augmented reality. You use a camera stream and plot information on top of it, or do analysis. There are a number of use cases. The direction is towards WebRTC (Web Real-Time Communications).

DM: You might also combine it with WebGL for 3D rendering, and bring gaming, video, and 3D interactions more into the browser.

AB: Yes, you could create WebGL objects and place them in a video. You need orientation events as well. I believe there are some iPhone or Android apps that do this natively. All the new standards that have been implemented in the past year will provide new ways to interact with content. We have only just scratched the surface of what people will be able to do once we start to combine these features. More experimentation is necessary.

IJ: How difficult or easy is it to combine these technologies in innovative way?

DM: Right now we are at the edges of finding out how they work together. We don't yet know what we will find (e.g., performance issues). We need to experiment, and this will also tell the people writing specifications what to fix.

AB: Sometimes you can combine things you didn't know worked together. For example, you can combine SVG and media queries in interesting ways, for instance changing the SVG rendering depending on the resolution (even though SVG is resolution-independent). That's something that people in the media query work weren't thinking about. But people discover interesting uses and it works cross-platform!

IJ: What should we expect in Opera 12 and when?

AB: We're working hard on 12, and while we can't say yet when it will be ready, people can track progress on our desktop team blog as well as our standards support pages. One of the things we're working on is GPU-accelerated WebGL support for instance, and there is also the earlier mentioned getUserMedia integration.

IJ: I hear from others that using the GPU makes a big difference.

AB: In the long run we are looking at offloading other things to the GPU as well. As far as I understand a lot has to do with how things are architected; there are not immediate performance gains for hooking directly into GPU. It's not magic. There are more architectural things that need to happen. What will get better? Some animations, but not everything magically. You may not need it for ordinary page rendering.

IJ: Any advice for W3C? Where to focus? What to change?

DM: I'd like to see specifications become standards more quickly. I understand why they take time but it would be great to speed things up. Also, I'd like to see more developers and designers learn what to do "first hand" from the specifications. A lot of people get their information 2nd or 3rd hand from browser vendors. That also results in people creating apps that are specific to an old way of doing things.

AB: I agree that education of how to use web technologies the right way is important (as we said about vendor prefixes). It is important that people learn how to use features in a way that doesn't cause sites to fail on new devices, for example by using fallbacks.

IJ: Do you have suggestions around good practices for living with vendor prefixes?

AB: In general we suggest that people include all the known vendor prefixes. There are also a couple of JavaScript libraries that take the pain out of doing that. Or online tools. Or Sass, which gives you programming language features that CSS doesn't have.

AB: I think people need to think about mobile differently. We work directly with people to improve their code. We sometimes see that people handle "Opera compatibility" as a business development request. It's like they think they have to support another platform, but the purpose is the opposite - that you write once and with little effort it can run anywhere. People designing for one platform miss out on what the web has to offer. Project coordinators need to understand the values of developing with standards.

DM: Use standards. That's the best way forward for getting something on multiple and varied range of devices.

IJ: Thank you both for the conversation!

>> Use UniView

The major change in this update is the update of the data to support Unicode version 6.1.0, which should be released today. (See the list of links to new Unicode blocks below.)

There are also a number of feature and bug related changes.

What UniView does: Look up and see characters (using graphics or fonts) and property information, view whole character blocks or custom ranges, select characters to paste into your document, paste in and discover unknown characters, search for characters, do hex/dec/ncr conversions, highlight character types, etc. etc. Supports Unicode 6.0 and written with Web Standards to work on a variety of browsers. No need to install anything.

List of changes:

• One significant change enables you to display information in a separate window, rather than overwriting the information currently displayed. This can be done by typing/pasting/dragging a set of characters or character code values into the new Popout area and selecting the icon alongside the Characters or Copy & paste input fields (depending on what you put in the popout window).

• Two new icons were added to the Copy & paste area:

  Clicking on this will display the characters in the area in the lower right part of the page with all relevant characters converted to uppercase, lowercase and titlecase. Characters that had no case conversion information are also listed.

  Clicking on this produces the same kind of output as clicking on the icon just above, but shows the mappings for those characters that have been changed, eg. e→E.

• Where character information displayed in the lower right panel has a case or decomposition mapping, UniView now displays the characters involved, rather than just giving the hex value(s), eg. Uppercase mapping: 0043 C. You will need a font on your system to see the characters displayed in this way, but whether or not you have a font, this provides a quick and easy way to copy the case-changed character (rather than having to copy the hex value and convert it first).

• There is also a new line, slightly further down, when UniView is in graphic mode. This line starts with ‘As text:’, and shows the character using whatever default font you have on your system. Of course, if you don’t have a font that includes that character you won’t see it. This has been added to make it easier to copy and paste a character into text.

• There is also a new line, slightly further down, when UniView is in graphic mode. This line starts with ‘As text:’, and shows the character using whatever default font you have on your system. Of course, if you don’t have a font that includes that character you won’t see it. This has been added to make it easier to copy and paste a character into text.

• Fixed some small bugs, such as problems with search when U+29DC INCOMPLETE INFINITY is returned.

Enjoy.

Here are direct links to the new blocks added to Unicode 6.1:

• Arabic Extended-A
• Sundanese Supplement
• Meetei Mayek Extensions
• Meroitic Hieroglyphs
• Meroitic Cursive
• Sora Sompeng
• Chakma
• Sharada
• Takri
• Miao
• Arabic Mathematical Alphabetic Symbols

This Open Web Platform weekly has quite a lot of stuff. Among the important things being discussed for the last week, Mark Notthingham announced that there is a will to recharter the HTTP WG for working on HTTP 2.0. The thread on the HTTP WG mailing list has been huge.

The indexedDB specification doesn't explain how to generate keys. Jonas Sicking (Mozilla) explained how indexedDB keys were generated in Firefox.

Arun Ranganathan (Mozilla) has published a new Editor's draft of the File API for review. (Full Thread) and Cameron McCormack (Mozilla) has published a version of WebIDL for Last Call. Vincent Scheib (Google) announced that the Mouse Lock specification has been moved and renamed Pointer Lock.

Following a blog post by Tobie Langel (Facebook) about the mess of manifests for Web apps (widgets, extensions, etc.), Robin Berjon is asking if the Web Apps WG should work on aligning those to a common format. We have to note that there was a normative format already defined in the widget specification, but which was not followed by all implementers.

will HTTP verbs LINK and UNLINK be resurected, it is what James Snell is proposing with a few use cases.

Another go is being done at the recurring topic about responsive images.

Ilya Sherman (Chromium) is proposing to add an autocomplete attribute to the input element. The proposal is documented on the wiki.

A request for a new comment element triggered a very long answer by Ian Hickson (Google) on the nature of the article element.

This column is written by Karl Dubost, working in the Developer Relations team at Opera Software.

The latest release of the Open Web Platform weekly is mostly about Web Apps WG.

The group in charge of WebSocket Protocol is rechartering. They specifically want to define extension to WebSocket including

1. to define a per-frame compression extension to improve the bandwidth usage.
2. Define a multiplexing extension to improve the scalability of the WebSocket protocol
3. Define timeout-handling capabilities to reduce the chattiness of the protocol

Jonas Sicking (Mozilla) in Colliding FileWriters in File Writer API is wondering about the opportunitiy of having a FileWriter.close() if multiple pages create a FileWriter for the same FileEntry at the same time. (full thread). The File Writer API would allow Web applications to write files on the disk. That could become very handy by helping users to keep the control of their data using a distant Web services to process data, but keeping all data locally.

Charles Pritchard (Jumis) asked what is happening when the audio element is removed from the DOM while playing. The specification defines it and implementations follow the specification with very small differences.

Dimitri Glazkov (Google) is proposing to augment the HTML parser to recognize new elements. It might be needed by the Shadow DOM and HTML templates specifications. Though Henri Sivonen (Mozilla) is not convinced it is worth the cost of modifying the algorithm.

This week, the theme of Anne Van Kesteren's report is about… the new year and treats of the Web Platform.

This column is written by Karl Dubost, working in the Developer Relations team at Opera Software.

I was unlucky enough two months ago to start to experience loss of my (computer) identity, occasionally at wake froms sleep. My computer terminal would show "I have no name!" in the prompt instead of my user name, would claim that I am 501, when it should say I'm koalie. Of course, ssh would not want me, telling me to go away as I don't exist. So I rebooted a couple time and grumbled a lot.

Vlad suggested something was wrong with LDAP and my colleague Thomas diagnosed that opendirectoryd was crashing. All true.

It happened again tonight and Vlad found a way to restart opendirectoryd (in Terminal.app):

sudo launchctl
stop com.apple.opendirectoryd

Which restarts opendirectoryd.

I'm none the wiser on what triggers the opendirectoryd crash at wake from sleep. But I'm glad this works when the crash happens.

I had a great time reading a paper on Semantic Search[1]. Although the paper is on the details of a specific Semantic Web search engine (DERI’s SWSE), I was reading it as somebody not really familiar with all the intricate details of such a search engine setup and operation (i.e., I would not dare to give an opinion on whether the choice taken by this group is better or worse than the ones taken by the developers of other engines) and wanting to gain a good image of what is happening in general. And, for that purpose, this paper was really interesting and instructive. It is long (cca. 50 pages), i.e., I did not even try to understand everything at my first reading, but it did give a great overall impression of what is going on.

One of the “associations” I had, maybe somewhat surprisingly, is with another paper I read lately, namely a report on basic profiles for Linked Data[2]. In that paper Nally et al. look at what “subsets” of current Semantic Web specifications could be defined, as “profiles”, for the purpose of publishing and using Linked Data. This was also a general topic at a W3C Workshop on Linked Data Patterns at the end of last year (see also the final report of the event) and it is not a secret that W3C is considering setting up a relevant Working Group in the near future. Well, the experiences of an engine like SWSE might come very handy here. For example, SWSE uses a subset of the OWL 2 RL Profile for inferencing; that may be a good input for a possible Linked Data profile (although the differences are really minor, if one looks at the appendix of the paper that lists the rule sets the engine uses). The idea of “Authoritative Reasoning” is also interesting and possibly relevant; that approach makes a lot of pragmatic sense, I wonder whether this is not something that should be, somehow, documented for a general use. And I am sure there are more: In general, analyzing the experiences of major Semantic Web search engines on handling Linked Data might provide a great set of input for such pragmatic work.

I was also wondering about a very different issue. A great deal of work had to be done in SWSE on the proper handling of owl:sameAs. On the other hand, one of the recurring discussions on various mailing list and elsewhere is on whether the usage of this property is semantically o.k. or not (see, e.g., [3]). A possible alternative would be to define (beyond owl:sameAs) a set of properties borrowed from the SKOS Recommendation, like closeMatch, exactMatch, broadMatch, etc. It is almost trivial to generalize these SKOS properties for the general case but, reading this paper, I was wondering: what effect would such predicates have on search? Would it make it more complicated or, in fact, would such predicates make the life of search engines easier by providing “hints” that could be used for the user interface? Or both? Or is it already too late, because the ubiquitous usage of owl:sameAs is already so prevalent that it is not worth touching that stuff? I do not have a clear answer at this moment…

Thanks to the authors!

1. A. Hogan, et al., “€œSearching and Browsing Linked Data with SWSE: the Semantic Web Search Engine”€, Journal of Web Semantics, vol. 4, no. December, pp. 365-401, 2011.
2. M. Nally and S. Speicher, “Toward a Basic Profile for Linked Data”, IBM developersWork, 2011.
3. H. Halpin, et al. “When owl:sameAs Isn’t the Same: An Analysis of Identity in Linked Data”, Proceedings of the International Semantic Web Conference, pp. 305-320, 2010

Filed under: Semantic Web, Work Related Tagged: Linked Data, OWL, semantic search, Semantic Web, Web search engine

I spoke with Gilles Drieu, Vice President of Software Engineering at Motorola Mobility, about his participation in W3C.

IJ: What motivates you to participate in W3C?

GD: From the early 90's, I have always had a passion for the web. I think it's important to continue to push the web with open standards. The people I work with at Motorola Mobility come from different backgrounds but we share a "common DNA," which drives our interest in standards work. Part of our common DNA is that rich graphics are important and now, finally, they are converging with open standards.

IJ: So rich graphics are keys to taking the web to the "next level"? (I saw a number of great demos featuring rich graphics at W3Conf in November.)

GD: I would say there are three keys. The first is that video and audio will be available on any browser and any platform, natively, through open standards. The idea of being able to watch a video as simply as you can display an image and text is fundamental. You don't want the tedium of installing plug-ins or having to use complex markup. Browsers have default controls for this content, which simplifies its publication.

GD: We also need the web platform to support premium content. Integration with digital rights management (DRM) would close the loop with some important content providers. There are encouraging discussions going on between the HTML Working Group and the participants of the web and TV Interest Group. The fact that Adobe has announced that it will not pursue Flash on mobile devices means that there is an incredible opportunity, but we need to act quickly.

GD: The second key is to be able to create animations and spatial transformations using open standards (such as CSS transforms, transitions and animations). Except for some details, this work is mostly done. The web developers’ community has embraced the technology. Also very exciting, the WebKit community is now innovating with new concepts such as CSS shaders and filters.

GD: The third key is performance. Video and graphics are processing intensive. On mobile devices, native applications take advantage of hardware acceleration by using graphics processing units (GPUs). There is a lot of expertise out there from people who have worked on Flash, Silverlight, iOS, and so on. W3C has been essential to get the people with that expertise to the standards table, and they are now designing a high-performance run-time environment. These people have deep expertise on WebKit and GPUs, and they are joining others that have deep access to expertise on publishing or tooling. Because they have come together in various W3C groups and applied their diverse skills to standards, we have made a leap of progress in the past five years.

IJ: Where do big performance leaps come from?

GD: If you want to avoid using the CPU and battery of a mobile device, you need to leverage GPU technology. Native apps have some advantages today because they use libraries that are GPU-optimized. In mobile, your frame rate falls apart unless you use the GPU. There have been great performance strides in Javascript as well. Standards are "showing the way" but there needs to be more of a feedback loop between implementation/optimization and semantics.

IJ: I'll mention in passing that W3C has launched a Web Performance Working Group and is investing more in testing.

GD: This is so important! Having a formalized way to profile your web app or your web content is something we need to do clearly. It would be cool to standardize a way to add instrumentation in runtimes. Because expressive graphics and media are so intensive, you can't cheat on mobile. It shows. You'll notice, for example, better animation performance with WebKit since the libraries it uses are GPU-accelerated. If we could enable the rest of the world to instrument their code, that would help everyone get to that level of performance.

IJ: When do you think web apps will reach the same performance?

GD: I expect the gap will go away in 1 or 2 years. On both mobile and desktop.

IJ: Do native apps have other advantages today that you see going away?

GD: Native apps can leverage more native system APIs, so developers can access more the device capabilities. W3C's Web Applications Working Group and DAP Working Group are working on bringing those APIs to the web. If we can standardize device APIs that provide developers access to the whole device, efficiently (which should not be a problem for standard functionalities), then I think we will really see the emergence of a ubiquitous, cross device web platform and an ecosystem based on open standards.

IJ: Can you say a word about Motorola's participation in W3C?

GD: We are interested in web technologies for mobile devices based on Android. To become a “player” (meaning a relevant contributor and potentially an influencer) in the web world, you have to do 2 things: be active in open source (contribute to WebKit) and be involved in open web standards. Our investment in being part of the web community is essential to us. That's why were are here at W3C.

IJ: Thank you, Gilles!

The decision by the Financial Times to launch a Web application made headlines in 2011. I recently spoke with Mary Beth Christie, Product Director, and Dan Skinner, Head of Design about their experience so far.

IJ: How did you get started with HTML5 and the Open Web Platform?

MBC: We launched the iPad native app in April 2010 and were blown away by its success. We had no aspirations for the iPad app other than it work. It was so successful we thought we would have to do this for every device (and there was a lot of hype about new devices). There was no way we could come out with new apps for new devices and new systems at that point. Around the same time we began discussions about creating a Web app. We asked our development people to see if it worked, but then kind of forgot about it until February 2011. We then sat down with our developers and it was amazing. The Web app was doing most of what we needed (e.g,. swiping). There were some questions about offline storage, but we decided it was worth pursuing. We reset our priorities and released the Web app in June 2011. We now have over 1 million users of the Web app. A lot of customers have switched over from the native app.

IJ: How is user experience different?

DS: The Web app and native experiences are very similar. We had set out to mimic the native app and make the transition to the Web app seamless. Although it was tricky to achieve precisely the same quality (e.g., access to apis), we quickly got very close (say, 80-90% the same user experience). We have since stopped development of the native app and are aggressively developing the HTML5 version.

IJ: What characteristics of the Web app approach stand out for you?

DS: You don't have to download anything; you just visit the Web. Faster start-up provides an improved user experience. You can download the app icon to the homescreen too which can then enable offline caching.

MBC: Some other benefits: marketing is easier. You can just say "Visit app.ft.com." Development times have gone down, it's easier to debug problems and deploy fixes, and we have shortened release cycles.

IJ: Did anybody notice the difference?

MBC: We've had super positive response from users overall. But the experience is so close many people probably did not recognize the difference. We resolved some glitches from the initial release and now things are running smoothly.

IJ: Do you see value in staying in stores (e.g., to reach more customers)?

MBC: We have discussed this but have concerns about supporting diverse versions of the app. We don't know enough about the testing costs. In theory, it sounds like a great idea to have multiple versions but in practice you need to test and bug fix for multiple devices. Having a generic app that can be used across several different devices is more cost-effective. And because there is more consistency across devices, this is less confusing to users.

IJ: One thing we've talked about lately is how the Web platform lets you link devices in new ways (see the blog post from Dominique Hazaël-Massieux). Have you looked at any multi-device scenarios for the Financial Times?

DS: We have looked into the TV angle a bit. Until recently that market has been small, but now there is an explosion in smart TVs. In theory porting TV is a simple matter of a new style sheet. But in practice we would have to treat it like another platform. It will be interesting in the future, however.

IJ: Did you change what content you offer when you switched to HTML5, or are you planning to add, say, more video?

DS: Not really. We already have significant video content that app users appreciate.

MBC: While video is an important avenue, it's not going to take the place of text any time soon. We are not a broadcasting house.

IJ: What pieces of the stack are missing?

DS: We would love to see notifications.

IJ: We may have some work going on in that area; see Web Notifications.

DS: There are quite a few things where we had to work to reach parity with the native solution. For example, for proper caching we ask the user (via a dialog) to extend the memory of the device. For swiping interactions, we had to do a lot to make it smooth.

IJ: Did you use any framework or libraries to help out?

DS: We looked at a number of those tools but in the end we pretty much wrote things from scratch.

IJ: Do you have other apps you plan to convert to HTML5?

MBC: We have an app for our magazine "How to Spend It" that we would like to convert to HTML5. However, there are some challenges. It is rich in gorgeous images. We've encountered some performance issues.

DS: Those assets are large and that has an impact on the smoothness of the experience. Ultimately we would like to emulate a glossy magazine.

IJ: Does typography play an important role in your apps?

DS: Interesting question. We do use certain typefaces in our apps, but we don't use them on the Web site. Custom fonts on the Web have been tricky until about a year ago. On platforms with well-understood capabilities (e.g., the iPad) it would be unusual not to use custom fonts.

DS: An area of interest to us has to do with online charts. You expect two features: vector graphics and interactivity.

IJ: Are you using SVG for vector graphics?

DS: Not yet. We use raster images but I would like to see us move in the direction of SVG. We really value interactive graphics. We have a lot of flash interactives on the site (e.g., to demonstrate timelines, to implement slide shows) We've not yet found a way to translate them. I think it is primarily a workflow issue. The tools aren't there yet for producing several HTML5 charts a day. But we'd love to get there.

IJ: Any other things you would like to share?

DS: One overarching theme is the "write-once deploy everywhere." We have really found HTML5 useful for that. However, it's not as easy as it could be. There are still browser interoperability issues. It takes a lot of fine-tuning to achieve a polished experience on multiple platforms.

IJ: Can you design for big classes of devices (for example "big screen," "tablet," and "mobile") and then refine from there?

DS: That's true, you have to cleverly work out some core layout options first, for example related to number of columns or pixel density. But even once you've done that you still run into issues such as "people who use this environment expect desktop icons to appear in specific positions." So for the best experience, you need to do more than tweak your CSS. You have to treat it like a different product.

DS: HTML5 offers a huge advantage, but in the end it still requires work. The degree of work depends in part on the nature of the app. For example, our text-heavy app requires a lot of alignment. It is also the case with more features (e.g., caching) that there are fewer examples out there to compare.

IJ: Thank you very much for your time!

I’m just back from 3 weeks off. I’m restarting the Open Web Platform weekly summary with an incomplete summary of what happened in the last few weeks, but mostly things that caught my eyes. The next weeks editions will be hopefully better.

HTML5

A global translate attribute will be added to HTML5. The values are yes or no with the same inheritance policy than the lang attribute. The goal is to specify if a piece of text should or not should not be translated automatically. For example, you might have the following markup 

<p lang="en">Mr <span translate="no">Hope</span> 
is speaking at…</p>

When translating from English to French, the string “Hope” will not be translated to “Espoir” in French.

There were a lot of discussions about what are the right encodings for the Web platform. A draft, Encoding, has been started to summarized these elements.

Web Apps

Speaking to your computer to create a query and have a result in return. Controlling (commanding) your computers to do certain actions by voice. These are things that would be allowed on Web applications if there was a Speech API. A call for comments has been sent to the WebApps WG. The proposal came after the work of the W3C Incubator Group about HTML Speech. You can read the first version of a draft for an HTML Speech API.

The Shadow DOM first draft has been published. It is a method of establishing and maintaining functional boundaries between DOM subtrees and how these subtrees interact with each other within a document tree, thus enabling better functional encapsulation within DOM. Follow the discussion.

Art Barstow (Web Apps WG co-chair, Nokia) has published a list of expectations for the year 2012. It gives a good overview of the directions taken by the Web Apps WG

DOM

document.characterSet has been chosen over document.charset which was barely implemented.

CSS

Web Architecture

The TAG has published a new finding on identifying Application State trying to draw best practices with regards to the use of hash signs in URIs for example. They also published a page summarizing the issues around persistence of identifiers.

HTTP

The HTTP WG has posted new version of the HTTP 1.1bis specifications. Julian Reschke noted that It shows that we’re getting close to LC; most of the changes are minor.

Elsewhere

• Reading List – Vendor prefixes, mobile, monoculture
• How to make a Web standards proposal
• Concise XPath
• A new validation service in town
• Preliminary implementation of CSS3 features for fonts by IE

This week, the theme of Anne Van Kesteren’s report

This column is written by Karl Dubost, working in the Developer Relations team at Opera Software.

The W3C held its first purely online event in November, the Social Business Jam. The motivating concept is that standardized social web technologies can enable a whole new round of innovation throughout the entire product cycle, both by "socializing" communication between customers and the enterprise as well as communication inside the enterprise itself. The W3C Jam was enabled via IBM's Collaboration Jam platform, and Watson was used to analyze the results of thousands of posts in order to determine trends and next-steps.

Over a thousand people attended the Social Business Jam, including both visionary innovators such as Tim Berners-Lee and Alex "Sandy" Pentland, discussing jointly with the business technologists such as Evan Prodromou (CEO of Status.Net) and Angel Diaz (IBM's Vice President of Software Standards). The discussion ranged from identity management to social metrics, and a number of innovative concepts were discussed in detail such as the ability to "prioritize" messages into activity streams and how to make e-mail a first-class social technology. In particular, the further development of standards around the federated social web are crucial to most business use-cases.

The final report of the Social Business Jam details a number of recommendations for standardization and use-cases. The main recommendation is to form a Social Business Community Group to develop customer driven use-cases for social business and mature standards around these use-cases - so join the Social Business Community Group!

Today W3C WAI published updated Techniques for WCAG 2.0 and Understanding WCAG 2.0, following a public review period. For background on the stable WCAG standard and this updated supporting material, read the October 2010 blog post.

About the Techniques

First, understand that the basis for determining conformance to WCAG 2.0 is the success criteria from the WCAG 2.0 standard — not the techniques. The Techniques document provides guidance that is "informative". You do not have to use the sufficient techniques to meet WCAG. Web content can use other ways to meet the WCAG success criteria. Web content could even fail a particular technique test, yet still meet WCAG a different way. Also, content that uses the published techniques does not necessarily meet all WCAG success criteria.

To learn more about the techniques, please see:

• About the Techniques section of How to Meet WCAG 2.0: A customizable quick reference...
• Sufficient and Advisory Techniques section of Understanding WCAG 2.0

About this Update

The updated documents published today include more coverage of non-W3C technologies (Flash, PDF, Silverlight), which will help developers who are using those technologies make their content more accessible. However, publication of techniques for a specific technology does not imply that the technology can be used in all cases to create accessible content that meets WCAG 2.0. (For example, the Flash Techniques for WCAG 2.0 say: "Flash accessibility support for assistive technology relies on use in Windows operating systems, using Internet Explorer 6 or later (with Flash Player 6 or later) or Mozilla Firefox 3 or later (with Flash Player 9 or later).") Developers need to be aware of the limitations of specific technologies and ensure that they create content in a way that is accessible to all their potential users.

Changes in this update are highlighted in diff-marked versions at: Techniques for WCAG 2.0 (Diff), Understanding WCAG (Diff).

(Note: The first links above go to the latest version of the documents. The "dated" versions of this update are: Techniques for WCAG 2.0 (dated URI), Understanding WCAG (dated URI) The difference between these links are explained in Referencing and Linking to WAI Guidelines and Technical Documents.)

Help Develop Techniques

Updating and expanding these WCAG supporting documents is on-going work, and we welcome your contributions.

• You can send in your ideas for new techniques via the Techniques for WCAG 2.0 submission form.
• You can comment on what's already there via the web form or e-mail listed in the Instructions for Commenting on WCAG 2.0 Documents.
• You can actively participate in the WCAG Working Group, writing and reviewing new techniques.

And finally, a big thanks to the WCAG Working Group and everyone who is contributing to providing updated WCAG 2.0 Techniques!

The W3C TAG is pleased to announce the publication of a new TAG Finding "Identifying Application State."

URIs were originally used primarily to identify documents on the Web, or with the use of fragment identifiers, portions of those documents. As Web content has evolved to include Javascript and similar applications that have extensive client-side logic, a need has arisen to use URIs to identify states of such applications, to provide for bookmarking and linking those states, etc. This finding sets out some of the challenges of using URIs to identify application states, and recommends some best practices. A more formal introduction to the Finding and its scope can be found in its abstract.

The W3C TAG would like to thank Ashok Malhotra, who did much of the analysis and editing for this work, and also former TAG member T.V. Raman, who first brought this issue to the TAG's attention, and who wrote earlier drafts on which this finding is based.

These are notes on using CSS @font-face to gain finer control over the fonts applied to characters in particular Unicode ranges of your text, without resorting to additional markup. Possibilities and problems.

Changing the font used for certain characters

Most non-English fonts mix glyphs from different writing systems. Usually the font contains glyphs for Latin characters plus a non-Latin script, for example English+Japanese, or English+Thai, etc.

Normally the font designer will take care to harmonise the Latin script glyphs with the non-Latin, but there may be cases where you want to change the design of the glyphs for, say, and embedded script without adding markup to your page.

For example, if I apply the MS-Mincho font to some content in Japanese with embedded Latin text I’m likely to see the following:

Let’s suppose I’d like the English text to appear in a different, proportionally-spaced font. I could put markup around the English and set a class on the markup to apply the font I want, but this is very time consuming and bloats your code.

An alternative is to use @font-face. Here is an example:

@font-face {
  font-family: myJapanesefont;
  src: local(MS-Mincho);
  }
@font-face {
  font-family: myJapanesefont;
  src: local(Gentium);
  unicode-range: U+41-5A, U+61-7A, U+C0-FF;
  }
p {
  font-family: myJapanesefont;
  }

The result would be:

The first font-face declaration associates the MS-Mincho font with the name ‘myJapanesefont’. The second font-face declaration associates the Baskerville font with the Unicode code points in the Latin-1 letter range (of course, you can extend this if you use Latin characters outside that range and they are covered by the font).

When specifying src the local() keyword indicates that font-face should look for the font on the user’s system. Of course, to improve interoperability, you may want to specify a number of alternatives here, or a downloadable WOFF font. The most interoperable value to use for local() is the Postscript name of the font. (On the Mac open Font Book, select the font, and choose Preview > Show Font Information to find this.)

Note how I was careful to set the unicode-range values to exclude punctuation (such as the exclamation mark) that would be used by (and harmonised with) the Japanese characters.

Adding support for new characters to a font

You can use the same approach for fonts that don’t have support for a particular Unicode range.

For example, the Nafees Nastaliq font has no glyphs for the Latin range (other than digits), so the browser falls back to the system default.

With the following code, I can produce a more pleasant font for the ‘W3C’ part:

@font-face {;
  font-family: myUrduFont;
  src: local(NafeesNastaleeq);
  }
@font-face {
  font-family: myUrduFont;
  src: local(BookAntiqua);
  unicode-range: U+30-FF;
  }
div p {
  font-family: myUrduFont;
  font-size: 60px;
  }

A big fly in the ointment

If you look at the ranges in the unicode-range value, you’ll see that I kept to just the letters of the alphabet in the Japanese example, and the missing glyphs in the Urdu case.

There are a number of characters that are used by all scripts, however, and these cause problems because you can’t apply fonts based on the context – even if you could work out what that context was.

In the case of the Japanese example above, numbers are left to be rendered by the Mincho font, but when those characters appear in the Latin text, they look incorrectly sized. Look, for example, at the 3 in W3C below.

The same problem arises with spaces and punctuation marks. The exclamation mark was left in the Mincho font in the Japanese example because, in this case, it is part of the Japanese text. Punctuation of this kind, could however be associated with the Latin text. See the question mark in this example.

Even more problematic are the spaces in that example. They are too wide in the Latin text. In Urdu text we have the opposite problem, use Urdu space glyphs in Latin text and you don’t see them at all (there should be a gap between W3C and i18n below).

With my W3C hat on, I start wondering whether there are any rules we can use to apply different glyphs for some characters depending on the script context in which they are used, but then I realise that this is going to bring in all the problems we already have for bidi text when dealing with punctuation or spaces between flows of text in different scripts. I’m not sure it’s a tractable problem without resorting to markup to delimit the boundaries. But then, of course, we end up right back where we started.

So it seems, disappointingly, that the unicode-range property is destined to be of only limited usefulness for me. That’s a real shame.

Another small issue

The examples don’t show major problems, but I assume that sometimes the fonts you want to bring together using font-face will have very different aspect ratios, so you may need to use something like font-size-adjust to balance the size of the fonts being used.

Browser support

The CSS code above worked for me in Chrome and Safari on Mac OS X 10.6. but didn’t work in Firefox or Opera. Nor did it work in IE9 on Windows7.

"Neque porro quisquam est qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit..."
"There is no one who loves pain itself, who seeks after it and wants to have it, simply because it is pain..."

...

There has been a flurry of activities around RDFa 1.1 in the past few months. Although a number of blogs and news items have been published on the changes, all those have become “officialized” only the past few days with the publication of the latest drafts, as well as with the publication of RDFa 1.1 Lite. It may be worth looking back at the past few months to have a clearer idea on what happened. I make references to a number of other blogs that were published in the past few months; the interested readers should consult those for details.

The latest official drafts for RDFa 1.1 were published in Spring 2011. However, lot has happened since. First of all, the RDFWA Working Group, working on this specification, has received a significant amount of comments. Some of those were rooted in implementations and the difficulties encountered therein; some came from potential authors who asked for further simplifications. Also, the announcement of schema.org had an important effect: indeed, this initiative drew attention on the importance of structured data in Web pages, which also raised further questions on the usability of RDFa for that usage pattern This came to the fore even more forcefully at the workshop organized by the stakeholders of schema.org in Mountain View. A new task force on the relationships of RDFa and microdata has been set up at W3C; beyond looking at the relationship of these two syntaxes, that task force also raised a number of issues on RDFa 1.1. These issues have been, by and large, accepted and handled by the Working Group (and reflected in the new drafts).

What does this mean for the new drafts? The bottom line: there have been some fundamental changes in RDFa 1.1. For example, profiles, introduced in earlier releases of RDFa 1.1, have been removed due to implementation challenges; however, management of vocabularies have acquired an optional feature that helps vocabulary authors to “bind” their vocabularies to other vocabularies, without introducing an extra burden on authors (see another blog for more details). Another long-standing issue was whether RDFa should include a syntax for ordered lists; this has been done now (see the same blog for further details).

A more recent important change concerns the usage of @property and @rel. Although usage of these attributes for RDF savy authors was never a real problem (the former is for the creation of literal objects, whereas the latter is for URI references), they have proven to be a major obstacle for ‘lambda’ HTML authors. This issue came up quite forcefully at the schema.org workshop in Mountain View, too. After a long technical discussion in the group, the new version reduces the usage difference between the two significantly. Essentially, if, on the same element, @property is present together with, say, @href or @resource, and @rel or @rev is not present, a URI reference is generated as an object of the triple. I.e., when used on a, say, <link> or <a> element, @property  behaves exactly like @rel. It turns out that this usage pattern is so widespread that it covers most of the important use cases for authors. The new version of the RDFa 1.1 Primer (as well as the RDFa 1.1 Core, actually) has a number of examples that show these. There are also some other changes related to the behaviour of @typeof in relations to @property; please consult the specification for these.

The publication of RDFa 1.1 Lite was also a very important step. This defines a “sub-set” of the RDFa attributes that can serve as a guideline for HTML authors to express simple structured data in HTML without bothering about more complex features. This is the subset of RDFa that schema.org will “accept”,  as an alternative to the microdata, as a possible syntax for schema.org vocabularies. (There are some examples on how some schema.org example look like in RDFa 1.1 Lite on a different blog.) In some sense, RDFa 1.1 Lite can be considered like the equivalent of microdata, except that it leaves the door open for more complex vocabulary usage, mixture with different vocabularies, etc. (The HTML Task Force will publish soon a more detailed comparison of the different syntaxes.)

So here is, roughly, where we are today. The recent publications by the W3C RDFWA Working Group have, as I said, ”officialized” all the changes that were discussed since spring. The group decided not to publish a Last Call Working Draft, because the last few weeks’ of work on the HTML Task Force may reveal some new requirements; if not, the last round of publications will follow soon.

And what about implementations? Well, my “shadow” implementation of the RDFa distiller (which also includes a separate “validator” service) incorporates all the latest changes. I also added a new feature a few weeks ago, namely the possibility to serialize the output in JSON-LD (although this has become outdated a few days ago, due to some changes in JSON-LD…). I am not sure of the exact status of Gregg Kellogg’s RDF Distiller, but, knowing him, it is either already in line with the latest drafts or it is only a matter of a few days to be so. And there are surely more around that I do not know about.

This last series of publications have provided a nice closure for a busy RDFa year. I guess the only thing now is to wish everyone a Merry Christmas, a peaceful and happy Hanukkah, or other festivities you honor at this time of the year.  In any case, a very happy New Year!

Filed under: Python, Semantic Web, Work Related Tagged: HTML, HTML5, JSON, RDFa, RDFa 1.1 Lite, Resource Description Framework, schema.org

The W3C Audio Working Group have been hard at work standardizing a set of advanced-audio-features for the web browser, with significant contributions in the form of implementations from Mozilla and Google. The state of audio in the web has been lagging behind for some time, but the new Audio Processing API allows JavaScript developers to bring web applications and games into the present day.

In case you have not been following the progress of the Audio Working Group, here is a very quick glance at what developers can do with the Audio Processing API:

• Loop sounds without gaps
• Control parameters such as Bass and Treble, enhancing the clarity of audio
• Panning sounds left to right
• Positioning sounds in 3D space for games
• Easily process the raw data in an audio stream for scientific research
• Adding filters and effects to audio for music creation
• Visualize audio signals for music and streaming applications

Alistair MacDonald, the initial chair of the Audio Working Group and the Audio Incubator Group, explains the focus of the group’s work:

What we are working on here is completely overhauling the way the we handle audio in the web. We are moving closer every week to a solution that goes far beyond what Flash and Java can offer us. In standardizing an advanced JavaScript audio API in the web browser, we can offer a level playing field for all developers; a solution that is a better fit for the way users engage with today’s “application-web”, not forcing users to deal with the often frustrating experience of downloading new plug-ins to get to interactive content, or excluding them from a growing mobile device market.

It has been really interesting to watch clients’ interest in these features at our web-development company SignedOn in Boston. We work with several media and music companies, as well as a Grammy award winning music producer, yet we get interest from all kinds of organizations. Streaming radio, game development studios, you name it! Everyone we talk to is extremely excited to hear about the developments in the Audio Working Group and wants to know when they can start building things with this API and roll it out cross-browser. The potential of the Audio Processing API for education, music software development, streaming services and game development is quite staggering. It is an untapped industry, and we see W3C as the place to get the work done and deployed.

The Audio Working Group recently added Olivier Thereaux from the BBC as a co-chair of the group. Having worked at the W3C for many years, Olivier brings great experience in the standardization process to the group, which greatly compliments co-chair Alistair MacDonald’s knowledge of existing audio software APIs, and experience in music and TV production studios.

Oliver explains the uniqueness of Audio WG standardization challenges:

The BBC has long been at the forefront of Research and Development in Audio —exemplified as early as the 1920s with our radio operations and as recently by the launch of the Audio Research Partnership— and we are enthusiastic that this expertise can be brought to the Open Web Platform thanks to the W3C Audio Working Group.

The group grew out of the exploratory W3C Audio Incubator group, in which the many participants, among them my colleague Chris Lowis, developed use cases and requirements to enable great experiences from games to music. Other requirements come from our collaboration with other working groups, including the WebRTC WG, the W3C effort on real-time communication, to bring great audio capabilities to future online communication channels.

And all this is not just for audio consumption, but a platform for amateur and professional audio processing applications on the web, connected and accessible, so we have to meet the needs not only of the traditional web developer, but also audio engineers and musicians.

To solve these requirements, the group was presented with two separate proposed specifications in various stages of implementation, and as co-chairs, Alistair and I are tasked with helping build consensus around a single approach going forward, taking the best from both approaches.

It's an exciting challenge, which will require the participation from many sides: as of today, we have browser vendors including Google, Mozilla, and Opera, and content and app developers like SignedOn and Noteflight and we also invite feedback and participation from other stakeholders.

Early Adopters

Even though the Audio Processing API is relatively new, early release implementations from Mozilla and Google have caused a considerable buzz, with developers everywhere already creating demos, games, music applications and all kinds of interactive web applications using these new features.

If you are using an up-to-date version of Chrome or Firefox, you can try some of these out for yourself.

Firefox Demos

If you have not had a chance to see this video by Dave Humprey at Mozilla, this is a great opportunity to get a good idea about some of the things that are possible with an Audio Processing API.

You can test the interactive slides from this demo are here for you to test in Firefox.

Additional Firefox demos and API tutorials are also available.

Chrome Demos

Here are selection of amazing demos and games using the new audio features in Chrome.

Here is a tutorial on how to get started with Audio Processing in Chrome.

Some basic examples of what users can do with an Audio Processing API.

Specifications and Feedback

If you are interested in the development of audio APIs on the web, we want to hear from you. Please try out the demos, and create content yourself; if you know of other demos, or have made a cool demo yourself, please let us know, and we will post links to them from the Audio WG page.

But most importantly, please review the specifications and give use concrete feedback. This is the stage where you can have a real influence on how these technologies are developed and deployed in browser and authoring tools. There is an introductory document, the Audio Processing API, which serves as a landing page for the technical specifications, the Web Audio API and MediaStream Processing API. Let us know what you think on the Audio WG mailing list, public-audio@w3.org.

I spoke with Diana Stepner, Dan Murphy, Chris Schoenfeld, and Arun Vasudeva of the Pearson company about their use of Open Web Platform technology in publishing. Pearson owns the Financial Times Group and the Penguin Group and has an extensive library of education materials.

Ian: Thank you for speaking with me. I'm interested in how the Open Web Platform is transforming publishing.

Arun: There is a lot of interest in creating content that can be refactored for different devices automatically. One aspect of that is how "responsive design" can increase versatility and efficiency.

Ian: I recently spoke with the Filament Group about "progressive enhancement"; sounds like people are very interested in this topic.

Arun: We are also looking to move content from Flash to HTML5. The latest Flash platform is now being presented as an environment suited to gaming and high performance applications. Additionally, HTML content is versatile in that it can be either accessed directly through the web browser or packaged into an app format on all the major mobile platforms.

Chris: A major issue we see in publishing in HTML5 is that there is not yet an easy migration for users of (Adobe) InDesign. It's a big jump for users. What's missing for them is the right HTML5 authoring tool. There is still some confusion in the marketplace and I think it will be a while until we get there.

Ian: Can you summarize the key motivators for Pearson to move to HTML5?

Chris: One reason is publish once, reach all devices.

Diana: The Open Web Platform lets us play in an open field. As the world's leading learning company, we don't want to be tied to just one vendor. We are still working on device-specific apps (in particular iOS today but Android increasingly), but investing in the Open Web Platform is safer than putting all our eggs in one basket.

Chris: As a publisher, we want to maintain and grow customer relationships. App stores have drained some of that business.

Ian: What are the main business decisions are driving your technology choices?

Dan: One activity to reach new markets is our "plug and play" platform, which we launched in August. We provide developers with APIs to give them access to curated content. It's free bellow a certain threshold with a tiered fee structure for higher usage. The market is still in the early stages for this sort of thing. Similarly, Google maps now charges for access to maps above a certain threshold.

Ian: How has the platform worked so far?

Dan: It is still pretty early, but we are slowly increasing the content we provide. It's a very interesting market and reminds me of the "open data" movement when it started: we want to let people innovate using our content. For instance, DK Eyewitness Guides offer travelers respected information. Someone developing a transportation ticketing service, for example, could make use of that information and provide a richer experience to customers.

Ian: Are you making the data available using semantic web technology?

Dan: For the moment only through APIs. But if we see a demand for a more semantic approach for the APIs we'd be open to it.

Ian: Any semantic web use internally?

Dan: There are some groups using internally, for example a taxonomy project.

Ian: So how do you represent the metadata in the Plug-and-Play platform?

Dan: The APIs let you search and query and get back metadata, but it's not linked data. But through this work we have recognized the value of linked data, of being able to link our information with other people's data. I'm interested in this and think that's a good path to go down in 2012.

Ian: Beyond the authoring tool issue, how is it going with app development using HTML5 and other technologies, for instance in terms of interoperability?

Chris: This is familiar territory for me. I'm used to working with platforms and frameworks, and am seeing the same needs arise with HTML5. The list of frameworks you need to know about is always evolving. Recently, though, it has settled down a bit to jQuery and PhoneGap. I've been surprised at how well the cross-platform has worked, including in Internet Explorer. But in terms of development, it's still a very manual process.

Ian: What are the keys to compatibility?

Chris: JQuery and PhoneGap. PhoneGap has a service where you upload your HTML5 app and they compile it into local binaries. This is way easier than before - we used to have people working full-time to create binaries for different platforms. PhoneGap has lowered costs and saved us time.

Ian: Any issues with Web App performance?

Chris: Performance is an issue, but bigger than that are behavior and control. Developers want fine control of threading and priorities. I think this is most common issue that comes up in HTML5 apps. In iOS you can have someone click something, update the UI, and make a network call in the background. You can't do that yet in HTML5. Or it's hard. In JavaScript you can be more specific. There are also issues of user perception of performance (e.g., activity indicators in the UI).

Ian: What about access to device capabilities?

Dan: You get more with native apps. And you know what you are getting. When you are writing HTML5 you know less about what you are coding to.

Ian: Would you say that overall HTML5 is the path to pursue?

Chris: I am more optimistic about HTML5 all the time. Last year people were asking whether they should do HTML5. But more and more the signal keeps getting stronger, such as the Financial Times and Facebook moving in that direction. Sony Ericsson released a WebGL phone, which is huge. There's a lot of momentum right now.

Diana: HTML5 is not the solution for everything. Developers need to think about features, consumers, and choose the right technology. We are moving more toward HTML5 but currently it is still a conscious decision.

Ian: What are your criteria for going with HTML5?

Diana: If you don't need to access specific features of a phone, or if you don't need immersive graphics. We want to do more HTML5 in the future because it will save time and be more efficient to reach multiple devices.

Chris: HTML5 is good for rapid prototyping. You test, tweak, and then "burn" your native apps. Also, it's very convenient to test some things on the server. You can deploy five different versions of a banner graphic and iterate on the server side before shipping any native code.

Ian: What else would you like to see W3C work on?

Chris: Here's what would have a lot of value: there's room for a standard layer above the HTML5 that would give you a framework for different well-known applications scenarios that would make development easier. When we think about a mobile app, we don't want to have to turn to vendors to fill the gaps. I want to be able to use a tag that tells the browser a context I'm working in, for instance "a window with a menu bar" or "render that in the native OS widgets." As a designer I want to focus on functionality and let the browser interpret my description of a high-level task, rendering appropriately according to platform standards. There are SDKs that take care of this sort of thing, but I'd like things to be pushed up into standards that people can use without going to a third-party.

Ian: Thank you for the conversation!

The Open Web Platform weekly summary is about love for the open Web, about the work we do together, about the hours we spent every day to create a better Web. I can work in this domain, because others gave an open environment for working. Let’s keep it open.

HTML5

The specification has been modified to allow two syntaxes for the time element. You may write time with a T or a single space separator between the date and the time.

<time>2011-12-24T23:59</time>
<time>2011-12-24 23:59</time>

XML documents have a UTF-8 default encoding. Kornel Lesiński asked if it would be possible to do that for documents with an HTML5 doctype. Henri Sivonen (Mozilla), who is also developing the HTML5 parser for Firefox, rejected the suggestion. It would introduce more incompatibilities and more specific behaviors than the already existing explicit mechanisms.

HTML Rich Content

Sometimes Web developers need to extend their content with a richer semantics by adding simple data structure to their markup. A first Working Draft for RDFa Lite 1.1 has been published. For example to specify that this column is written by a human and not a cow.

<p vocab="http://schema.org/" 
   resource="#karl" 
   typeof="Person">
   This blog post is written by 
   <span property="name">Karl Dubost</span>.</p>

The purpose of this group is to develop a common specification in OWL for structured and unstructured annotations on Web documents, based on prior work developed by the Annotation Ontology (http://code.google.com/p/annotation-ontology/) and Open Annotation Collaboration (http://www.openannotation.org/) efforts.

You are invited to support the creation of this group: http://www.w3.org/community/groups/proposed#annotation

Video Tracks

The WebVTT format (Web Video Text Tracks) is a format intended for marking up external text track resources. WebVTT has escaped HTML5 to be developed by the Web Media Text Tracks Community Group. They also have a twitter account. Anne van Kesteren has created a WebVTT Validator and published the source code on bitbucket. The syntax is a very simple text file.

WEBVTT

00:11.000 --> 00:13.000
<v Roger Bingham>We are in New York City

00:13.000 --> 00:16.000
<v Roger Bingham>We're actually at the Lucern Hotel, just down the street

Web Apps

If humanity had an UndoManager API we might have been able to fix a lot of mistakes. Ryosuke Niwa (webkit) is working on such an API for the Web and he is asking feedback. A long list of use cases has been outlined to better understand what do we need to solve.

Dominique Hazaël-Massieux (W3C) has been giving a summary of the Standards for Web Applications on Mobile. He has published an update for November 2011.

DOM

The new methods for append, prepend, … that we mentioned a few weeks ago have been addred to the DOM 4 specification in the mutation methods section. This triggered a new syntax requirement for WebIDL, which has not yet been completely defined. Anne van Kesteren (Opera) has also started to define Mutation observers.

CSS

An update has been published for CSS Image Values and Replaced Content and a new editor draft for CSS3 Grid Layout. As a kind reminder, these are drafts and then not stable. If the implementations change them or drop these features, you will have to eat your own hat :)

Web Architecture

A tendency in Web development has emerged a little while ago. Web developers started to push hash sign in their URIs not to define an anchor in the document but the state of an application. The W3C Technical Architecture Group has summarized best practices for handling hash signs URIs.

The W3C TAG is working on a few topics in parallel. You could participate constructively to the discussions by subscribing to the www-tag mailing list.

HTTP

You can now buffer this number, RFC 6455, in your memory lane. The WebSocket Protocol is accepted. Though be careful, because there might still be a bit of breakage depending if your browser has released a version of the implementation but disabled by default. Check your preferences.

In the discussion about extending HTTP status code, Roy Fielding (Adobe) gave an interesting rule for knowing how/when to extend the list of codes.

When extending HTTP status codes, the question that needs to be asked is “how will a client process this response differently than any of the existing status codes?”

Elsewhere

• Move The Web Forward is the new kid in town. It gives a long list of resources to help Web developers stay informed about what’s going on the Open Web platform.
• Redbot, the HTTP validation tool developed by Mark Nottingham, now supports HTTP over SSL and TLS

This column is written by Karl Dubost, working in the Developer Relations team at Opera Software.

The Web and TV Interest Group has just published his first group note document: "Requirements for Home Networking Scenarios".

This document is a collective work of the members of the Home Network TF of the IG and lists the design goals and requirements that potential W3C recommendations should support in order to enable access to services and content provided by home network devices, including the discovery and playback of content available to those devices, both from services such as traditional broadcast media and internet based services but also from the other services running on another home network device.
This input document as been submitted to the Device APIs and Policies Working Group (as previously mentioned on this blog) and to the new Web Intents group.

About the Web&TV IG

Launched in February 2011, the Web and TV Interest Group is a forum for Web and TV technical discussions, aimed to review existing services and technologies as well as new scenarios and identify gaps in the web platform that would prevent these services to be deployed in an effective and interoperable way across devices.

Gaps analysis is the first, yet important, step in creating new standards. The IG Task Forces are in charge of reviewing use cases from the TV community and bringing the identified (potential) gaps as input to one or more W3C Working Groups. TF members follow-up the discussion in the WGs and make sure that the identified use cases are accepted and addressed by WGs (or brought back to the IG for refinement, if needed).

The Web&TV IG is a pretty young group but it grew quite a lot in the last months, reaching 123 participants from 44 organizations. At the moment there is another TF actively discussing the impact of requirements posed by media formats commonly used by TV services on the HTML5 media interfaces.

The IG chairs are planning to start few new activities. More news soon on this blog and on the IG home page