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

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 group-ag-chairs@w3.org.

WAI-ARIA 1.1

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 Jon Davis • 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

Fetch

Intelligent Tracking Prevention

CSS

Rendering

SVG

JavaScript

Web Inspector

Media

Storage

Security

Accessibility

Bug Fixes

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

Source: W3C's Cascading Style Sheets home page07 February 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.

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: ', entry.target);
      console.log(`Element size: ${cr.width}px × ${cr.height}px`);
      console.log(`Element padding: ${cr.top}px / ${cr.left}px`);
    }
  });

  // Observe one or multiple elements
  ro.observe(someElement);

import.meta

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 www-style@w3.org 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 Jon Davis • 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

SVG

Service Workers

CSS

Web API

Rendering

Web Inspector

Web Driver

Accessibility

WebRTC

JavaScript

WebAssembly

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

Speedometer 2.0: A Benchmark for Modern Web App Responsiveness

Source: Surfin' Safari Addy Osmani, Mathias Bynens, Ryosuke Niwa • 16 January 2018

In 2014, the WebKit team at Apple released Speedometer 1.0, a benchmark for web app responsiveness. It simulates user interactions in web applications, using TodoMVC to orchestrate adding, completing, and removing todo items. Speedometer repeats these actions using DOM APIs that were extensively used in real-world applications. The performance of these kinds of operations depends on the speed of the JavaScript engine, DOM APIs, layout, CSS style resolution and other parts of the browser engine.

Browser engineers have been optimizing their engines using Speedometer as a proxy for real-world use of popular frameworks for a number of years. Originally, Speedometer included implementations of todo apps in six popular JavaScript frameworks and libraries in heavy use: Ember, Backbone, AngularJS, jQuery, Flight, and an early version of React. It also included vanilla JavaScript.

The web developer ecosystem has evolved significantly since Speedometer 1.0 was first released, as have the trends in what libraries, frameworks, and programming paradigms are used. Developers now commonly use transpilers, module bundlers, and recently-introduced frameworks when creating new sites. This is why, for the last year, engineers from WebKit and Chromium have been collaborating on a new version of Speedometer that better reflects the frameworks, tools, and patterns in wide use today.

Today, we are pleased to announce the Speedometer 2.0 benchmark. We hope this new version of Speedometer helps browser vendors optimize their browser engines for the modern Web.

Support for modern JavaScript frameworks and libraries

Over the last three years, a growing number of real-world sites have been written using React — a JavaScript library for authoring user interfaces. Derivatives such as Preact and Inferno have also gained popularity. Speedometer 2.0 includes web apps implemented using these libraries. It also includes an entry using React and Redux — a popular state management library.

Webpack and Rollup are popular JavaScript module bundlers frequently used with these libraries and Speedometer 2.0 includes output generated by these tools.

Ember.js, which featured in the original Speedometer, now has a dedicated tool to create new projects, and provides a more streamlined deployment process for authors. In addition, there were large changes to the core Ember framework over the years. To incorporate these changes in Ember.js itself and the way developers use Ember.js today, Speedometer 2.0 includes an implementation using the latest Ember, built using Ember CLI.

Another framework we observed gaining traction is Vue.js — a progressive solution aimed at being incrementally adoptable. Similar to Ember, Vue.js has prescriptive tooling for getting started and Speedometer 2.0 includes a Vue.js implementation built using the Vue CLI.

It’s of course true that not all real-world sites are being built using these solutions. Many are still deployed using libraries that were popular when Speedometer 1.0 was authored, which is one reason Speedometer 2.0 also includes updates to implementations written in AngularJS, Backbone.js, and Flight.

ES2015 JavaScript and Babel support

Speedometer 1.0 included a version of the todo app implemented with vanilla JavaScript — i.e. without using any libraries or frameworks. At the time, web developers primarily wrote their applications in the version of JavaScript known as ES5. Today, modern browsers have excellent support of ES2015 (also known as ES6), a more evolved version of JavaScript. Speedometer 2.0 now includes a todo app implemented using ES2015 features like classes, const, let, arrow functions, and template literals.

Although measuring vanilla JavaScript performance has high value, a growing number of developers today also use transpilers like Babel to transpile the latest versions of JavaScript code back to a version supporting all browsers they care about. To reflect this workflow, Speedometer 2.0 includes an ES2015 implementation that uses ES Modules and has ES5 output generated by Babel. In the future, as browsers gain full support for native ES Modules, we hope to evolve the benchmark to also track an implementation that isn’t bundled or translated.

TypeScript support

