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-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.

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

Source: W3C's Cascading Style Sheets home page15 January 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 Burlingame, CA F2F 2017-11-06 Part II: Flexbox, Image Decoding, Line Clamping, Cleaning up OWNERS files, Feedback on Testing Policy, Values & Units, Contains, Line Grids, Line Heights

Source: CSS WG Blog Dael Jackson • 14 January 2018

Flexbox

Full Minutes || Spec Referenced

Image Decoding

Full Minutes

Line Clamping

Full Minutes

Cleaning up OWNERS files

Full Minutes

Feedback on testing policy

Full Minutes

Values and Units

Full Minutes || Spec Referenced

Contains

Full Minutes || Spec Referenced

Line Grid

Full Minutes

Line Heights

Full Minutes || Specs Referenced: CSS Inline CSS 2.1

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

Updated Candidate Recommendation: CSS Color Level 3.

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

5 Dec 2017 Updated Candidate Recommendation: CSS Color Level 3.

Updated Working Draft: CSS Animations. Updated Working Draft…

Source: W3C's Cascading Style Sheets home page30 November 2017

30 Nov 2017 Updated Working Draft: CSS Animations. Updated Working Draft: CSS Transforms. Updated Working Draft: CSS Transitions.

Minutes Telecon 2017-11-22

Source: CSS WG BlogDael Jackson • 23 November 2017

Full Minutes

Publishing Working Group TPAC 2017 Summary

Source: W3C Blog Tzviya Siegman • 17 November 2017

On November 6 and 7, the Publishing Working Group held a face-to-face meeting in Burlingame, California. The meeting was part of W3C’s massive TPAC conference, where immersion in spec work was the goal. Having TPAC at an airport hotel meant there were no distractions, which was perfect. We had participants from five continents, ranging in age from “don’t ask” all the way down to less than one.

Ivan Herman focuses his attention on a baby.

Ivan Herman, Garth Conboy, and a PWG guest

Update on FPWD for WP and PWP

The working group’s overarching goal is to publish first public working drafts (FPWD) of both the Web Publications (WP) spec, edited by Matt Garrish, and the Packaged Web Publications (PWP) spec, edited by David Wood. We hope to publish these in the next few weeks, and TPAC was the chance to discuss and hopefully resolve many of the major issues.

Of course, a specification without tests is just words, and we have lots of volunteers to help with testing, but no one (yet) to lead the testing effort.

Web Publication Lifecycle and Manifest

Naming things is hard—we even use the term “bikeshedding” to describe arguing about names. We’d previously used the term “manifest” to describe the components and structure of a web publication, but the term is so overused in other contexts that we decided to use “waybill” as a working term to avoid confusion for now.

One of those contexts is the Web Application Manifest (WAM). Through discussion in the group and with Kenneth Rohde Christiansen, we agreed that we will likely reuse some of the terms from WAM, and perhaps WAM will be able to adapt some terms from publishing. However, we have different processing models, and PWG may need to diverge from WAM when it comes to processing. The PWG will continue to work with WAM as we sort out the details of our metadata requirements. We hope we can contribute to their work, and they can contribute to our work.

Tim Cole suggested that we use terminology from FRBR to discuss the lifecycle of a WP: Discover, Identify, Select, Obtain.

  1. Discovery is finding the publication via search, reference or some other means.
  2. Identify roughly corresponds with the identifier and the addressability.
  3. Selection is a disambiguation process.
  4. Obtaining is the process of opening the publication.

We also talked about whether it would be possible for each component of a web publication to link to the “waybill”, or somehow indicate that it was part of a particular web publication. But this would prevent a component from being reused in other web publications, which is a major goal of some publishers. The discussion did help us clarify our understanding of the components of a publication.

Internationalization

Richard Ishida, Addison Phillips, and Fuqiao Xue of the Internationalization WG joined the group to discuss their work. The site includes information on how to participate, requirements, developer support, and education and outreach at https://w3c.github.io/i18n-activity/projects/. The goal is to have all Working Groups and specs do self-review using the ongoing work and requirements. The I18n WG is looking for contributions to the Typography Matrix. Even photographs of books in the languages with gaps in the table are helpful.

Packaging

The group has put together packaging requirements. EPUB is a packaging format for web content like HTML and CSS, but it doesn’t actually work directly in web browsers. What would a packaging format for web publications look like, when we want it to be a part of the Web? We discussed existing packaging formats on the Web, including MIME, webpack, tar, gzip, zip, and CBOR. Leonard Rosenthal gave a presentation about the future of PDF, which could potentially be used as a packaging method for web content in the future. We have not yet reached a conclusion about which packaging format we will specify, but the FPWD does not need to be that specific, and David Wood graciously agreed to edit the draft.

