W3C

Web Design and Applications

Web Design and Applications involve the standards for building and Rendering Web pages, including HTML, CSS, SVG, device APIs, and other technologies for Web Applications (“WebApps”). This section also includes information on how to make pages accessible to people with disabilities (WCAG), to internationalize them, and make them work on mobile devices.

HTML & CSS Header link

HTML and CSS are the fundamental technologies for building Web pages: HTML (html and xhtml) for structure, CSS for style and layout, including WebFonts. Find resources for good Web page design as well as helpful tools.

JavaScript Web APIs Header link

Standard APIs for client-side Web Application development include those for Geolocation, XMLHttpRequest, and mobile widgets. W3C standards for document models (the “DOM”) and technologies such as XBL allow content providers to create interactive documents through scripting.

Graphics Header link

W3C is the home of the widely deployed PNG raster format, SVG vector format, and the Canvas API. WebCGM is a more specialized format used, for example, in the fields of automotive engineering, aeronautics.

Audio and Video Header link

Some of the W3C formats that enable authoring audio and video presentations include HTML, SVG, and SMIL (for synchronization). W3C is also working on a timed text format for captioning and other applications.

Accessibility Header link

W3C’s Web Accessibility Initiative (WAI) has published Web Content Accessibility Guidelines (WCAG) to help authors create content that is accessible to people with disabilities. WAI-ARIA gives authors more tools to create accessible Web Applications by providing additional semantics about widgets and behaviors.

Internationalization Header link

W3C has a mission to design technology that works across cultures and languages. W3C standards such as HTML and XML are built on Unicode, for instance. In addition, W3C has published guidance for authors related to language tags bi-directional (bidi) text, and more.

Mobile Web Header link

W3C promotes “One Web” that is available on any device. W3C’s Mobile Web Best Practices help authors understand how to create content that provides a reasonable experience on a wide variety of devices, contexts, and locations.

Privacy Header link

The Web is a powerful tool for communications and transactions of all sorts. It is important to consider privacy and security implications of the Web as part of technology design. Learn more about tracking and Web App security.

Math on the Web Header link

Mathematics and formula are used on the Web for business reports, education materials and scientific research. W3C’s MathML enables mathematics to be served, received, and processed on the World Wide Web, just as HTML has enabled this functionality for other types of content.

News Atom

Updates to Requirements for Chinese Text Layoutinclude the following.

  • Zhuyin figures updated
  • Various graphic examples of annotations added
  • New section containing examples of Zhuying annotations
  • Aijie Zhang added to list of editors
  • Various code fixes and typos corrected

We are in the process of adding Simplified Chinese translations of all the text, but the work is still in progress. All markup created during this process so far has been hidden in this document using CSS. It will be unhidden in a future Working Draft, once the work is completed.

A detailed list of changes, including diffs, can be found in the github commit log.

A report summarizing the MultilingualWeb workshop in Riga is now available from the MultilingualWeb site. It contains a summary of each session with links to presentation slides and minutes taken during the workshop in Riga. The workshop was a huge success. With the parallel Connecting Europe Facility (CEF) event, it had more than 200 registered participants. See a summary of highlights , and a dedicated report about outreach activities of the supporting EU funded LIDER project . The Workshop was locally organized by Tilde , sponsored by the LIDER project and by Verisign . Learn more about the Internationalization Activity.

The Web Platform keeps moving forward every day. Back in October last year, following the release of HTML 5.0 as a Recommendation, I wrote about Streaming video on the Web as a good example of more work to do. But that’s only one among many: persistent background processing , frame rate performance data , metadata associated with a web application , or mitigating cross-site attacks are among many additions we’re working on to push the envelop. The Open Web Platform is far from complete and we’ve been focusing on strengthening the parts of the Open Web Platform that developers most urgently need for success, through our push for Application Foundations . Our focus on developers led us to the recent launch of the W3C’s Web Platform Incubator Community Group(WICG). It gives the easiest way possible for developers to propose new platform features and incubate their ideas.