TypeScript is a typed superset of JavaScript that has been gaining traction in the web developer community. It offers types as a first-class syntax, generally fast compilation, and rich tooling for type-aware auto-completion and error highlighting during iteration.

Today, one of the largest users of TypeScript is Angular. To enable browsers to measure the kinds of output a TypeScript app might generate, Speedometer 2.0 includes an Angular implementation written in TypeScript, transpiled to ES5. We’re hopeful that browsers optimizing for this implementation will be able to offer the same wins as more frameworks introduce TypeScript support.

Future-facing: functional programming

The front-end developer community has been shifting in the direction of borrowing more patterns from functional programming. This has been demonstrated with the growth of interest in technologies like Elm and PureScript, both of which transpile down to JavaScript. To enable browsers to optimize for these patterns, Speedometer 2.0 includes implementations for both of these technologies.

Updates in score calculation

Speedometer 1.0 calculated a final score for Web App Responsiveness using the arithmetic mean of the run time needed to add, mark completed, and remove 100 todo items in each implementation in order to incentivize browser vendors to optimize the slowest framework or library. Unfortunately, this resulted in some implementation of a todo app getting 25× more weight compared to another as we added more libraries and frameworks to Speedometer 2.0. It became particularly problematic when we added back a debug build of Ember — it was more than 4× slower than the Ember production build. However, only a small fraction of websites deployed with Ember use debug builds.

In Speedometer 2.0, we’ve changed the score to be computed as the geometric mean against different implementations of the todo app. The final score is computed as the arithmetic mean of the geometric means computed for each iteration of the benchmark.

Future

Speedometer 2.0 has been an exciting collaboration between browser vendors. We would like to build on this collaboration in future iterations of the benchmark by working more closely with framework authors and the developer community to identify broadly-used patterns, frameworks, and tools for which browser engines could be optimized.

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

Media

Rendering

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?

Books

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.

Conclusion

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

Minutes Telecon 2017-12-20

Source: CSS WG BlogDael Jackson • 06 January 2018

Minutes Telecon 2017-12-13

Source: CSS WG BlogDael 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.

Culture

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.

AI

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 => { dialogBox.open(); }) .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 www-style@w3.org 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 public-fx@w3.org 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].

PR of CSS Basic User Interface Module Level 3

Source: CSS WG Blog Florian Rivoal • 29 December 2017

The CSS WG has published a Proposed Recommendation of the CSS Basic User Interface Module Level 3. This specification describes user interface related properties and values that are proposed for CSS level 3 to style HTML and XML (including XHTML). It includes and extends user interface related features from the properties and values of CSS level 2 revision 1. It uses various properties and values to style basic user interface elements in a document.

This document is intended to become a W3C Recommendation. This document will remain a Proposed Recommendation at least until 1 February 2018 in order to ensure the opportunity for wide review. The W3C Membership and other interested parties are invited to review the document and send comments. Advisory Committee Representatives should consult their WBS questionnaires.

Changes since the last Candidate Recommendation are listed in the Changes section.

A disposition of comments and implementation report are available.