Synchronized Media

Marisa DeMeglio and Daniel Weck of the DAISY Consortium offered an overview of the work they have been doing to ensure that synchronized media publications continue beyond EPUB 3’s Media Overlays. Synchronized audio books usually offer sound with highlighted text as the user progresses through. Requirements and design options are available at https://github.com/w3c/publ-wg/wiki/Requirements-and-design-options-for-synchronized-multimedia. The basic requirements are that audio playback is synchronized, navigate in the audio the same way one navigates in the text, escape complex structures (e.g. out of a table), some customization (e.g. don’t follow footnotes). There are several specifications today that enable some of the requirements. We are also hoping to close the gap between audiobooks and books that have an audio component. The group recognizes that this is a need for the Web as a whole, not just for publishing, and we are exploring work on existing standards, such as MPEG and TTML. We are planning to set up a Community Group devoted to this work. See also Romain Deltour’s slides about synchronized audio books.

Security, Privacy, and Integrity

The PWG plans to rely heavily on the basic security model of the Web. We rejected restrictive models such as AMP or even limiting JavaScript as was done in EPUB 3. This has proven to be an unsuccessful method. Some feel very strongly that privacy for publications must go beyond what is available today because users have different expectations from publications than of the Web. Others stressed that terms like “spying” are misleading because observing reading habits allows UAs to offer readers experiences such as keeping their place in a publication. The group discussed adding slots for signatures to ensure integrity of the content (that the publication has not changed since obtaining it). There is a need for user privacy as well. Readers have a much higher expectation of privacy within a reading environment than in a web app, and we plan to include a statement, perhaps more social than technical, in our document explaining that.

Locators

Tim Cole has been working on a Locators document that expands on the Web Annotations Selectors and States. He queried the group to determine whether we need to retain some of the unique attributes of EPUB CFI, the fragment identifier for EPUB. We discussed whether there should be a fragment id (no), whether we need side bias and text position selectors (including sortability), and selection of continuous and discontinuous embedded resources. We are seeking feedback from those systems that use CFI about whether their needs are met. We’re looking at you VitalSource.

Meeting with Accessible Platforms Architecture Group (written by Avneesh Singh)

The joint session of PWG Accessibility Task Force, Accessible Guidelines (Silver) Task Force and APA was addressed the incorporation of accessibility requirements specific to publishing to WCAG 3.0 (Silver) and way forward for Media Overlays specifications.

Topic 1: Incorporation of accessibility requirements specific to publishing in WCAG 3.0.

The Silver task force was happy to receive the publishing requirements compiled at https://github.com/w3c/publ-a11y/wiki/Publishing-issues-for-Silver.

They were also briefed about the architectural issues in WCAG 2.0/2.1 due to which accessibility metadata was accepted as optional conformance in WCAG 2.1, while it is extremely important component of publications. The Silver task force stated that these issues will help them in creating a better design. APA conveyed their intent to propose the concept of pages to HTML working Group because it is a requirement for mobile devices also, and this would address the needs of publishing as well as of mobile users. Regarding timeline, it is a longer term work. Silver task force will be working on research and design in coming months, and they stated that actual work would pick up one year from now.

Topic 2: Exploring paths for moving ahead Media Overlays specifications.

The presentation was well accepted. APA group mentioned that they worked on somewhat similar requirements and developed a document some years ago at https://www.w3.org/WAI/PF/media-a11y-reqs/.

The groups also discussed the existing technologies that may be useful i.e. TTML and Web VTT. The issue with these technologies is that the media is the master and text is associated to it. But in our case we need the text to be the master because the audio or video has to be an overlay. The structure and formatting should be provided by the publication, and media should be synchronized with it. So, TTML and WebVT are doing the reverse of that we need.

The advice was to go through second screen work, and explore other groups that may have the similar requirements. Some group members also suggested some ways in which TTML and Web VTT can be useful for our work. The broad view was to start a community group to explore the path ahead, and APA will help in communicating this work to other groups in W3C.

Breakout session on offlining