As part of the very rapid pace of innovation in the Web Platform, HTML itself will continue to evolve as well. The work on Web Components is looking to provide Web developers the means to build their own fully-featured HTML elements, to eliminate the need for scaffolding in most Web frameworks or libraries. The Digital Publishing folks are looking to produce structural semantic extensions to accommodate their industry, through the governance model for modularization and extensions of WAI-ARIA.

In the meantime, the work boundaries between the Web Applications Working Group and the HTML Working Group have narrowed over the years, given that it is difficult nowadays to introduce new HTML elements and attributes without looking at their implications at the API level. While there is a desire to reorganize the work in terms of functionalities rather then technical solution, resulting in several Working Groups, we’re proposing the Web Platform Working Group as an interim group while discussion is ongoing regarding the proper modularization of HTMLand its APIs. It enables the ongoing specifications to continue to move forward over the next 12 months. The second proposed group will the Timed Media Working Group. The Web is increasingly used to share and consume timed media, especially video and audio, and we need to enhance these experiences by providing a good Web foundation to those uses, by supporting the work of the Audioand Web Real-Time CommunicationsWorking Groups.

The challenge in making those innovations and additions is to continue to have an interoperable and royalty-free Web for everyone. Let’s continue to make the Open Web Platform the best platform for documents and applications.

The Internationalization Working Group has published a First Public Working Draft of Requirements for Chinese Text Layout ( 中文排版需求 ), on behalf of the Chinese Layout Task Force , part of the Internationalization Interest Group.

The document describes requirements for Chinese script layout and text support on the Web and in digital publications. These requirements inform developers of Web technologies such as CSS, HTML, and SVG, and inform browser and tool implementers, about how to support the needs of users in Chinese-speaking communities.

This is still a very early draft and the group is looking for comments and contributions to support the ongoing development of the document.

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.

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

We are super excited to announce the launch of the W3C’s Web Platform Incubator Community Group(WICG). Despite the funny name (“the Why-See-Gee, really?”), this is a great new initiative that seeks to make it easier for developers to propose new platform features for standardization.

What we want to achieve

The purpose of the WICG:

  • Make it as easy as possible for developers to propose new platform features, in the spirit of the Extensible Web Manifesto.
  • Provide a space where developers and implementers can discuss new platform features.
  • Incubate those ideas by providing guidance and a supportive and inclusive environment to those who have never contributed to standards (and even to those that have!:D); Ultimately transitioning those ideas to a W3C Working Group for formal standardization (i.e., making a “W3C Recommendation”).
  • Modernize how we do standardization of platform features (yay! no mailing lists… unless you really want one).
  • Provide a legal frameworkthat keeps all contributions free and open.

In short, we want to be a support group for aspiring standardistas. We want to provide you with all the help you would need in order to take your idea or proposal to the next level.

What we are not

We are not planning on being the new powers-that-be. You don’t have to convince us that your idea is any good; and even if you do, that might not help you much. What we would give you though is feedback on your ideas formulation, and help you iterate on them to improve the chances of them getting some traction once presented to the appropriate group.

Are browser makers involved?

Yes! Absolutely. Microsoft, Apple, Google, and Mozilla are fully supporting this effort.

Inspired by what the RICG achieved, the browser vendors want to make it easier to have a dialog about new features in a space that provides the required legal framework with minimal red-tape. However, we require people to join the community groupto participate.

Having early buy-in from browser vendors is critical for getting something supported across browsers. Because all the browser vendors are involved in this effort, ideas can be quickly vetted from both a developer and browser vendor’s viewpoint.

By working together, we can create features that are fit for their purpose and, hopefully, a pleasure to use—all while solving real-world problems!

How we hope to make things easier…

In short: GitHub+ tooling + a supportive community.

The elves at the W3C have been busy making sure we have the toolsin place to make participation as simple as possible. We will develop specs/use case documents like we develop any open source software.