Please send feedback by either filing an issue in GitHub (preferable) or sending mail to the (archived) public mailing list www-style@w3.org with the spec code ([css-ui-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 WD of CSS UI Level 4

Source: CSS WG Blog Florian Rivoal • 29 December 2017

The CSS Working Group has published an updated Working Draft of CSS Basic User Interface Module Level 4.

This specification describes user interface related properties and values to style HTML and XML (including XHTML). It includes and extends user interface related features from the properties and values of previous CSS levels. It uses various properties and values to style basic user interface elements in a document.

CSS-UI Level 4 includes all features defined for level 3, as well new features and extensions of existing ones:

Changes since the last Working Draft are listed in the Changes section.

Please send feedback by either filing an issue in GitHub (preferable) or sending mail to the (archived) public mailing list www-style@w3.org with the spec code ([css-ui-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: CSS Basic User Interface Level 4.

Source: W3C's Cascading Style Sheets home page22 December 2017

22 Dec 2017 Updated Working Draft: CSS Basic User Interface Level 4.

Release Notes for Safari Technology Preview 46

Source: Surfin' Safari Jon Davis • 20 December 2017

Safari Technology Preview Release 46 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 225266-225841.

Service Workers

Offline applications are important to the web. After HTML5 first tried to accommodate them with the Offline Application Cache, the Service Workers specification was created as a successor.

This standard describes new APIs focused on using JavaScript to handle resource loading for a web page without network access. While work continues, we’re excited to enable Service Workers by default in this release. Please test our implementation with your websites and send us feedback using the WebKit project bug tracker.

Security UI

Privacy

CSS

Rendering

Storage Access API

Web Inspector

Web Assembly

Web Driver

JavaScript

Media

WebRTC

How should we resolve percentage margins and padding on grid and flex items?

Source: CSS WG Blog Rachel Andrew • 20 December 2017

The CSS Working Group would like your opinion. There is a longstanding issue in both the CSS Grid Layout and Flexbox specifications.

From the CSS Grid specification:

Percentage margins and paddings on grid items can be resolved against either:

• their own axis (left/right percentages resolve against width, top/bottom resolve against height), or,

• the inline axis (left/right/top/bottom percentages all resolve against width)

A User Agent must choose one of these two behaviors.

Note: This variance sucks, but it accurately captures the current state of the world (no consensus among implementations, and no consensus within the CSSWG). It is the CSSWG’s intention that browsers will converge on one of the behaviors, at which time the spec will be amended to require that.

Authors should avoid using percentages in paddings or margins on grid items entirely, as they will get different behavior in different browsers.

The flexbox specification has the same wording.

What is the problem here?

A percentage has to be resolved against something. If you give a grid item a margin-right of 10%, you would probably expect that 10% to be calculated as 10% of the width of the grid area. What happens however if you give the item a margin-bottom of 50%? Do you expect it to resolve to 50% of the total height of the grid area or do you expect it to calculate 50% from the width? The spec allows for both, and browser implementations are split.

You can see the problem in this very simple CodePen. We have three column tracks which are each 120 pixels in width. The margin-right applied to each track resolves to 12 pixels, 10% of 120.

In Chrome and Safari the margin-bottom resolves to 60 pixels. 50% of the width of 120 pixels is 60 pixels.

In Firefox and Edge the margin-bottom uses the height of the grid area and so in this case resolves to 150 pixels as I have put a height on the grid and items are stretching.

If you remove the height on the grid container you will see how Firefox now completely collapses the container as there is now no height to resolve against. Chrome will keep the container at 60 pixels – that being the margin.

We see the same variance in Flexbox, however in Flexbox we resolve against the flex container as the containing block. However you can see in the below example how Chrome uses 10% of 500 pixels for the margin-right, and 50% of 500 pixels for margin-bottom. Firefox uses 10% of 500 pixels for margin-right and 50% of 300 pixels for margin-bottom.

The fact that percentages resolve from the width is essentially a throwback to the old days of layout on the web where we didn’t have great control over the height of things. The width was the measurement we could control and so became the dominant measurement.

The ‘aspect ratio hack’

One reason to follow the Chrome behaviour here is that it allows the percentage-based padding “aspect ratio hack” to work on flex and grid items. There is an excellent write-up of the interoperability issue on Bram.us – Vertical margins/paddings and Flexbox, a quirky combination, the issue is also detailed on Flexbugs and Gridbugs.

However, perhaps a better solution is to properly solve the aspect ratio issue, while also deciding on one solution for margins and padding in general.

We want your feedback!

The CSS Working Group would love to know your thoughts on this issue. As you can see above this is not an issue when using horizontal percentage margins and padding, this continues to work as it always has done. The issue is with vertical margins and padding. Would you prefer the Chrome behaviour, of the Firefox one? Other than the aspect ratio padding hack, are you using vertical margins and padding for any other reason?

You can comment directly on the GitHub issue with thoughts and use cases. It would be great to get this particular interoperability problem solved.

Cross-posted to rachelandrew.co.uk.

New Proposed Recommendation: CSS Basic User Interface Level …

Source: W3C's Cascading Style Sheets home page14 December 2017

14 Dec 2017 New Proposed Recommendation: CSS Basic User Interface Level 3. Updated Candidate Recommendation: CSS Counter Styles Level 3. Updated Candidate Recommendation: CSS Grid Layout Level 1. Updated Candidate Recommendation: CSS Scroll Snap Level 1.

Minutes Telecon 2017-12-06

Source: CSS WG BlogDael Jackson • 09 December 2017

Full Minutes

New Working Draft: CSS Writing Modes Level 4. Updated Candid…

Source: W3C's Cascading Style Sheets home page07 December 2017

7 Dec 2017 New Working Draft: CSS Writing Modes Level 4. Updated Candidate Recommendation: CSS Writing Modes Level 3.

Release Notes for Safari Technology Preview 45

Source: Surfin' Safari Jon Davis • 06 December 2017

Safari Technology Preview Release 45 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 224579-225266.

If you recently updated from macOS Sierra to macOS High Sierra, you may need to install the High Sierra version of Safari Technology Preview manually.

Rendering

JavaScript

CSS

Web API

Media

Web Inspector

Accessibility

Feeds

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.

fantasai

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