W3C

Web of Devices

W3C is focusing on technologies to enable Web access anywhere, anytime, using any device. This includes Web access from mobile phones and other mobile devices as well as use of Web technology in consumer electronics, printers, interactive television, and even automobiles.

Mobile Web Header link

W3C promotes “One Web” that is available on any device. W3C’s Mobile Web Initiative helps ensure the best user experience on mobile devices, taking into account device capabilities, location, and other context information.

Voice Browsing Header link

The W3C Speech Interface Framework is a suite of specifications (e.g. VoiceXML) integrating Web technology and speech interaction. VoiceXML, PLS, SISR, SRGS, SCXML, and CCXML all contribute to the Speech Interface Framework.

Device Independence and Content Adaptation Header link

Devices come in many shapes, capabilities and sizes which define constraints on the content these devices can handle. Device descriptions, content transformation guidelines, device APIs and CC/PP help developers to optimize the user experience.

Multimodal Access Header link

Increasingly, interactions with devices doesn’t only happen with a keyboard, but also through voice, touch and gestures. The W3C Multimodal architecture and its components (EMMA, InkML) allow developers to adapt applications to new interaction modes.

Web and TV Header link

With the advent of IP-based devices, connected TVs are progressing at a fast pace and traditional TV broadcasting is quickly evolving into a more immersive experience where users can interact with rich applications that are at least partly based on Web technologies. There is strong growth in the deployment of devices that integrate regular Web technologies such as HTML, CSS, and SVG, coupled with various device APIs.

News Atom

Changes in this publication of Requirements for Hangul Text Layout and Typography ( 한국어 텍스트 레이아웃 및 타이포그래피를 위한 요구사항) are editorial in nature, but significant. The separate English and Korean versions of the document were merged into one page. (You can use buttons at the top right of the page to view the document in one language or the other, if you prefer.)

Merging the languages helps significantly for development and maintenance of the document, for guiding users to a language version they prefer, and for bilingual readers offers additional opportunities.

In addition, the links to issues in the document were changed to point to the github issues list, rather than the former Tracker list.

There were no substantive changes to the English (authoritative) version, but the Korean version was brought into line with earlier changes to the English text.

Character Model for the World Wide Web: String Matching and Searchingbuilds upon Character Model for the World Wide Web 1.0: Fundamentals to provide authors of specifications, software developers, and content developers a common reference on string identity matching on the World Wide Web and thereby increase interoperability.

This new version introduces numerous editorial changes as well as replacing some temporary terminology with better terms, and integrating the case folding text from the string matching algorithm into the case folding section. The document template was also adapated to match the new Internationalization publication process. See details of changes.

Additional Requirements for Bidi in HTML & CSSwas used to work through and communicate recommendations made to the HTML and CSS Working Groups for some of the most repetitive pain points prior to HTML5 and CSS3 for people working with bidirectional text in scripts such as Arabic, Hebrew, Thaana, etc.

It is being published now as a Working Group Note for the historical record in order to capture some of the thinking that lay behind the evolution of the specifications and to help people in the future working on bidi issues to understand the history of the decisions taken. Notes have been added to give a brief summary of what was actually implemented in the HTML or CSS specifications.

The Internet Society (ISOC) just released its second annual Global Internet Report, with a focus this year on the mobile Internet. The report explores mobile Internet availability, affordability, and relevance to potential users, and highlights opportunities as well as challenges to ensure all users can enjoy the full benefits of mobile access to the open Internet.

The HTML5Apps team contributed significantly to the report in two key sections of this report which are related to:

  • the challenges presented by the current app ecosystem
  • the recommendations to address these challenges based on the work W3C is undertaking

These contributions were depending on the work conducted earlier by the project on the native/Web gap analysis and on the API gap review.


Filed under: html5apps , Mobile , Standardization

As part of  the HTML5Apps project work, the team is trying to gain a more detailed understanding of the barriers that developers from European SMEsencounter, and what the subsequent reasons make them avoid or prevent them from developing mobile apps using Web technologies.

