The future of style

The Future of Style aggregates posts from various blogs that talk about the development of Cascading Style Sheets (CSS) [not development with Cascading Style Sheets]. While it is hosted by the W3C CSS Working Group, the content of the individual entries represent only the opinion of their respective authors and does not reflect the position of the CSS Working Group or the W3C.

Latest articles

Minutes Telecon 2018-03-21

Source: CSS WG Blog Dael Jackson • 22 March 2018

Full Minutes

What’s new in Chromium 65 and Opera 52

Source: Dev.OperaDaniel Bratell • 22 March 2018

Opera 52 (based on Chromium 65) for Mac, Windows, Linux is out! To find out what’s new for users, see our Desktop blog post. Here’s what it means for web developers.

Paint Worklet, Paintlet, Paint API

With paintlets it is possible to write a script that does the background rendering of an element. This can be more flexible than generating images on the server side or using client side generated data urls for backgrounds.

The image below is a rather silly example of what can be done with paintlets.

This effect was accomplished by adding a paint module to the paint worklet, and then, in its paint() method, drawing on the supplied ctx as if it had been a canvas. It is also possible to supply configuration from CSS to the script, something that can make paintlets easier to use than other ways to generate background images.

<!-- demo.html -->
  textarea {
  background-image: paint(circlearcpainter);
  --circle-arc-pixel-size: 24;
<!-- Textarea is a good demo since it can be resized. -->

The module itself is defined with the javascript below.

// circle_arc.js
class CircleArcPainter {
    circle_arc(ctx, x, y, radius, angle) {
        let angleInRad = (angle * 0.9 / 2 + 10) * Math.PI / 180;
        ctx.fillStyle = 'yellow';
        ctx.arc(x, y, radius,
                angleInRad, Math.PI * 2 - angleInRad, false);
        ctx.lineTo(x, y);
    static get inputProperties() { return ['--circle-arc-pixel-size']; }
    paint(ctx, geom, properties) {
        const css_prop = properties.get("--circle-arc-pixel-size");
        const size = css_prop ? parseInt(css_prop.toString()) : 100;
        ctx.fillStyle = "black";
        ctx.fillRect(0, 0, geom.width, geom.height);
        for (let x = 0; x < geom.width/size; x++) {
            for (let y = 0; y < geom.height/size; y++) {
                const circle_size = Math.abs(
                    Math.sin((x + y) / 6)) * size / 4 + size / 12;
                const opening = Math.random() * 90;
                this.circle_arc(ctx, (x + 0.5) * size, (y + 0.5) * size,
                                circle_size, opening);

// Register our class under a specific name
registerPaint('circlearcpainter', CircleArcPainter);

Server Timing API

With the new Server Timing API there is a well defined way for servers to pass performance information to the browser through HTTP headers. With this information web pages can make even better informed decisions.

In Developer Tools this information is displayed in the Network view by selecting the resource and activating the Timing tab.



Feature Policy


Performance APIs


What’s next?

If you’re interested in experimenting with features that are in the pipeline for future versions of Opera, we recommend following our Opera Developer stream.

Release Notes for Safari Technology Preview 52

Source: Surfin' Safari 21 March 2018

Safari Technology Preview Release 52 is now available for download for macOS Sierra and macOS High Sierra. If you already have Safari Technology Preview installed, you can update from the Mac App Store’s Updates tab. This release covers WebKit revisions 228856-229535.

Legacy NPAPI Plug-ins

Service Worker






Web Driver

Web Inspector



Bug Fix

CSS Text Decoration Level 4: First Public Working Draft

Source: CSS WG Blog fantasai • 16 March 2018

The CSS Working Group has published an updated Working Draft of CSS Text Decoration Level 4. The Text Decoration module contains the features of CSS relating to text decoration, such as underlines, text shadows, and emphasis marks. Level 4 adds controls for the offset and thickness of underlines, spread radius for text-shadow, and control over skipping punctuation and/or spaces.

This is an early-stage working draft, and significant changes are expected going forward, particularly to the skipping controls.

Please send feedback by either filing an issue in GitHub (preferable) or sending mail to the (archived) public mailing list with the spec code ([css-text-decor-4]) and your comment topic in the subject line. (Alternatively, you can email one of the editors and ask them to forward your comment.)

The CSS Days 2018 in Amsterdam are this year on 14 & 15 …

Source: W3C's Cascading Style Sheets home page15 March 2018

14 Jun 2018 The CSS Days 2018 in Amsterdam are this year on 14 & 15 June (with workshops on the 13th). The first day's theme is user interaction. Speakers include Eric Meyer and Greg Whitworth.

Minutes Telecon 2018-03-14

Source: CSS WG Blog Dael Jackson • 15 March 2018

Full Minutes

New Proposed Recommendation: CSS Color Level 3. Updated Cand…

Source: W3C's Cascading Style Sheets home page15 March 2018

15 Mar 2018 New Proposed Recommendation: CSS Color Level 3. Updated Candidate Recommendation: CSS Fonts Level 3.

New Working Draft: CSS Text Decoration Level 4.

Source: W3C's Cascading Style Sheets home page13 March 2018

13 Mar 2018 New Working Draft: CSS Text Decoration Level 4.

Minutes Telecon 2018-03-07

Source: CSS WG Blog Dael Jackson • 08 March 2018

Full Minutes

Last Call for Comments on CSS Sizing Level 3

Source: CSS WG Blogfantasai • 04 March 2018

The CSS Working Group has published an updated Working Draft of CSS Intrinsic and Extrinsic Sizing Level 3. This module extends the CSS sizing properties with keywords that represent content-based “intrinsic” sizes and context-based “extrinsic” sizes, allowing CSS to more easily describe boxes that fit their content or fit into a particular layout context.

Significant changes since last year are listed in the changes section and include:

Open issues include:

We expect to transition to CR soon, so this draft effectively marks the beginning of a last call for comments period; we will be accepting comments at least through the end of March, and depending on the state of the draft, aim to transition to CR sometime in April. (We will of course process comments during CR as well, but would prefer to get them sooner rather than later.)

(Note that the min-content and max-content keywords have already been officially cleared for shipping by the CSSWG in 2015 since their syntax was stable and their behavior was tied to behavior exposed in existing CSS2.1 features.)

Please send feedback by either filing an issue in GitHub (preferable) or sending mail to the (archived) public mailing list with the spec code ([css-sizing-3]) and your comment topic in the subject line. (Alternatively, you can email one of the editors and ask them to forward your comment.)

Updated Working Draft: CSS Intrinsic & Extrinsic Sizing …

Source: W3C's Cascading Style Sheets home page04 March 2018

4 Mar 2018 Updated Working Draft: CSS Intrinsic & Extrinsic Sizing Level 3.

WOFF 2.0, the inside scoop

Source: W3C BlogChris Lilley • 01 March 2018

Today, WOFF 2.0 is a W3C Recommendation. Perhaps you have some questions: what is it, why should I care, can I use it already?


WebFonts – fonts which are automatically downloaded and used on demand to render a web page, without having to be installed – have risen in importance in recent years. In 2010, a survey of the top 10,000 websites found that only 1% used WebFonts anywhere on the site. That survey is being repeated twice a month, and today, eight years later, 70% use WebFonts.

Work on the original WOFF 1.0 was started in 2010, at which time WebFonts were barely used. WOFF is a container for TrueType and OpenType fonts; the original font data plus a header and optional metadata (such as the name of the designer, a link to a license) are compressed using the same gzip compression used by PNG images. WOFF 1.0 took a minimum viable product approach, using a compression library that was already in the browser. WOFF 1.0 became a W3C Recommendation in December 2012, at which point WebFont usage had risen to 14%.

By the start of 2014, WebFont usage had risen to 35% of websites. With such a volume of data, improving the compression was seen to have significant benefit. A two-stage compression was investigated: firstly a font-specific data reduction, then an improved general compression algorithm.

WOFF 2.0 Font-specific Preprocessing

TrueType and OpenType are designed more for ease of access than for minimal filesize. Data is often padded to an integral number of bytes, making it faster to access. Sometimes the same or similar information is stored at multiple places in the file, for historical reasons. Some data, such as pointers to glyph outlines, is convenient for access but could easily be recalculated. WOFF 2.0 therefore starts by removing redundant or recalculable data, and packing it into the minimum number of bits. This is based on the MicroType Express technology from Monotype.

To take one example,  the bounding box of a single glyph is defined by four numbers (Xmin, Xmax, Ymin, Ymax). The left side bearing is also stored, and is always identical to Xmin. WOFF 2.0 therefore throws away the left side bearing when the font is compressed, and copies over the value from Xmin when the font is reconstructed.

Not all experiments were successful. For example, the placement of knots in a glyph path follows a set of rules, which can (for example, at local curve minima or maxima) allow a point to be predicted based on nearby points and the overall position on the curve. A novel preprocessing stage was considered which removed predictable points before entropy compression, and restored them in the reconstruction step. Experiments showed that a modest reduction in filesize could be obtained, but that the prediction capabilities of the entropy coder were already accounting for these points and thus, the size of the compressed result was not significantly reduced.

WOFF 2.0 compression (entropy coding)

Several options were examined for the second compression stage. One option, LZMA, gave good results but the decoding time was high, which would have been a problem on lower powered devices such as mobile. For this and other reasons, LZMA was abandoned in favor of a novel compression scheme, Brotli. This was first created, and then further developed over the next couple of years, by a Zürich-based expert compression team at Google, and gives excellent compression results; the decompression speed and the memory need to decompress are also very close to what WOFF 1.0 requires.

During development, WOFF2 was tested on three large datasets: the entire Google fonts corpus (1.1k TTF fonts), the Monotype corpus (33k TTF fonts), and the Adobe Fonts corpus, comprising 13.9k TTF fonts and  5k CFF (Type 1)  fonts. This allowed us to not only measure the average compression, but also to examine the best and worst cases. It is worth noting that the WOFF 2.0 size was smaller than the WOFF 1.0 size, for every font tested. Overall, for Truetype fonts (TTF outlines) WOFF 2.0 is 27% better than WOFF 1.0, and for fonts with Type 1 glyphs it is 13.5% better.

In fact, the general-purpose Brotli compressor is so good that it was also adopted into HTTP, providing benefits to the Web for HTML, CSS and Javascript files as well.

WOFF 2.0 and the future

During the development of WOFF 2.0, new font capabilities arose. Multicolored OpenType fonts, and OpenType Variable Fonts are the two main examples. Both are handled by WOFF 2.0 without change, because it is designed to be forwards compatible.

Using WOFF 2.0

WOFF 2.0 is already supported by recent versions of all the major browsers, and has been for the last couple of years. Fallback to WOFF 1.0 for older browsers is easy, a few lines of CSS and no server-side configuration is required:

/* load WOFF 2.0 font if possible, otherwise use WOFF 1.0 font */
@font-face {
  font-family: ExampleName;
  src: url(example.woff2) format("woff2"),
       url(example.woff) format("woff");

Further reading

Minutes Telecon 2018-02-21

Source: CSS WG Blog Dael Jackson • 22 February 2018

Full Minutes

Accessibility: Review of 2017 and Outlook for 2018

Source: W3C Blog Shadi Abou-Zahra • 14 February 2018

video on web accessibility standards and benefits

2017 was another busy year for the W3C Web Accessibility Initiative (WAI). This includes developments in the technical and educational areas of WAI, as well as in international standards coordination and harmonization. Much of the results are expected to become more visible and tangible this year, in 2018.

WCAG 2.1

The Accessibility Guidelines Working Group has been working on an extremely tight schedule to make improvements to the internationally recognized Web Content Accessibility Guidelines (WCAG). Among other things, WCAG 2.1 addresses more accessibility requirements for people with cognitive and learning disabilities, people with low vision, and for mobile accessibility. On 30 January 2018 WCAG 2.1 entered Candidate Recommendation (CR). It is scheduled for completion as a W3C Recommendation by June 2018. The working group welcomes implementations of WCAG 2.1 CR during this phase. If you are interested, get in touch with


On 14 December 2017 the Accessible Rich Internet Applications Working Group published Accessible Rich Internet Applications (WAI-ARIA) 1.1 as a completed W3C Recommendation. WAI-ARIA defines roles and properties to make web applications and rich web content more accessible. The group continues to work, or spawn work in other groups, on accessibility API mappings for several technologies including WAI-ARIA, HTML, Graphics and SVG, Digital Publishing, and CSS. Also the WAI-ARIA Authoring Practices 1.1 was published as a Working Group Note, to provide implementation guidance.

Conformance Testing

The Accessibility Conformance Testing Task Force of the Accessibility Guidelines Working Group has been refining the Accessibility Conformance Testing (ACT) Rules Format 1.0, and applying it to ACT Rules initially developed by the Auto-WCAG Community Group. ACT provides transparently documented ways for testing web content, to improve reliability and common interpretation. The ACT Rules Format is scheduled to complete its Candidate Recommendation (CR) stage in 2018, to allow open contribution of ACT Rules by different entities.

Education and Outreach

The Education and Outreach Working Group has been focusing on updating and revising resources in coordination with a complete redesign of the WAI website. This includes revising the content of Introduction to Web Accessibility and Easy Checks – A First Review of Web Accessibility, and the content and functionality of Web Accessibility Laws and Policies. W3C also published a 4-minute introductory video based on the existing Web Accessibility Perspectives videos.

Horizontal Review

The Accessible Platform Architectures Working Group has continued to look at every formally published W3C specification for accessibility, and to comment where relevant. It has active efforts to support accessibility strategy for CSS and Payments, and brings longer-term questions to the Research Questions Task Force which is exploring authentication, personalization, CAPTCHA, virtual reality, automotive, and internet of things.

Standards Harmonization

W3C Staff have been involved in activities to support international coordination and harmonization of web accessibility standards. In Europe, EC Mandate 554 defines updating of the standard EN 301 549 with continued alignment with W3C specifications, such as WCAG 2.1. In China the national standard for web accessibility is being revised, with opportunities for increased alignment.

Outlook for 2018

Besides many other activities, some of the main highlights in W3C accessibility for 2018 include:

Get Involved — we look forward to your contributions and active participation in these and other priorities, to help make the Web more accessible.

Release Notes for Safari Technology Preview 49

Source: Surfin' Safari 07 February 2018

Safari Technology Preview Release 49 is now available for download for macOS Sierra and macOS High Sierra. If you already have Safari Technology Preview installed, you can update from the Mac App Store’s Updates tab. This release covers WebKit revisions 227071-227873.

Service Workers


Intelligent Tracking Prevention





Web Inspector





Bug Fixes

What’s new in Chromium 64 and Opera 51

Source: Dev.OperaFredrik Söderqvist • 07 February 2018

Opera 51 (based on Chromium 64) for Mac, Windows, Linux is out! To find out what’s new for users, see our Desktop blog post. Here’s what it means for web developers.

Mitigations for the “Spectre” vulnerability

In order to mitigate the recently disclosed security vulnerability called “Spectre”, the following restrictions that affect the functionality of the web platform have been applied:

Both of the above serve to reduce the possibility of performing a side-channel attack to read sensitive user data, by removing potential ways to acquire a high-precision timing source.

Resize Observer

Responsive web applications are often written using CSS media queries or window.onresize to build components that adapt to different viewport sizes. Both of these are global signals, thus requiring the overall viewport to change in order for the site to respond accordingly. With the Resize Observer API, web applications can observe changes to sizes of elements on a page with finer granularity.

The following code snippet uses the Resize Observer API to observe size changes to an element:

  const ro = new ResizeObserver((entries) => {
    for (const entry of entries) {
      const cr = entry.contentRect;
      console.log('Element: ',;
      console.log(`Element size: ${cr.width}px × ${cr.height}px`);
      console.log(`Element padding: ${}px / ${cr.left}px`);

  // Observe one or multiple elements


Developers writing JavaScript modules often want access to host-specific metadata about the current module. To make this easier, support for the import.meta property has been added. This property currently exposes the module URL as import.meta.url. Authors of libraries may want to access the URL of the module being bundled into the library to more easily resolve resources relative to the module file as opposed to the current HTML document.

Other features in this release

Deprecations and interoperability improvements

What’s next?

If you’re interested in experimenting with features that are in the pipeline for future versions of Opera, we recommend following our Opera Developer stream.

New Working Draft: CSS Grid Layout Level 2.

Source: W3C's Cascading Style Sheets home page06 February 2018

6 Feb 2018 New Working Draft: CSS Grid Layout Level 2.

Fast-forwarding media support on the Web

Source: W3C Blog François Daoust • 05 February 2018

A brief history of media on the Web

screenshot of the Roadmap of Media Technologies for the Web Media on the Web has gone through three main stages until now. Before the release of HTML5, audio and video were essentially not on the Web, and only available through plug-ins. Plug-ins were widely available on desktop browsers, but smartphones were around the corner, and the Web slowly transitioned to a plug-in free platform.

Then HTML5, first published as a W3C Recommendation in 2014, came along. HTML5 brought media to the Web through the <audio> and <video> tags. Plugins were no longer needed, in theory at least. In practice though, the media industry was willing to stream content on the Web, which was not immediately possible with HTML5 in an interoperable way. HTTP-based adaptive streaming solutions, such as Dynamic Adaptive Streaming over HTTP (MPEG DASH) or HTTP live Streaming (HLS), were developed to improve the user experience when streaming content on the Web, but most HTML5 browsers did not support these mechanisms out of the box. All in all, even though HTML5 brought support for media content, the Web platform remained impractical for professional media usage.

Media Source Extensions (MSE) and Encrypted Media Extensions (EME), published as W3C Recommendations in 2016 and 2017, added the missing blocks to address video on demand (VoD) requirements on the Web, making it possible to implement adaptive streaming mechanisms and to control playback of encrypted content across browsers.

Media on the Web in 2018

A number of use cases, which were arguably of lower priority as long as the above core technologies had not been developed and implemented across browsers, are now moving to the forefront of standardization discussions around media.

Sticking to building blocks, given the heterogeneity of media content supported across platforms, one core technology that is still missing today is the ability for Web applications to tell the media capabilities of the underlying platform (decoding, encoding, and output capabilities for a given format) with enough details to make an optimal decision when picking media content for the user. A solution is being incubated in the Web Platform Incubator Community Group (WICG) with the Media Capabilities specification. That specification should make further progress in 2018.

TV displays, projectors and regular computer displays now support High Dynamic Range (HDR) and Wide Color Gamut content. How can these wider color spaces be supported on the Web platform? How to map luminance levels when mixing HDR and non-HDR content? The Color on the Web Community Group is exploring these questions. The CSS Working Group already started to address extensions to CSS to support other color spaces (CSS Colors Level 4 and CSS Media Queries Level 4).

All embedded media devices (TV sets, set-top boxes, HDMI dongles, smartphones, etc.) have now embraced Web technologies one way or the other, although with varying levels of support for key technologies. making it difficult for content providers to develop media Web applications that run smoothly across media devices. To reduce this fragmentation, the Web Media API Community Group maintains a baseline of Web APIs that are well supported across main Web browsers and that embedded devices should support as well. This effort, done in collaboration with the CTA Wave Project, led to publication of the Web Media API Snapshot 2017 in December 2017. This group may transition to a W3C Working Group this year to produce yearly snapshots of the Web platform for media applications.

Talking about media devices and displays, second screen scenarios are a space to watch in 2018. Users typically own and switch between multiple devices nowadays — for instance, they may discover media content on their smartphones but will want to play back that content on their large TV sets. The Second Screen Community Group incubates an Open Screen Protocol on top of which the Presentation API and the Remote Playback API could be implemented, with a view to providing full interoperability across devices in the longer term.

Last but not least, streaming live linear content on the Web remains a challenge. The first version of MSE and EME addressed Video on Demand needs, but provided only superficial support for live linear content scenarios. New requirements for these specs, such as the need to give Web applications some control over the internal buffering to prioritize low latency over continuity of media playback, are being discussed. They may trigger renewed work on these specifications down the line.

Tracking progress

The Roadmap of Media Technologies for the Web highlights the topics mentioned above, other identified gaps, as well as on-going developments, not mentioned here for brevity — for example, the thorough work on captioning with Timed Text Markup Language (TTML) and the Web Video Text Tracks Format (WebVTT), or extensions needed to support 360° videos, discussed in the Immersive Web Community Group.

The Media & Entertainment Interest Group tracks progress of on-going activities at W3C and elsewhere, and assign priorities of possible standardization efforts at W3C. The group holds monthly calls, focused on a different technology each time. It serves as steering committee for the standardization of media-related features at W3C. Interested parties are welcome to join and help improve media support on the Web!

Updated WD of Selectors Level 4

Source: CSS WG Blogfantasai • 02 February 2018

The CSS Working Group has published an updated Working Draft of CSS Selectors Level 4. Selectors is a pattern-matching syntax for identifying sets of elements in a document, and is used e.g. for applying CSS declarations to elements in a document tree.

This publication brings the official draft up-to-date with all of the WG resolutions since 2013. Significant changes are summarized in the Changes section.

This specification is now in the Refining stage: we don’t expect any large changes prior to Candidate Recommendation, but will be continuing to address issues. Most features are well-scoped, with significant open issues described in the draft to solicit directed feedback. Other than addressing open issues, a significant focus of the next round of edits will be to update and improve cross-references between Selectors and other Web standards (in coordination with the editors of the DOM and HTML standards at WHATWG).

Please send feedback by either filing an issue in GitHub (preferable) or sending mail to the (archived) public mailing list with the spec code ([selectors-4]) and your comment topic in the subject line. (Alternatively, you can email one of the editors and ask them to forward your comment.)

Updated Working Draft: Selectors Level 4.

Source: W3C's Cascading Style Sheets home page02 February 2018

2 Feb 2018 Updated Working Draft: Selectors Level 4.

Updated Candidate Recommendation: Selectors Level 3.

Source: W3C's Cascading Style Sheets home page30 January 2018

30 Jan 2018 Updated Candidate Recommendation: Selectors Level 3.

Release Notes for Safari Technology Preview 48

Source: Surfin' Safari 24 January 2018

Safari Technology Preview Release 48 is now available for download for macOS Sierra and macOS High Sierra. If you already have Safari Technology Preview installed, you can update from the Mac App Store’s Updates tab. This release covers WebKit revisions 226358-227071.

Password AutoFill

Storage Access API


Service Workers




Web Inspector

Web Driver





Bug Fixes

Minutes Telecon 2018-01-17

Source: CSS WG Blog Dael Jackson • 18 January 2018

Full Minutes

Minutes Telecon 2018-01-10

Source: CSS WG Blog Dael Jackson • 18 January 2018

Full Minutes

Release Notes for Safari Technology Preview 47

Source: Surfin' Safari Jon Davis • 11 January 2018

Safari Technology Preview Release 47 is now available for download for macOS Sierra and macOS High Sierra. If you already have Safari Technology Preview installed, you can update from the Mac App Store’s Updates tab. This release covers WebKit revisions 225841-226358.

This release contains the Spectre mitigations released in iOS 11.2.2, the High Sierra 10.13.2 supplemental update, and Safari 11.0.2 reissue released on Monday, January 8. For more information about Spectre, see What Spectre and Meltdown Mean For WebKit.

Storage Access API

This is a newly proposed API (WhatWG issue) that can be enabled in the Develop menu under Experimental Features. Cookies partitioned by Safari’s Intelligent Tracking Prevention can be accessed in an iframe loaded from the cookie’s domain by calling document.requestStorageAccess() in a click event handler. When the returned promise resolves, the first-party cookies in that iframe will be accessible. There is also the convenience function document.hasStorageAccess() available that doesn’t require a click.

Service Workers



Web Inspector

Clipboard API

Bug Fix

Storage Access API: Refactor XPC for access removal to go straight from the web process to the network process (r226389)

What does the publishing industry bring to the Web?

Source: W3C Blog Ivan Herman • 08 January 2018

(Disclaimer: many of the thoughts and opinions in this blog are of my own, and not necessarily shared by the W3C as a whole. Putting it another way: I wrote this blog with my W3C team’s hat down…)

Document Web or Web Operating System?

Let’s look at the definition of the Web on, say, Wikipedia. Here is what we find:

The World Wide Web […] is an information space where documents and other Web resources are identified by Uniform Resource Locators (URLs) interlinked by hypertext links, and can be accesses via the Internet

Note the word “documents” (emphasis is mine).

In its first, say, 10-15 years the Web was seen as some sort of a giant library of (interlinked) information. Web pages were, mostly, documents with an essentially textual content although, possibly, illustrated with images and videos. In contrast, the force that drives the Web today are mostly Web Applications. The Web has turned into some sort of a universal Web Operating System which makes the differences among Windows, Linux, Android, IOS, or MacOS mostly disappear, and which is used to run sophisticated programs from email clients to online computer games, from virtual reality applications to teleconferencing utilities. That is the main thrust of today’s developments these days.

Is this a problem? Not really, one is tempted to say, because all those applications are undeniably useful (or fun…), and having a universal Web Operating System is a good thing. It simplifies the life of many. The features used by Web Applications, i.e., the underlying rich API-s, provide useful interaction, transformation, or animation possibilities that more traditional Web pages can also exploit. And that is also a good thing.

So do we have a problem? Well… maybe yes. Not due to the fact that Web Applications (and the underlying infrastructure) exists but because, in my view, the pendulum has swung to an extreme. In spite of the amazing facilities offered by CSS, of the advances of internationalization on the Web, or of new font technologies, one nevertheless has the impression that the Web has forgotten its “roots”, that the only important goal is to make Web Applications as fast and responsive as possible, and everything else is deemed irrelevant or at least not important. We’ve got to a situation when browsers optimize their operations so that 3D animation and Virtual Reality work with hitherto unimaginable speed, but most browsers are not enabled to display the oldest and most universal language of scientific discourse, namely mathematics. It has become easy to display pull-down menus with carefully calibrated, colorful (but, often, futile) transitions but displaying poetry on a Web page remains a challenge. Systems are optimized at short messages surrounded by dancing pictures and emojis but handling really long text in a readable manner, using ergonomically proven techniques like temporary bookmarks (in the original, etymological sense of the word) on a simple paragraph, or paginating the content, is still experimental and in the realm of (a few) extensions as opposed to be part of the core. The Web has contributed in making us forget about the value of long, carefully written and curated content in favor of short texts of 128 characters…

In short, we have lost the concept of a “Web of Documents”. Personally I believe this is a problem.

Haven’t (traditional) publishers developed solutions already?

Unfortunately, not really. To see some of the problems they are facing we have to realize that the term “publishers” means lots of different communities, even if we concentrate on the question of how they interact with the Web.

Journals, magazines…

Take journal and magazine publishers. This includes publishers of scholarly journals and conference proceedings as well as industrial reports and publicity materials. As of today, this community mostly produces PDF as the output of their workflow with, in some cases, a presence on the Web that serve just as a landing page to get to those PDF files. They do it because they have, usually, very high demand on the typesetting and general output of their materials (either for aesthetic reasons or due to the traditions of a particular community) and their “digital” publication is merely a digital copy of their paper publication. Magazines, for example, have barely moved away from that approach. I do not really consider that as part of the Web, it is just providing digital access to, essentially, printed or printable material.

This approach begins to break down, though. First of all, one of the peculiar aspects of, e.g., scholarly publishing is that publishers “publish”, say, conference proceedings consisting of a series of PDF files formatted as if they were printed documents even though the printed version is not produced any more. Which is odd, if one thinks about it. And the usage of such files is becoming a major issue for the consumers of our digital age: PDF may be problematic for accessibility or for consuming it on a mobile device. Anybody who has tried to provide a peer review of a scholarly paper on a tablet or a phone knows how unnerving that can be.

Some of these publishers recognize that the future is to move fully to the Web, but then they hit numerous issues that need solutions. In many cases a publication in those communities must have a unique and immutable identity so that others can refer to it. (People’s career in, for example, the scholarly world may depend on a clear identification of their publication!) But a publication usually consists of many different resources: not only the core textual content, but all the accompanying images, photographs, data files together, and the identity should refer to all these resources and not only to one of those. It is the collection that counts, not a single HTML page.

Also, journal publishers, depending on the discipline, must include mathematics, biochemical diagrams, or extracts of sheet music. They may have to abide to various typesetting rules that have evolved over centuries and that scholars are not ready to give up. Publications must include a number of metadata elements. And, last but not least, scholars may want to have an access to the full publication even if they are offline; after all, what is a better place to read a paper than on a plane or on a train while commuting?


Traditional “trade” publishers, e.g., those that publish “simply” books (novels, textbooks, recipes, or travel books) have gone down the EPUB way. Though different in origin, the problems they have hit is fairly similar to what, say, journal or academic publishers have come to face. (It must be noted that EPUB is not for books only although, so far, the book publishing industry is its biggest user. EPUB is perfectly usable for other types of publications.)

The most obvious issues is that an EPUB publication is off the Web. Just like the aforementioned PDF files, they may be downloaded from the Web, but they rely on special “reading devices”, as the jargon goes. This in spite of the fact that, at its core, EPUB relies on Web technologies. Forgetting the packaging aspect for a moment, EPUB is, essentially, a Web site. A Web site that, beyond the core content in HTML, CSS, or SVG, contains a number of information that makes the Web site a publication. It specifies that it is, actually a collection of resources (just like a modern, HTML-based scholarly publication is such a collection), it contains metadata, it contains information about a table of content, it has a strong notion of identity for the collection, etc. Note that EPUB, as a Web site, also uses technologies that are barely used elsewhere on the Web like SMIL (albeit a relatively small profile thereof). EPUB has features to turn the content into an audio book, and the accessibility requirements imposed by EPUB are more stringent than on the Web in general. Finally, EPUB is packaged (into a derivative of ZIP): the reason is partly a business/distribution issue, but partly because, just like a scholarly publication, an EPUB publication must be available offline or for archival purposes in, e.g., national libraries.

Is (the current version of) EPUB a solution for a Web of Documents (if one forgets about the packaging again)? Not as it stands today. The definition of EPUB, that was done independently, was always dependent on what was developed elsewhere (mostly at W3C), and was therefore often behind the most up-to-date technologies. It still uses XML syntax’s for some of its “configuration” (today we would say “manifest”) data, which has become, over the years, a heresy for many in the Web community. It relies on XHTML. It is impossible to “just” unpack an EPUB file onto a Web site and expects the result to be “just” enjoyable. (There are of course extensions or applications on top of Web browsers, but they are highly non-trivial and complex, ahem, Web Applications acting on the packaged EPUB publications, much like pdf.js is used in many browsers to handle PDF files.)

A way forward: work together!

The recent evolution at W3C may have a profound and welcome effect on the development of a Document Web. Mid last year W3C and IDPF (the organization that specified EPUB) decided to join their forces to form what is now called “Publishing@W3C”. This was followed by the creation of several new groups at W3C, including the Publishing Working Group, that began their work right before summer. Without going into too much details, one can say that the goal of the Working Group (as well as of Publishing@W3C in general) is to make significant steps towards a more comprehensive Web of Documents.

What are the direction this Working Group has taken? A precursor of the Working Group, the (now closed) Digital Publishing Interest Group, has coined the term “Web Publication” for, well, publications on the Web. It described a vision where publications are wholly part of the Web. This term has been taken up by the Working Group in its charter; the term refers to a collection of Web resources that has a unique identity (i.e., a URL) for the whole collection as opposed to any individual constituents. It should have some sort of a manifest, providing information that are necessary for publications (table of content, metadata, references to the constituent resources, etc.). It should be available offline or online; it should be packageable, if necessary (the term “Packaged Web Publication” is used to differentiate that state) to encompass relevant business models or requirements for long term archival. User actions, like search or annotations, preference settings for font size or color background should be based on the collection (i.e., the full publication) rather than necessarily restricted to a specific constituent resource. (After all, users want to search for a term in the whole book, and not exclusively in the current chapter only…) But probably the most important aspect of the planned work is that all these feature should be through additions to Web technologies, and not (I repeat: not) some sort of a “fork” of the current Web.

The Working Group will need to look at ways to reintroduce features on audio-video-text synchronization using technologies other than SMIL, because that latter has been ignored by the current Web developments; it should rely, as much as possible, on technologies that already exist are under development elsewhere. It has to reuse, wherever possible and worthwhile, technologies developed elsewhere; for example, whilst the current work on Web Application Manifests is aimed (of course…) at Web Applications, a similar and, hopefully, compatible approach may be used for publications, too. It should embrace the latest evolution of Web Technologies, like Service Workers, to make offline access to a publication a simple issue. Or, as packaging remains necessary for business or archival reasons, reuse any work on Web packaging, should the Web community move in this direction.

Simple, traditional Web pages should also be considered as Web Publications either out of the box or with very little extra work. That means that reasonable defaults should be provided so that systems (browsers, dedicated applications, etc.) could automatically offer extra facilities to Web pages that were, so far, not available (e.g., pagination of long texts). It should be possible to extend the capabilities of Web browsers with new formats like mathematics or chemical markup; obviously, we cannot expect browser manufacturers to solve everything by themselves. A simple path should be available for existing publications (journal articles, EPUBs, etc.) to become Web Publications, to make the transition for publishers easy and smooth.

Note that Web Publications, because they are essentially Web sites, need the possibilities offered by that “Web Operating System”, too. Not necessarily for the publication of a simple novel but, for example, for educational materials that may include interactive tests, direct connection and interaction with sophisticated server-side facilities, inclusion of all possible types of media. (Consider an educational textbook that is on the borderline of a book and an application providing online tests, quizzes, etc.) Also, at least at first, handling Web Publications will probably need some polyfill or other forms of extensions to be handled within the browser. The big advantage is that, via such extensions, reading a novel or an article will rely on the same user interface, the same look-and-feel as any Web site, as opposed to how a PDF or an EPUB document is consumed today. That shows that the choice should not be a Web of Applications or a Web of Documents; the future should be a Web of Applications and a Web of Documents. The pendulum should get to an equilibrium in the middle.

The first results

The Publishing Working Group has now reached a significant milestone: it has published the First Public Working Draft for Web Publications. As is often the case for such first drafts, the document does not provide detailed technical solutions for all issues like the essential information items for Web Publications, manifests, security issues, locations and identifiers, or reading enhancements. There may be an outline for a solution for some of those, and merely number of specific technical questions and open issues for others. But it gives a direction to where the WG thinks we should go. Also, many of the problems faced by publishers are actually not addressed by this Working Group, because they represent issues that other Working Groups are chartered for (e.g., CSS), and the job of the Publishing Working Group will be to work hand in hand with those groups.


The main value, for me, of publishers joining (at last!) the efforts to develop the Web further is to help us find the right balance that I believe we have lost. We must continue developing a Web Operating System for all the good reasons. But we also must spend our efforts to rejuvenate a Web of Documents, i.e., a universal library of human knowledge and culture, where publishing political essays and poetry, scholarly articles, or novels can occur as a direct continuation of one of the oldest human endeavors that is present in all cultures and traditions: publishing. Such a Web of Documents should embrace all the possibilities offered by Web of Applications, but this should happen without giving up the facilities, the aesthetics, or the ergonomic features of traditional publishing. Just as it may be a pleasure to open a beautifully typeset and illustrated art book, it should be the same pleasure opening up a similar page on the Web, without loosing the additional possibilities that the Web has given us and that may also revolutionize publishing.

Web Publications should put the paradigm of a document on the Web back in the spotlight. Not in opposition to Web Applications but to complement them. (Web) Publications should become first class entities on the Web. This should lead to a right balance between a Web of Applications and a Web of Documents as two, complementary faces of the World Wide Web.

Minutes Telecon 2018-01-03

Source: CSS WG Blog Dael Jackson • 06 January 2018

Full Minutes

Web Directions Events in 2018

Source: Web Directions BlogJohn • 04 January 2018

We started out with a single event, Web Directions, back in 2006. Over the intervening 12 years, we’ve branched out to different countries at times (and who knows maybe will again!) and added more focussed singe track events like Code in 2012 to our major event (now Web Directions Summit).

We’ve experimented with taking events to multiple cities in a short time frame (the lesson we learned was this was really exhausting for all concerned), created “popup” events (some of which go on to becoming annual events, others remain one off), and continued to look to evolve our events, and their content as our industry continues to evolve.

We’ve now finalised our 2018 program, a mixture of our trusted, long running conferences, including Code and Summit, with some new events as well. Read on for more on each event, or if you can’t wait and want to see what’s planned, head right on over to our events page.

the year at a glance

At a glance, there are three ‘tent post’ events. Design in Melbourne in April, Code in Melbourne in August and Summit in Sydney in November.

Along side each these are related events–Design Leaders, Code Leaders, AI and Culture.

Respond becomes Design

The biggest change is the retirement of our Respond conference. But don’t be too despondent, as it is really transforming into something even more relevant and valuable. Respond began life as a one day “popup” event in 2014, with a Web design focus–partly on technology, above all CSS, and partly on the design challenges of an increasingly multi-screen world. Over the following years, it became increasingly a broadly design focussed event, though its name continued to suggest topics closer to its original focus.

Now after a lot of thought and many conversations with attendees of our events and folks we know in the industry, we’ve come to conclude that increasingly the division between the content at Code and that at Respond, particularly the technical content, is artificial. Not that many years ago, developers who worked with JavaScript were a subset of front end developers. This separation is increasingly rare.

And so from 2018, all of the technical, front-end content, from CSS to HTML to JavaScript, will live at Code (and in the engineering track at our end of year Summit). If you work on the front end with any of these technologies these events are for you.

But where does that leave Respond?

Well, right from the beginning, and increasingly over its lifespan, Respond had a strong design focus. Last year over two thirds of the content was what you might broadly describe as design.

So just as Code started life by us taking the developer focussed aspects of our end of year Sydney event and creating a new dedicated developer event, Respond will become Design, a single track event focussing on the challenges of designing great digital products and services.

From user research to Interaction Design, Product Design to CX, we’ve created Design as the place for design professionals to gather, learn and connect. We’re already lining up an incredible set of speakers (we can’t wait to start announcing them in early February). So mark April 12 and 13 in Melbourne in your diaries.

And, Design Leaders

In a similar vein to our Code Leaders event, we’re also running Design Leaders in Melbourne the day before Design. As design moves from nice-to-have to being increasingly appreciated as having key strategic value for companies and organisations, design teams are growing, often rapidly, and design professionals are playing increasingly important leadership roles.
Design leaders is created for experienced design professionals in, or moving into these management and leadership roles.

The sell out Code returns

Code, running since 2012 in Melbourne, returns after selling out weeks in advance in 2017. It’s of course again in Melbourne, August 2 and 3, at its long running home, the Arts Centre. If you work on the front end, then this is the event for you. We suggest starting to plan now, as last year a lot of people were disappointed to miss out.

Alongside Code we’re running Code Leaders once again. This one day event we started last year is tailored to more senior engineering professionals, and the particular challenges they face. Last year the content was more technical, but for this year, based on attendee’s feedback, there’ll be more of a focus on leadership, management and culture. Code Leaders takes place on August 1st.

Web Directions Summit

After experimenting with a single track format in 2016, we returned to the long established, much loved two track format with Web Directions Summit in Sydney in November. And that’s how it will stay, with a track focussed on design, and a track focussed on development and engineering, alongside keynotes from highly engaging deep thinkers.

Web Directions Summit 2018 takes place on November 8 & 9 in Sydney. It’s our keystone event, and we’re already lining up incredible speakers.


Last year we ran our first Culture event. Building on the success of and interest in Code Leaders, Culture focusses on the challenges of building great teams and organisational cultures that are diverse, inclusive and high performing. Culture returns in 2018 the day before Summit, and is created for design and engineering leaders, as well as HR and Culture professionals.


New in 2017, one of our ‘popup’ events, AI sold out and generated a lot of great responses.

In 2017 we’ll again hold AI, this year running on the day before Summit, November 7, in Sydney. Whether your focus is design, engineering or decision making, AI provides you with a better capacity to incorporate machine learning and AI technology into your current products and services, as well as new products and services you may be working on.

Register now and save

We currently have great super early bird specials for all of our 2018 events–get a Gold ticket (conference, conference videos and speaker dinner) for just $999 for any of our main conferences.

Where did Transform go?

You may notice that our Transform event, which we’ve run the last couple of years is no longer part of our lineup. Both editions of Transform have been successful, but we’ve found the challenge of such a small team running so many events simply too depleting. A lot of the content we covered in Transform, which focussed on government digital transformation, is covered at other events of ours, and we’ve long had a strong contingent of government attendees at all our events.

Here’s to a great 2018

All the best for 2018. We’re looking forward to an amazing year of conferences, and other events so start planning now, and we look forward to seeing you.

The post Web Directions Events in 2018 appeared first on Web Directions.

What’s new in Chromium 63 and Opera 50

Source: Dev.OperaJens Widell • 04 January 2018

Opera 50 (based on Chromium 63) for Mac, Windows, Linux is out! To find out what’s new for users, see our Desktop blog post. Here’s what it means for web developers.

Dynamic module imports

New JavaScript module import syntax allows developers to dynamically load code into modules and scripts at runtime. This makes it possible to load parts of an application lazily, which can be used to improve application start-up time or to avoid loading seldom used parts until they are actually needed.

javascript button.addEventListener('click', event => { import('./dialogBox.js') .then(dialogBox => {; }) .catch(error => { /* Error handling */ }); });

The code example above shows how to use the import(specifier) function to import JavaScript after an event.

Async iterators and generators

Asynchronous iteration is made more convenient with the addition of asynchronous generator functions

javascript async function* generateAsync() { while(condition) { const an_object = await produceAnObject(); yield an_object.some_property; } }

and the asynchronous iteration protocol

javascript for await (const item of generateAsync()) { console.log({ item }); }

Read more about this syntax and its possibilites on Jake Archibald’s blog or in this summary of the “Asynchronous Iteration” proposal.

Device Memory API

Using the new Device Memory API developers can estimate the total amount of RAM on the device. This information could be used to deliver a suitably scaled version of the site to lower-end devices, or help put collected performance data into context to better understand the behavior of a web application.

Other web platform features in this release

Deprecations and interoperability improvements

What’s next?

If you’re interested in experimenting with features that are in the pipeline for future versions of Opera, we recommend following our Opera Developer stream.

Remaining Spec Update Announcements 2017

Source: CSS WG Blogfantasai • 02 January 2018

The CSSWG published a number of major updates last year, not all of which were announced, so here are the missing publications, in reverse chronological order:

  1. CSS Grid Layout Level 1 — updated CR
  2. CSS Scroll Snapping Level 1 — updated CR
  3. CSS Counter Styles Level 3 — updated CR
  4. CSS Writing Modes Level 3 & Level 4 — updated CR, FPWD
  5. CSS Transitions Level 1 — updated WD
  6. CSS Animations Level 1 — updated WD
  7. CSS Transforms Level 1 — updated WD
  8. CSS Flexible Box Layout Level 1 — updated CR
  9. CSS Box Alignment Level 3 — updated WD
  10. CSS Text Level 3 — updated WD
  11. CSS Logical Properties Level 1 — FPWD
  12. CSS Fill and Stroke Level 3 — FPWD
  13. CSS Images Level 4 — updated WD
  14. CSS Rhythmic Sizing Level 1 — FPWD
  15. CSS Timing (Easing) Functions Level 1 — FPWD

As usual, please send feedback by either filing an issue in GitHub (preferable) or sending mail to the (archived) public mailing list with the appropriate spec code and your comment topic in the subject line. (Alternatively, you can email one of the editors and ask them to forward your comment.)

CSS Grid Layout Module Level 1

On 14 December 2017, the CSS WG published an updated Candidate Recommendation of the CSS Grid Layout Module Level 1.

This module defines a new type of layout manager, the grid, which makes it extremely easy to specify complex, responsive 2-dimensional layouts for a page or sub-component of the page.

This update incorporates all of the feedback received over the past year since the initial Candidate Recommendation in October 2016.

Major changes include

Significant changes are listed (with diffs) at in the Changes section, and a Disposition of Comments is also available.

Please send feedback with the spec code [css-grid-1].

CSS Scroll Snapping Module Level 1

On 14 December 2017, the CSS WG published an updated Candidate Recommendation of the CSS Scroll Snapping Module Level 1.

This module contains features to control panning and scrolling behavior with “snap positions”.

This update renames the scroll-snap-margin property to scroll-margin and applies it also to the target element of scrolling operations such as scrollIntoView(), focus(), and navigating to #fragment.

Note that scroll-padding is already applied generally, to allow adjustment of the scrolling area for visual continuity and to accommodate floating sidebars/headers/footers, without requiring JavaScript.

Significant changes are listed in the Changes section, and a Disposition of Comments is also available.

Please send feedback with the spec code [css-scroll-snap-1].

CSS Counter Styles Module Level 3

On 14 December 2017, the CSS WG published an updated Candidate Recommendation of the CSS Counter Styles Module Level 3.

This module introduces the @counter-style rule, which allows authors to define their own custom counter styles for use as list markers and generated content. It also predefines a set of common counter styles, including the ones present in CSS2 and CSS2.1.

This update addresses feedback received since the 11 June 2015 CR. Significant changes are listed in the Changes section; a Disposition of Comments is also available.

Please send feedback with the spec code [css-counter-styles-3].

CSS Writing Modes Level 3 and Level 4

On 7 December 2017, the CSS WG published an updated Candidate Recommendation of CSS Writing Modes Level 3 and a First Public Working Draft of CSS Writing Modes Level 4.

CSS Writing Modes defines CSS support for various international writing modes, such as left-to-right (e.g. Latin or Indic), right-to-left (e.g. Hebrew or Arabic), bidirectional (e.g. mixed Latin and Arabic) and vertical (e.g. Asian scripts).

Level 4 is the same as the previous Level 3 draft; several features were cut from Level 3 due to lack of implementation:

The only other change was to adjust the fallback “available space” for orthogonal flows to use the nearest fixed-size scrollport where available, rather than always using 100vh/vw.

The significant changes are all listed in the draft: Level 3 changes, Level 4 additions.

A Disposition of Comments is also available.

We anticipate transitioning Level 4 back up to Candidate Recommendation as soon as the requisite waiting periods have ended; Level 3 will transition to REC as soon as the last few tests pass in two implementations.

Please send feedback with the spec code [css-writing-modes].

CSS Transitions Module Level 1

On 30 November 2017, the CSS WG published an updated Working Draft of the CSS Transitions Module Level 1.

CSS Transitions allows property changes in CSS values to occur smoothly over a specified duration.

This update adds more precision and correctness to the draft in a number of cases and also adds some new events. Significant changes in the draft.

Please send feedback with the spec code [css-transitions-1].

CSS Animations Module Level 1

On 30 November 2017, the CSS WG published an updated Working Draft of the CSS Animations Module Level 1.

This module introduces declarative keyframe animations of CSS properties.

his draft folds in a number of previously-outstanding WG resolutions, as well as other fixes and clarifications, see status.

Please send feedback with the spec code [css-animations-1].

CSS Transforms Module Level 1

On 30 November 2017, the CSS WG has published an updated Working Draft of the CSS Transforms Module Level 1

CSS transforms allows elements styled with CSS to be transformed in two-dimensional space. This specification is the convergence of the CSS 2D transforms and SVG transforms specifications.

This update incorporates a lot of feedback since the earlier 2013 draft; 3D Transforms have been split out into Level 2.

There is no completed disposition of comments or changes list. The changelog can be found in the CSSWG’s drafts repository (part 3, part 2, part 1), and a partial disposition of comments, up through 31 December 2016, is available, with a number of resolutions for the issues therein logged in the Seattle F2F minutes (part 1, part 2. Subsequent issue-tracking was moved to GitHub.

Please send feedback with the spec code [css-transforms-1].

CSS Flexible Box Module Level 1

On 19 October 2017, the CSS WG published an updated Candidate Recommendation of the CSS Flexible Box Layout Module Level 1.

Flexbox is a new layout model for CSS. The contents of a flex container can be laid out in any direction, can be reordered, can be aligned and justified within their container, and can “flex” their sizes and positions to respond to the available space. We expect this model to be particularly useful for UI layouts.

This update addresses issues found since the 26 May 2016 publication. Exact diff-marked changes, and their justifications, are available in the Changes section. A Disposition of Comments resulting in the latest changes is also available.

Please send feedback with the spec code [css-flexbox-1].

CSS Box Alignment Level 3

Probably the worst announcement to have missed this year…

In August the CSSWG resolved to drop the grid- prefixes of Grid Layout‘s gutter properties, grid-gap/grid-row-gap/grid-column-gap, merging its row gap property with the existing Multi-column Layout module’s row-gap property and extending its functionality to apply to Flexbox as well. See full discussion.

As a result, on 6 September 2017 the CSS Working Group published an updated Working Draft of the CSS Box Alignment Module Level 3, shifting the definitions of these properties (and renaming them accordingly) to this module. (The Grid module has also been updated to remove the grid-gap definitions.)

There were no other changes since the draft six weeks prior.

Please send feedback with the spec code [css-align-3].

CSS Text Module Level 3

On 22 August 2017, the CSS WG published an updated Working Draft of the CSS Text Module Level 3.

This module contains various typesetting properties not related to font selection, such as alignment, line breaking, white space collapsing, text justification, and other forms of text-level spacing adjustments.

This update represents the handling of all comments received during the 2013 Last Call period and up through about mid-2015 (as well as a handful of later issues). A completed disposition of comments and a full changes list will be made available once the rest of the comments are handled. See the Disposition of Comments.

Please send feedback with the spec code [css-text-3].

CSS Logical Properties Level 1

On 18 May 2017, the CSS WG published a First Working Draft of the CSS Logical Properties and Values Module Level 1.

This module introduces properties and values that control layout through logical (writing-mode–relative), rather than physical, direction and dimension mappings. The module defines such flow-relative properties and values for the features defined in [CSS21] and older CSS modules; newer CSS modules are expected to define such equivalents on their own.

This is a very late FPWD for a variety of unfortunate reasons, however as a functional dependency of supporting writing-mode for HTML much of the draft has been implemented and shipped (per WG resolution, see minutes and explanation). An explanation of the status of the spec is given in the intro; note, the inset name was later resolved.

Further work on this module is likely to consist of fixing issues raised against details such as the cascading mechanism, and either resolving or deferring unstable features not required by HTML’s default UA stylesheet.

One of the major open issues is the syntax for switching margin-style shorthand parsing from physical to logical, and the WG would appreciate feedback and suggestions on this feature, see open issue.

Please send feedback with the spec code [css-logical-1].

CSS Fill and Stroke Module Level 3

On 13 April 2017, the CSS WG published a First Public Working Draft of the CSS Fill and Stroke Module Level 3.

This module extends the SVG fill and stroke properties to apply to text in CSS-formatted documents, allowing control over text fills and outlines. It also extends the properties to allow for layered image-based fills similar to the CSS background properties.

This is an early-stage Working Draft, and there are many open issues listed in the draft. Comments and suggestions are quite welcome on the mailing list or, preferably, in the FXTF GitHub repo with the spec code [fill-stroke-3].

CSS Images and Replaced Content Module Level 4

On 13 April 2017 the CSS WG published an updated Working Draft of the CSS Image Values and Replaced Content Module Level 4.

This module defines the CSS <image> type used in background-image and other image-accepting propertys, and additionally defines several properties for handling replaced elements. The main extensions compared to Level 3 are several additions to the <image> type: the image() notation, the element() notation, and conic gradients.

This is an early-stage Working Draft. The update includes a number of fixes as well as the addition of some new features:

Significant changes are listed in the draft.

Please send feedback with the spec code [css-images-4].

CSS Rhythmic Sizing Module Level 1

On 2 March 2017 the CSS WG published a First Public Working Draft of the CSS Rhythmic Sizing Module Level 1.

This module contains CSS features for sizing boxes in multiples of a “step size”.

This is an early-stage Working Draft and may change significantly as the feature designs are worked out. The line-height-step property in particular has raised a number of design concerns, see e.g. minutes of an F2F discussion.

The CSSWG is interested in use cases for line-height-step that are not better solved by either the block-step feature in the draft or by adjusting the inline layout model to exclude child boxes from the calculation of the line box height (thus forcing the line height to remain constant within a paragraph), as thus far the use cases presented for line-height-step seem to be better solved with these other approaches.

Please send feedback with the spec code [css-rhythm-1].

CSS Timing (Easing) Functions Module Level 1

On 21 February 2017, the CSS WG published a First Public Working Draft of the CSS Timing Functions Module Level 1.

This module extracts the various timing functions previously specified in CSS Transitions into their own module, for easier re-use across modules.

It also adds a new stepped timing notation for looped animations (called
frames() in the FPWD, but to be changed to an extension of steps()).

There was a request to change the name of the module to be more general for potential re-use with progressions other than time, such as in gradients; therefore, unless someone comes up with a much better idea soon, it is expected that the next publication will be titled CSS Easing Functions [css-easing].

Please send feedback with the spec code [css-timing-1].


The Future of Style features:

If you have a post you want to add to this feed, post a link (or the whole thing) on the CSS3 Soapbox. If you own a blog with frequent posts about the future of CSS, and want to be added to this aggregator, please get in touch with fantasai.


Made with CSS! Valid CSS!Valid HTML 4.0! RSS feed Atom feed