What’s the process?

Roughly, we want to follow the process already established by the RICG, though we will adapt as we go. It will go something like:

  1. State the problem: Write a description of a limitation with the Web platform and either post it to Discourse, spin up a GitHub repo, or just publish it somewhere (e.g., blog post, gist, whatever you like). This should be something you believe is missing in the platform and would make the lives of developers significantly easier if it were added. It can also be something you’ve noticed is a recurring development pattern which would benefit from standardization.
  2. Join the group: Before bringing the above to the group’s attention, join the community group , which means you agree with the terms of the W3C’s Community Contributor License Agreement (CLA). It’s critical if you first join the groupor else key members won’t be able to review or discuss your proposal. Don’t worry if you forget, the Chairs will remind you and hound you till you do :)
  3. Evaluation: As a community, we will evaluate if the problem can’t be solved already using Web tech. We will also look at how many users of the Web might be affected. This will require collecting data, real world usage examples, etc.
  4. Use cases: If need be, we will formalize the above into a use cases document. Such a document can help prove to the community that there is indeed a need for a solution that needs standardization (see the Use Cases and Requirements for Standardizing Responsive Images, for example).
  5. Advocate: We circulate this with browser vendors and the community at large—we pitch it to anyone who will listen. Getting everyone on-board and in our corner is critical.
  6. Specify it: Once we have buy-in from browser vendors and the community, we put together some rough proposals (e.g., a new HTML element, API, or HTTP header…) and we do an “ intent to migrate“: where we move the spec to a W3C Working group to seek royalty free licensing commitments from W3C members (you know, the “free” in “free and open”).
  7. (Bonus points) Implementation: Help turn the ideas from words on paper into working features in modern browsers.

(If you are interested in the formal process, take a look at the Web Platform Incubator Community Group Charter)

Support

We won’t sugar coat it: standardization is hard (just ask anyone who survived the RICG:)).

The bar to add new things to the Web is going to remain high: We might need to raise money. Or bring everyone together in a room, like we once did in Paris. Or pitch ideas at conferences to get more developer interest and get momentum behind a feature.

However, anyone who chooses to participate will be well supported. We have some extremely experienced browser/standards engineers participating who are here to help. If you don’t know where to start, or don’t know your RFC2119 from your WebIDL, don’t worry. We got your back!

Collaboration with the RICG

So what’s the relationship between this group and the RICG? Since we share members and acronym parts with it, we thought it’s worth explaining.

The RICGis focused primarily on pushing essential responsive features into standards and browsers, as well as getting more developers involved in the standards process. The WICG will focus mostly on that second bit: incubation of new platform features. We will help you take your idea of something that is missing in the platform and help you grow it until it is ready to be sent off to the appropriate group. This might even include pushing something into the RICG.

The RICGwill continue to handle all things “responsive”, tackling the specific issues that have matured from a gleam in someone’s eye into ready-for-prime-time proposals.

What about other Community Groups?

Other Community Groupscontinue to function as normal. However, the WICG provides a one-stop-shop for features specifically targeted at web browsers. Sometimes, new CGs might be spun off from this one to work on a particular feature.

Got Questions?

You can find the chairs on Twitter:

Events Header link

  • 2015-08-23 (23 AUG) 2015-08-24 (24 AUG)

    Editing APIs Task Force (WebApps and HTMLWG members)

    Paris, France

    Mozilla

    Registration is mandatory and the deadline to register is August 14

  • 2015-09-09 ( 9 SEP) 2015-09-10 (10 SEP)

    WebRTC Working Group Meeting

    Redmond, WA

    Microsoft

  • 2015-09-23 (23 SEP) 2015-09-26 (26 SEP)

    The Graphical Web

    Pittsburgh, Pennsylvania, USA

    The conference invites technical presentations about the implementations and usage of open web graphic technologies, such as SVG, Canvas, WebGL, CSS and HTML5 audio/video.

See full list of W3C Events.