In addition to participating at developer events and interacting via social media, we are also conducting a few one-to-one interviews with developers with the goal to dive in more details in some of these barriers.

The first of these interviews was conducted in June 2015, with Fabrice Castellon and Alain Prette, the co-founders and leaders of Beepeers, an SME based in the South of France, specialized in the development and publishing of social applications.

Hello guys, can you tell us more about your company and its business at a high level?
Beepeers was founded 3 years ago in Sophia-Antipolis in France. We provide a platform for building and publishing white-label social network applications, typically used inside enterprises, or for specific events. We aim at enabling widespread use of mobile technologies for a social usage, thanks to a brand-new line of social apps, available on-demand.
Our customers include radio and media companies, some local administrations and event organizers. We have focused on a product-based approach: our customers trust us to build a response to their specific needs, rather than seeking an all-encompassing (but likely ill-fitting) solution.
What platforms does your development target? How much relies on native technologies vs Web-based ones?
Our two main targets for mobile devices are the iPhone and Android-based phones; we can also support Windows phones and have deployed applications targeted at the iPad devices. Early in the life of our company, we experimented with using HTML5 technologies to deliver our services on mobile as we were receptive to the idea it could help us reduce our development costs. But in the end, we made the decision to only focus on native.
Could you elaborate on the reasons that made you move away from the Web technology stack?
There were multiple reasons behind that decision:
  • Some of our customers had a negative experience with the UX quality of HTML5-based development on mobile, and were thus not very open to that solution;
  • We also ourselves came to the conclusion that native had a better return on investment when it came to building the most fitting user experience on a given device; building the equivalent with HTML5 required a lot of efforts, with non-trivial maintenance costs;
  • While there is a cost in maintaining our code base across these different platforms, the expertise we have in building these specific solutions is an added value of the service we provide to our customers; each platform comes with its own UX language (navigation patterns, sharing actions), and being able to stick to that language has proven not only useful in building good UX, but is also proving a good source of inspiration for further evolutions;
  • Presence on application stores remains a critical part of the marketing and communication needs for our customers; that is where many of their users will end up looking for the app they seek to provide;
  • Although our apps don’t have ads per se, they need to show sponsorship inserts, and we found that it is much easier to integrate those in the native UX flow;
  • Some of our features require a reliable offline system (e.g. downloaded tickets for an event), which is a much more simple story in native;
  • Likewise, the ability to use push notifications is a critical piece to get users engaged, especially for event apps, where they let us build momentum ahead of the actual event;
  • In most cases, the users of our apps sign in via a separate existing social network (e.g. Facebook, Twitter, LinkedIn) — it saves them the need to create and manage a new account. The workflow to integrate smoothly with these 3rd-parties is much better done with native technologies.
Is there any role for Web technologies in your product?
Yes. There are still some pieces where we are using Web technologies as fitting some of our requirements, even though most of the pieces exposed to end user by our apps are built using native technologies. For example:
  • For integration with third-party services (e.g. ticketing): HTML5 gives the right interoperability we need to display interactive content from other parties; but we keep the interactions to a very limited subset (e.g. no navigation);
  • The CMS that our customers use to publish their content to their users is Web-based, and is used to aggregate and broadcast content from other Web sources (e.g. other social networks, RSS feeds); but the content so gathered is transformed before being displayed in our apps, it’s not served as-is;
  • In some of our apps, we integrate a Web view that lets users see linked content while remaining in the app.