We had a packed room for a breakout session featuring Brady Duga, Benjamin Young, Jake Archibald, and Dave Cramer (via Skype) to discuss some basic questions what we need to offline publications and what the components of a publication are. We quickly concluded that ServiceWorkers should be able to do the job, but there is a great deal yet to be defined. Many of the questions that need to be answered have to do with the relationship of Web Publications to browsers. Jake made it clear to Publishers that browsers are really bad at guessing what to do with declarative markup and specifications that don’t explain behaviors. As a group, we are considering the need to create a JavaScipt Polyfill that provides a UI. This would not be provided by every publisher. Instead, it would be a universal, default UI.

Next steps

There are many open issues on GitHub. Please add your thoughts, and we will publish FPWD of WP and PWP within the coming weeks. Thank you to all who traveled to Burlingame and all who participated remotely.

Minutes and Drafts

Last week’s may be our best TPAC ever; W3C Strategic Highlights

Source: W3C Blog Jeff Jaffe • 15 November 2017

TPAC 2017 logoTPAC 2017, which we held last week next to the San Francisco airport, was a very successful event, where more than 600 participants registered, over 250 were drawn by our Developer Meetup, 150 members from the global publishing community participated at the first W3C Publishing Summit, while our first W3C Executive Forum attracted over 50 senior executives from Silicon Valley technology companies as well as international leaders from automotive, entertainment, financial services, gaming, real estate and retail industries. That is over 1,000 experts and aficionados from the Web community who met in over five days. It was the highest attendance ever for a TPAC. We heard and read unsolicited positive comments from so many attendees that we are glad the feeling is mutual.

36 work group and 5 W3C Community Groups met face-to-face on the first and last two days of the week, the Plenary session filled the room in the morning around topics of core Web innovation, improving how we do Web standards, and improving interoperability with web-platform-tests; and the masses splintered to organize 40 breakout sessions and reassembled to report and hear ideas, progress, proposals, etc.

This TPAC was marked with a resurgence in innovation around the core architecture of the Web.

Core innovation [Lightbulb design credit: Freepik]

The Web is again being enhanced in many diverse areas (Extensible Web, WebRTC, Web Assembly, Web Performance, Web Payments, WebVR, Web Authentication, Service Workers, Web Components, MSE) which will improve everyone’s experience on the Web, and drive improved commercial applications in financial services, e-commerce, entertainment, telecommunications, publishing, and gaming.

Of particular excitement was the energetic presentations provided by developers at the W3C developer meetup. It truly brought out the excitement in the usage of the Web; in areas such as usability, accessibility, performance, Web apps, WebVR, styling with CSS Grid, Web Components.

As part of preparation for TPAC we published for the Membership “W3C Highlights – November 2017,” now public, which I invite you to read.

We are already looking forward to TPAC 2018, 22-26 October in Lyon, France.

Release Notes for Safari Technology Preview 44

Source: Surfin' Safari Jon Davis • 15 November 2017

Safari Technology Preview Release 44 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 223953-224579.

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.

Conic Gradients

Payment Request

Image Bitmap

Web API

CSS

Rendering

Web Inspector

Web Driver

Media

CSS Grid

Security

Extensions

Updated Working Draft: CSS Properties and Values API Level 1…

Source: W3C's Cascading Style Sheets home page09 November 2017

9 Nov 2017 Updated Working Draft: CSS Properties and Values API Level 1.

What’s new in Chromium 62 and Opera 49

Source: Dev.OperaDaniel Bratell • 08 November 2017

Opera 49 (based on Chromium 62) 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.

Network Quality Estimator API

There are times when a web page want to adapt to the user’s network. To help a web page with that information there is now the Network Information API which can give a rough indication of the user’s network, including bandwidth and round-trip time.

This is still under development but the parts that exist today, rtt, effectiveType and downlink, should be enough for most use cases.

The plan is that these signals will also become available as HTTP request headers and enabled via Client Hints.

OpenType Variable Fonts

Previously a font file could only contain one weight/variant of a font. So you had one file for bold, one file for semi-bold, one for stretched, one for normal and so on. With OpenType Font Variations you can combine those variants efficiently in a single file. This should allow web pages to be smaller and load faster than before, while also giving them access to an infinite number of font variants (not that I recommend using more than a few in a page).

Animated font-variants

Animation based on Amstelvar and Decovar

Stretch, style, and weight can be adjusted by giving a numerical value to respective CSS property, or by setting the font-variation-settings CSS property.

Media Capture from DOM Elements

It is now possible to stream animations directly from a canvas or video element to anything that can handle a stream. Previously it was only possible to stream from capture hardware on the computer.

Through the W3C Media Capture from DOM Elements API you can call captureStream() on any HTMLMediaElement and send it to another video element or stream it remotely through WebRTC. Or process or manipulate it in other ways.

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.

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