So, in summary, you don’t see the Web playing any additional role on mobile for your company?
Actually, we have started very recently re-investing in a Web-based mobile solution for some of our customers. First, today, you cannot afford to provide a Web service that is not also mobile friendly, and in most cases we have already been providing a Web equivalent to our mobile apps. Since getting Web content mobile friendly is costly no matter what, it makes sense to get this mobile-friendly Web site to bring an alternative experience to our native apps.Second, and more importantly, we have started to invest in pure client-side applications (based on the Angular.js framework), and we are seeing very good results out it with some or our customers. In particular, it has enabled our more advanced customers to have more control on the service they provide to the users, since they can easily customize the templates through which their content is displayed. Compared to a traditional server-based approach, we have found the client-based approach to represent a much more reduced investment, and this is making us look again at our return-on-investment analysis. It is not our priority development, but we do see it as a promising direction to explore.Native apps also come with their own costs: getting an app reviewed and accepted create delays and risks, and while managing it participates to the service we provide to our customers, having a Web presence allows for a quicker turn around. But overall, in our opinion, it is not a matter of native winning over native or vice versa: it is a matter of providing the right UX to our customers users.
What are the main features you would like to see coming to the Web to improve your Web-based product?
Push notifications is the number one feature we’re interested in! It is great to see them coming to the browser, and we plan on investigating that possibility. Likewise, support for offline operations via ServiceWorker is promising. Being able to store tickets off-line, and to synchronize data with our servers in the background would help a lot!For ticketing, one specificity is that what we need some level of guarantees that the stored content cannot be tampered with, even by the users themselves.In our native apps, we have used interactions with iBeacon to facilitate integration with local marketing, and that is not available on the Web today.As alluded previously, being able to integrate smoothly with social connectors is also very important for us. Overall, having a very responsive user interface, with immediate reactivity is critical to building the kind of UX our customers want.For any new feature, of course, we will need to evaluate their impact on the user experience; for instance, find out if “permissions requests” are not too intrusive.
Thanks, great input! A number of these features are already under development in W3C, and we’ll look into what it takes to get the others started as well!


Filed under: Developer , HTML5 , html5apps , Mobile

I was present at the Edge conferenceon 27 June in London, UK, representing the HTML5Apps project. That conference, organized by FT Labs for the past 5 years, targets discussion and debate of leading-edge use of client-side Web technologies. It aims at being very participative in its nature, and was organized this year around a set of panels in the morning and breakouts in the afternoon.

About 180 developers attended the conference, including renowned developers, technical evangelists and standards advocates.

The context of the conference (“leading edge”) and its attendees made it indeed a great place for conversations and interactions. Specifically, I had good discussions related to:

  • Interest and adoption around some of the arrival in mobile browsers, esp. push notifications, installable Web app (via manifest) and offline via ServiceWorker. In particular, these technologies seem to open up to great “conversion rates” of installing Web apps via a manifest compared to the native installation workflow enabled by traditional banners — the notion that installing a Web app is a much smoother and less intrusive action seems to have teeth.
  • Publishers think that the Web remains a critical part of the traffic they get on mobile, and that the notion of progressive appscoined by Alex Russell matches well with the experience these publishers are facing with native.

On the organized sessions of the conference themselves, I attended/participated to:

  • The panel on security, with good conversations on the needs and issues of adopting a higher base-level security (with HTTPs and CSP);
  • The panel on front-end data, which illustrated some of the tensions between providing the right low-level primitives (in this case indexedDB) and providing an easy-to-use API;
  • The “installable web apps” breakout, which was a really good discussion on the model enabled by App Manifest, as well as some of the questions that remain open about it: Chrome chose to make “installing” something offered to the user under some conditions (serviceworker, repeated usage, responsiveness), where Opera is investigating surfacing that option more visibly in the UI; can these appmanifests help surface mobile Web apps in native stores (where users have been trained to look for content and services)? “Installing” a Web app is really “adding it to homescreen”, but that means they remain a 2nd class citizen in a number of ways (integration in app lists, integration in app settings, etc). This was my preferred session of the day;
  • A breakout on network operators where the Natasha Rooney from GSMA was looking for input and feedback on how developers see operators could be useful to their goals, with a lot of discussion similar to the topics in the Web & Mobile Interest Group networking task force.

Overall, this developer conference was a success and the project’s team is looking forward to the next edition!


Filed under: Developer , Event , HTML5

In the last 1 1/2 years, the LIDER project has organized several roadmapping events to gather a broad community around the topic of linguistic linked data. In July this year, LIDER will engage with two selected communities. On July 6, the 5th LIDER roadmapping workshop will be held in Rome at Sapienza University of Rome . The topic will be cross-media linked data and the event will provide several high level speakers from the multimedia area. On July 13th LIDER will organize the 6th roadmappping workshopin Munich. The event will be hosted by Siemens and will focus on content analytics and linked data in healthcare and medicine.

For both workshops participation is limited. If you are interested in the Rome event please contact Tiziano Flati , for Munich please contact Philipp Cimiano.

Version 8.0 of the Unicode Standard is now available. It includes 41 new emoji characters (including five modifiers for diversity), 5,771 new ideographs for Chinese, Japanese, and Korean, the new Georgian lari currency symbol, and 86 lowercase Cherokee syllables. It also adds letters to existing scripts to support Arwi (the Tamil language written in the Arabic script), the Ik language in Uganda, Kulango in the Côte d’Ivoire, and other languages of Africa. In total, this version adds 7,716 new characters and six new scripts. For full details on Version 8.0, see Unicode 8.0.

The first version of Unicode Technical Report #51, Unicode Emoji is being released at the same time. That document describes the new emoji characters . It provides design guidelines and data for improving emoji interoperability across platforms, gives background information about emoji symbols, and describes how they are selected for inclusion in the Unicode Standard. The data is used to support emoji characters in implementations, specifying which symbols are commonly displayed as emoji, how the new skin-tone modifiers work, and how composite emoji can be formed with joiners. The Unicode website now supplies charts of emoji characters, showing vendor variations and providing other useful information.

Some of the changes in Version 8.0 and associated Unicode technical standards may require modifications in implementations. For more information, see Unicode 8.0 Migrationand the migration sections of UTS #10, UTS #39, and UTS #46.

W3C is aiming to streamline Web Payments with new standards that will provide a uniform way for merchants to integrate payments into the Web with a level playing field for payment service providers and value added services. The HTML5Apps project initiated this work in 2014 by organizing the Web Payments Workshopat the “Bourse de Paris” to discuss requirements related to usability, security, mobile payments, digital wallets, ubiquitous payments, the Internet of Things, and more.

The Web Payment Interest Group , formed as a outcome of that workshop, is meeting this week in New York, in the heart of the financial community, for a  three day meeting (June 16-18) which aims to prepare the ground for launching a W3C Working Group on Web Payments standards later this year. The HTML5Apps project is helping stakeholders to clarify the scope and technical direction for chartering the new group.

On June 18, W3C will hold a  Future of Web Payments Industry Roundtable, hosted by Bloomberg. Participants at the Roundtable includes  representatives from W3C’s Web Payments IG, including Apple, Bloomberg, Deutsche Telekom, Gemalto, Google, Mozilla, NACS, Rabobank, Ripple Labs, Target, US Federal Reserve Bank, Walmart, Yandex, and others.


Filed under: HTML5 , html5apps , Payment , Standardization

In the context of the  Big Data Value Association Madrid Summit , 17-19th June, there are two sessions of specific relevance to standards and also to multilingualism: on 18th June a  session on standardization , and on 19th June a session on  Multilingual Data Value Chains . If you want to have an active participation in both sessions or want to provide further feedback, please contact Felix Sasaki < fsasaki@w3.org > on Standardization and Asun Gomez-Perez < asun@fi.upm.es> on Multilingual Data Value Chains. Presentation will be short in order to promote a wide participation.

If you cannot be in Madrid please also provide your input – see above session links for further instructions. The BDVA Summit will be crucial in shaping upcoming funding opportunities related to Big Data. Don’t miss the chance to describe your views on opportunities, challenges and potential solutions for the Big Data Value Chain!