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

New Working Draft of CSS Box Model Level 3

Source: CSS WG Blogfantasai • 09 August 2018

The CSS WG has published two back-to-back Working Drafts of the CSS Box Model Module Level 3. The first publication archives Bert and Anton’s changes to that spec since the 2007 draft for archaeological purposes. (Note: It is still dangerously out-of-date, please continue to reference CSS2.) The second publication cuts the module down to a subset of CSS2 Chapter 8.

The scope of this module is now just the margin and padding properties. We have dropped all of the spec content that discusses box generation (moved to the CSS Display Module) or the Block Layout model (will become its own module based on the prose in CSS2—which has been maintained—rather than what was in earlier publications—which was not). The remaining content, which discusses the box model (margin/padding/border/content areas) has been synced to CSS2. See Introduction. There are no non-editorial changes since CSS Level 2, other than adapting the prose slightly to account for vertical writing modes.

A future revision of this module might include the border styling properties (currently defined in CSS Backgrounds and Borders); whether or not to move them is currently open question, thoughts on this idea welcome.

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-box-3]) and your comment topic in the subject line. (Alternatively, you can email one of the editors and ask them to forward your comment.)

New Candidate Recommendation: CSS Painting API Level 1. Upda…

Source: W3C's Cascading Style Sheets home page09 August 2018

9 Aug 2018 New Candidate Recommendation: CSS Painting API Level 1. Updated Working Draft: CSS Display Level 3. Updated Working Draft: CSS Box Model Level 3.

Call for Review: EPUB 3.2

Source: W3C BlogDave Cramer • 08 August 2018

We live in exciting times for the world of ebook standards, with the IDPF-W3C merger and web publications. Yet for most of us, the EPUB we create and consume has not changed in a while. EPUB 3.0 came out nearly seven years ago. The minor changes of EPUB 3.0.1 happened more than four years ago. EpubCheck hasn’t had a major release in nearly three years. That’s not necessarily a bad thing for mature specs. EPUB 3 works. It satisfies lots of use cases, and lots of actual users. Most publishers have existing tools and processes to create and distribute EPUB 3 (if you don’t, you should).

But the world, and especially the world wide web, keeps changing. HTML and CSS, the building blocks of EPUB, keep getting more powerful. Implementations evolve. New media types are invented. And specs must adapt to those changes. In April, I wrote a blog post about the recent history of EPUB 3, and why the W3C EPUB 3 Community Group was working on EPUB 3.2.

I’m pleased to say that the work has gone well. We’ve created a draft spec that satisfies our requirements of being completely backward-compatible with EPUB 3.0.1, while updating EPUB’s relationship to the core web specs of HTML, CSS, SVG, etc. But don’t take my word for it—go see for yourself.

Consider this a formal request for wide review of the EPUB 3.2 specification. Let us know what you think. Is the spec clear? Readable? Implementable? We want to hear about everything from typos to fatal flaws. If you’re comfortable with GitHub, the best way to provide feedback is through GitHub Issues. We’re also happy to receive emails. The ambitious can even send us pull requests.

EPUB 3.2 is a modular family of specifications. Feel free to review any or all of them. Note that we have not made any changes to EPUB Accessibility, as it is not tied to a particular version of EPUB.

  1. EPUB 3.2 Overview: A non-normative introduction to EPUB
  2. EPUB 3.2 Specification: One spec to rule them all!
  3. EPUB Packages 3.2: describes the package document, which provides both metadata and structure for the publication
  4. EPUB Content Documents 3.2: the good stuff: HTML, CSS, and more!
  5. EPUB Open Container Format: how to turn a bundle of content into a single file
  6. EPUB Media Overlays 3.2: how to synchronize audio and text in EPUB
  7. EPUB 3.2 Changes: what’s changed since EPUB 3.0.1.

Our plan is to spend about two months in this final review period, until around the end of September or beginning of October. We will address all the feedback, and create a final version of EPUB 3.2, which will need approval from the Publishing Business Group before being published as a final community group report.

Thank you for your attention, and please let us know if you have any questions.

—Dave Cramer (Hachette Livre) and Rachel Comerford (Macmillan Learning), co-chairs of the EPUB 3 Community Group.

Updated Working Draft: CSS Inline Layout Level 3.

Source: W3C's Cascading Style Sheets home page08 August 2018

8 Aug 2018 Updated Working Draft: CSS Inline Layout Level 3.

CSS Grid Level 2 Updated: Subgrid Specification Completed

Source: CSS WG Blogfantasai • 04 August 2018

The CSS Working Group has published an updated Working Draft of CSS Grid Layout Level 2. This draft contains the “subgrid” feature that was cut from the Level 1 CR last year, along with a few other minor things.

At this point there are no further issues open against the subgrid feature, so we’re asking for everyone to conduct their final reviews against the feature. Changes since the last Working Draft are listed in the Changes section.

For the next update of this draft, we’ll be incorporating the full text of the CSS Grid Level 1 specification along with the spec text for a few small feature requests (which depend on incorporating the L1 prose):

Once that text is incorporated, the Level 2 spec will be feature complete, and we’ll start preparing it for Candidate Recommendation.

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-grid-2]) 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 Inline Layout Level 3

Source: CSS WG Blogfantasai • 04 August 2018

The CSS Working Group has published an updated Working Draft of CSS Inline Layout Level 3. This module describes the css features relating to inline box layout in the block-axis dimension, particularly vertical alignment within a line and initial letter styling (drop caps, etc.).

This update includes a pile of improvements to the specification for initial letter styling as well as the outline of a property to control the height of the background/border areas of an inline box. Changes since the last Working Draft are listed in the Changes section.

There are still a lot of open issues, including more precise definition of the initial letters’ layout model as well as several property/value naming issues. The CSSWG welcomes feedback on these issues and on the draft in general.

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-inline-3]) and your comment topic in the subject line. (Alternatively, you can email one of the editors and ask them to forward your comment.)

Updated Working Draft: CSS Grid Layout Level 2.

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

4 Aug 2018 Updated Working Draft: CSS Grid Layout Level 2.

Updated Working Draft: CSS Inline Layout Level 3.

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

2 Aug 2018 Updated Working Draft: CSS Inline Layout Level 3.

Release Notes for Safari Technology Preview 62

Source: Surfin' Safari 01 August 2018

Safari Technology Preview Release 62 is now available for download for macOS High Sierra and the beta of macOS Mojave. If you already have Safari Technology Preview installed, you can update from the Mac App Store’s Updates tab on macOS High Sierra and in the Software Update pane of System Preferences on macOS Mojave. This release covers WebKit revisions 233728-234197.

Known Issues

Intelligent Tracking Prevention

JavaScript

Media

Rendering

Dark Mode

Web API

Web Inspector

SVG

Web Animations

CSS

IndexedDB

Accessibility

CSS Overflow 3 Draft Updated

Source: CSS WG Blog Florian Rivoal • 31 July 2018

The CSS Working Group has published an updated Working Draft of CSS Overflow level 3. This modules contains the features of CSS relating to handling the display of excessive amount of content in an element.

In addition to bug fixes and refinements accumulated since last publication, this draft introduces:

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-overflow-3]) and your comment topic in the subject line. (Alternatively, you can email one of the editors and ask them to forward your comment.)

Updated Working Draft: CSS Overflow Level 3. Updated Working…

Source: W3C's Cascading Style Sheets home page31 July 2018

31 Jul 2018 Updated Working Draft: CSS Overflow Level 3. Updated Working Draft: CSS Basic Box Model Level 3.

The World Wide Success That Is XML

Source: W3C Blog Liam Quin • 27 July 2018

Most of the XML Working Groups have been closed by now; this year saw XQuery and XSLT close, their work successfully completed.

As we wind down work on standardizing the XML stack at W3C it’s worth looking at some of what we have accomplished and why. W3C XML, the Extensible Markup Language, is one of the world’s most widely-used formats for representing and exchanging information. The final XML stack is more powerful and easier to work with than many people know, especially for people who might not have used XML since its early days.

Today, XML tools work with JSON, with linked data, with documents, with large databases (both SQL/relational and NoSQL), with the Internet of Things and in automobiles and aircraft and music players. There are even XML shoes. It’s everywhere.

XML can be stored in very efficient databases and processed with a highly optimized query language (XQuery, and its younger cousin JSONiQ), can be transformed with an efficient declarative tree manipulation language (XSLT 3), orchestrated in pipelines (XProc), delivered with one of the most effective compression schemes around (EXI, with low entropy server-side parsing), formatted to PDF with both XSL-FO and CSS, and all of these things can be done both with proprietary applications and with open source software.

How did we get here?

The Web SGML Working Group was formed to solve a specific problem: to agree on a subset, or profile, of the large and complex SGML specification that could be shared on the Web and displayed in browser plugins. There were two such plugins at the time, one from SoftQuad (Panorama) and one from EBT/Inso that was never released. Unfortunately it was difficult to construct an SGML document that both plugins would display – there was a clear need for a standard.

We were not trying to replace HTML. We weren’t even expecting native XML support in Web browsers. Nor were we trying to make a format for interchange of data or for remote procedure calls.

XML has some redundancy in its syntax. We knew from experience with SGML that documents are generally hard to test, unlike program data, and the redundancy helped to catch errors early and could save up to 80% of support costs (we measured it at SoftQuad). The redundancy, combined with grammar-based checking using schemas of various sorts, helped to improve the reliability of XML systems. And the built-in support for multilingual documents with xml:lang was a first, and an enduring success.

XML, XSL-FO, XSLT, XQuery, XML Schema, XProc, EXI, all of these Working Groups included world experts and had strong industry representation. They were guided by experienced chairs.

Most of the work has finished: people are using the specifications in production and the rate of errata has slowed to a crawl. XQuery,  XSLT and EXI ended this year.  But just because the specification work is ending doesn’t mean XML is ending! It means XML is at a stage where the technology is mature and widely deployed. People aren’t reporting many new problems because the problems have already been worked out.

For sure some of the more recently-published specifications are still rolling out: XSLT 3 is very recent, but there was good implementation experience when it was published as a Recommendation. EXI Canonicalisation was published as a Recommendation this past June, and because EXI can be used to send just about any stream of parse events over the wire much more efficiently than compressing the interchange syntax, this spec was eagerly awaited.

But for the most part, it’s time to sit back and enjoy the ability to represent information, process it, interchange it, with robustness and efficiency. There’s lots of opportunities to explore in making good, sensible use of XML technologies.

XML is everywhere.

Thank you to all who have contributed.

Liam Quin, leaving W3C this week after almost 17 years with XML.

Minutes Telecon 2018-07-25

Source: CSS WG BlogDael Jackson • 25 July 2018

Full Meeting Minutes

Minutes Telecon 2018-07-18

Source: CSS WG BlogDael Jackson • 19 July 2018

Full Meeting Minutes

Release Notes for Safari Technology Preview 61

Source: Surfin' Safari 18 July 2018

Safari Technology Preview Release 61 is now available for download for macOS High Sierra and the beta of macOS Mojave. If you already have Safari Technology Preview installed, you can update from the Mac App Store’s Updates tab on macOS High Sierra and in the Software Update pane of System Preferences on macOS Mojave. This release covers WebKit revisions 233256-233728.

CSS

Dark Mode

Web API

Service Workers

Media

WebRTC

Web Assembly

Web Inspector

Accessibility

Exploring CSS property definitions

Source: W3C Blog François Daoust • 16 July 2018

Reffy and CSS specifications

Reffy is a specification exploration tool that Dominique Hazaël-Massieux and I developed as a side project during W3C Geek Week a couple of years ago to explore cross-dependencies of JavaScript APIs specifications. Reffy crawls, parses, analyzes, and reports on potential anomalies that specifications may have. Reffy reports are published on a daily basis and help detect issues such as invalid WebIDL content or missing normative references. The dump of the WebIDL content defined in each specification is now also used to create WebIDL tests in the Web Platform Tests effort.

Reffy was essentially restricted to specifications that define some WebIDL content. For Geek Week this year, Dominique and I wondered whether we could extend Reffy to support CSS specifications:

  1. Could we extract all CSS property/descriptor definitions from specifications automatically?
  2. Could we create a useful syntax tree out of the CSS property/descriptor value definitions automatically?
  3. Would it reveal potential issues in CSS specs? Would it be useful to improve the quality of the specifications, to automate the creation of tests, or to create/maintain documentation?

Outcomes

We identified and added about 100 CSS specifications to the list of specifications crawled by Reffy, looking at specifications published as W3C Technical reports, as well as Editor’s Drafts from the CSS Working Group, the FX Task Force and the Houdini Task Force.

Reffy can now successfully extract all CSS property/descriptor definitions from these specifications (544 CSS properties as of today), and parse all value definitions that follow the Value Definition Syntax.

A number of issues have been raised against CSS specifications along the way (see CSS Value Definition Syntax issues for details), notably to report invalid value definitions per the syntax and editorial updates that would help automate the extraction and parsing of definitions. The Value Definition Syntax was most likely not created with automated parsing in mind. We could not spot places where definitions were really ambiguous for human beings, but the syntax could perhaps be improved to ease automated processing and prevent any misunderstanding.

Comparing the information we extracted with MDN data, we detected and reported some outdated info on MDN related to scroll-snap properties and offset-* properties.

Possible next steps

We will continue to investigate the integration with MDN data. That data is currently maintained manually by the community. The possibility to automate part of this process would improve accuracy.

We did not have enough time to run a deep analysis of the resulting syntax tree. Such an analysis might reveal further specification issues. On top of improving the quality of CSS specifications, it should be easy to create a CSS property explorer similar to WebIDLPedia (this one being restricted, as its name suggests, to the exploration of WebIDL used across specifications) out of the list of properties extracted.

In specifications that define JavaScript APIs, WebIDL definitions can be used to create interface tests automatically, using idlharness.js. Similar tests can probably be created for CSS. We confess being more familiar with JavaScript APIs though. It may be that parsing CSS is not a major source of interoperability issues. Would such tests be as useful as WebIDL ones?

The extraction and parsing currently only works for CSS properties and descriptors. It could be interesting to cover at-rules and selectors as well. This may be more challenging though, as actual prose seems to prevail in that area, with fewer parseable code definitions.

Updated CR of CSS Text Decoration Level 3

Source: CSS WG Blog fantasai • 04 July 2018

The CSS Working Group has published an updated Working Draft of CSS Text Decoration 3. This module contains the features of CSS relating to text decoration, such as underlines, text shadows, and emphasis marks.

This update closes out a variety of issues filed since the previous publication in 2013. See the Disposition of Comments. Significant changes since the last Candidate Recommendation 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-text-decor-3]) and your comment topic in the subject line. (Alternatively, you can email one of the editors and ask them to forward your comment.)

Release Notes for Safari Technology Preview 60

Source: Surfin' Safari 03 July 2018

Safari Technology Preview Release 60 is now available for download for macOS High Sierra and the beta of macOS Mojave. If you already have Safari Technology Preview installed, you can update from the Mac App Store’s Updates tab on macOS High Sierra and in the Software Update pane of System Preferences on macOS Mojave. This release covers WebKit revisions 232790-233256.

Known Issues

Web Animations

Dark Mode

Web Inspector

Media

CSS

WebRTC

Security

Plug-ins

Intelligent Tracking Prevention

WebDriver

Accessibility

Updated Candidate Recommendation: CSS Text Decoration Level …

Source: W3C's Cascading Style Sheets home page03 July 2018

3 Jul 2018 Updated Candidate Recommendation: CSS Text Decoration Level 3.

What’s new in Chromium 67 and Opera 54

Source: Dev.OperaFredrik Söderqvist • 28 June 2018

Opera 54 (based on Chromium 67) 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.

Generic Sensors

Sensor data is used in many native applications to enable experiences like immersive gaming, fitness tracking, and augmented or virtual reality. This data is now available to web applications using the Generic Sensor API. The Generic Sensors API provides a foundation for sensors in the form of a base Sensor interface and associated abstract operations. Concrete sensors are provided on top of this specification. The following are some of the concrete sensors:

Additional resources:

Other Features in this Release

SVG

SVG2 requires <foreignObject> to be a stacking context. Making <foreignObject> a stacking context means HTML content within a <foreignObject> will integrate better with other content.

DOM

DOMTokenList.replace() now returns a boolean value indicating if the replacement was successful or not. This allows code that for instance takes different paths depending on whether a replacement occurred, to avoid an extra condition using contains().

HTML > Custom Elements

Custom Elements can now extend HTML elements to inherit the semantics of native, built-in elements. This avoids reimplementing built-in functionality such as accessibility, semantics and JavaScript methods/properties.

Input

Mouse events (mousedown, auxclick, mouseup) will now be dispatched for back and forward buttons on mice with more than four buttons. This allows back and forward mouse buttons to be prevented by applications, such as games, that wish to override them.

On Windows the right-hand Alt key serves as AltGraph (ISO-Level-3-Shift) on some layouts, such as many European language layouts, to allow generating additional printable-characters. Internally the key generates Ctrl+Alt modifiers, so that Opera reports all of Control, Alt and AltGraph in the flags for these keys. In this change, Opera distinguishes AltGraph from Ctrl+Alt under Windows for consistency with these modifiers on other platforms.

For developers this removes an edge-case from keyboard event modifier handling. If an app handles keydown/keypress/keyup to implement shortcuts, it will no longer need workarounds to cope with certain (mainly European) keyboard layouts. For example, if an app uses Ctrl+# as a shortcut then previously the app would need to check for both Ctrl, and for AltGraph, otherwise French users would not be able to use it. This change applies to Windows only.

JavaScript

JavaScript now supports a numeric primitive for arbitrary precision integers. Previously, numbers in JavaScript were represented as double-precision floats, thus giving them limited precision. Using the BigInt() function and ‘n' suffix on numeric literals you can store and operate on large integers beyond the safe integer limit for numbers.

Layout

Formatting contexts will now behave exactly like floats do when they are positioned. In other words, they no longer consider the shape-outside property of the float when positioning is determined, and are instead positioned according to their margin box. The new behavior can be seen in this example by changing the height of the flex class. This also affects how new formatting contexts are sized and positioned.

Loading

Client Hints enable origins to receive device-specific preferences in the HTTP request headers. The Accept-CH-Lifetime header field adds a client hint that allows origins to persist their opt-in policy for a specified period so they can receive client hints on navigation requests. Additionally, on the first page load, this feature provides hints for all subresources of the page.

For more on Client Hints, see Automating Resource Selection with Client Hints by Ilya Grigorik.

Streams

Stream API support has been extended with TransformStream. Transform streams enable transforming data in stream form. It can for example be used to pipe between a ReadableStream and a WritableStream. The following example uses a TransformStream to decode text received in a streaming response body:

function textDecodeTransform() {
  const decoder = new TextDecoder();
  return new TransformStream({
      transform(chunk, controller) {
        controller.enqueue(decoder.decode(chunk, { stream: true }));
      }
  });
}

fetch(url).then(response => {
  // response.body is a stream of Uint8Array chunks.
  // But if we want chunks of text:
  const stream = response.body.pipeThrough(textDecodeTransform());
  // …
});

Shadow DOM

The <slot> element can now participate in a flat layout tree, with UA style display: contents. Before this change, a CSS selector would not match a <slot> element. Now selectors match and children will inherit from the <slot> element.

Deprecations and Interoperability Improvements

HTTP-Based Public Key Pinning is deprecated

HTTP-Based Public Key Pinning (HPKP) was intended to allow websites to send an HTTP header that pins one or more of the public keys present in the site’s certificate chain. It has very low adoption, and although it provides security against certificate misissuance, it also creates risks of denial of service and hostile pinning.

To defend against certificate misissuance, web developers should use the Expect-CT header, including its reporting function. Expect-CT is safer than HPKP due to the flexibility it gives site operators to recover from configuration errors, and due to the built-in support offered by a number of CAs.

We expect to remove this in Opera 56 (Chromium 69).

AppCache deprecated in Non-secure Contexts

AppCache over HTTP is deprecated. AppCache is a powerful feature that allows offline and persistent access to an origin. Allowing AppCache to be used over non-secure contexts makes it an attack vector for cross-site scripting hacks. Removal is expected in Opera 56 (Chromium 69).

Layout / CSS

Two Webkit-prefixed CSS properties were been removed in this release - -webkit-box-flex-group and -webkit-box-lines. Percent (%) values are no longer accepted by the -webkit-line-clamp property.

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.

Updated Working Draft: CSS Grid Layout Level 2.

Source: W3C's Cascading Style Sheets home page28 June 2018

28 Jun 2018 Updated Working Draft: CSS Grid Layout Level 2.

Minutes Telecon 2018-06-27

Source: CSS WG BlogDael Jackson • 27 June 2018

Full Meeting Minutes

Call for Participation: W3C Workshop on Digital Publication Layout and Presentation (from Manga to Magazines)

Source: W3C Blog Bill McCoy • 26 June 2018

The W3C announced today the latest in a series of workshops exploring the capabilities needed to ensure that the Web delivers on its full potential as a universal platform for digital publishing.

The upcoming technical workshop will be held September 18-19 in Tokyo, Japan. It will focus on evaluating the current status and exploring future directions of visually-rich long-form digital publications based on Web Technologies (particularly CSS, the formatting language of the Web), encompassing both fixed and dynamic layouts. Such “high-design” publications, with complex or sophisticated layout, may be sequential art (Comics, Manga, Bandes-Dessinées, etc.), magazines, picture books, cookbooks, educational materials, etc.

Anyone may request to attend at no charge and the W3C welcomes participation by both speakers and non-speaking attendees with relevant expertise. Early expression of interest in attending is encouraged due to limited space.

The workshop will emphasize the application of theory and technology to meet practical ecosystem needs.  Participants in the workshop will:

Attendees are expected to include:

The Call for Participation is now open.

This W3C Workshop will take place at Keio University’s historic Mita campus, hosted by Keio’s Advanced Publishing Laboratory.

Updated Candidate Recommendation: CSS Fonts Level 3.

Source: W3C's Cascading Style Sheets home page26 June 2018

26 Jun 2018 Updated Candidate Recommendation: CSS Fonts Level 3.

CSS Basic User Interface Module Level 3 reaches Recommendation

Source: CSS WG Blog Florian Rivoal • 21 June 2018

The CSS WG has published the CSS Basic User Interface Module Level 3 as a Recommendation.

This specification describes user interface related properties and values to style HTML and XML. 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: box-sizing, outline (and related longhand properties), resize, text-overflow, cursor, and caret-color.

There were a few editorial changes since publication as a Proposed Recommendation, listed in the Changes section. An Implementation Report is available.

Errata will be maintained as necessary. Further refinements or extensions on the topics covered by this specification continue in CSS Basic User Interface Module Level 4, except for the box-sizing property, which will be maintained in the CSS Intrinsic & Extrinsic Sizing Module Level 3.

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], [css-ui-4], or [css-sizing-3] as appropriate) and your comment topic in the subject line. (Alternatively, you can email one of the editors and ask them to forward your comment.)

Minutes Telecon 2018-06-20

Source: CSS WG BlogDael Jackson • 21 June 2018

Full Meeting Minutes

New Recommendation: CSS Basic User Interface Level 3.

Source: W3C's Cascading Style Sheets home page21 June 2018

21 Jun 2018 New Recommendation: CSS Basic User Interface Level 3.

Web Animations in WebKit

Source: Surfin' Safari20 June 2018

Over the last 8 months we have been working on adding support for Web Animations, a W3C standard offering Web developers a JavaScript API to create, query and controls animations. While there is work left to do to ship this experimental feature to the Web at large, we feel our implementation has matured enough that, with the release of Safari Technology Preview 59, we can turn Web Animations on by default for our Web developer audience.

An Animation API for the Web

Browser engines have supported various animation features for many years, CSS Transitions and CSS Animations being two widely-supported approaches to authoring efficient animations on the Web. While these features have proven popular, they become limited when developers try to integrate browser-implemented animations via JavaScript:

For instance, developers would have to resort to code such as this to slide an element 100 pixels to the right:

const element = document.getElementById("my-element");

// Set the start value and transition properties.
element.style.transform = "translateX(0)";
element.style.transitionProperty = "transform";
element.style.transitionDuration = "1s";

// Force a style invalidation.
window.getComputedStyle(element);

// Set the end value.
element.style.transform = "translateX(100px)";

This approach is not elegant as it forces a style invalidation that causes extra work rather than just letting the browser invalidate styles at the most appropriate time. And this is just one single transition, but what if another library in your webpage also needed to create a transition? This would multiply forced style invalidation for no good reason.

The value of Web Animations lies in having a JavaScript API that preserves the ability to let the browser engine do the heavy lifting of running animations efficiently while enabling more advanced control of your animations. Using Web Animations, we can rewrite the code above with a single method call:¬…

element.animate({ transform: ["translateX(0)", "translateX(100px)"] }, 1000);

A single method call and you’re done! But that’s not all, now you can harness the power of Web Animations with a full-featured API to control this animation:

// Obtain a reference to the animation we created above.
const animation = element.getAnimations()[0];
// Seek the animation to 500ms.
animation.currentTime = 500;
// Pause the animation.
animation.pause();

The Web Animations API is very powerful, for instance letting you get a list of all running animations on the document or an individual element, use promises to run code when an animation is ready to start or has completed, reverse an animation, etc.

Integration with CSS

The Web Animations specification goes further than specifying a JavaScript API. It provides a timing and animation model for web browsers to implement features such as CSS Transitions and CSS Animations. In fact, in WebKit, we’ve updated our implementation of these existing CSS technologies so that the same CSS Transitions and Animations you’ve been authoring for years are now represented as Web Animations objects in the browser. Using the getAnimations() method, you can obtain a reference to a CSSTransition or CSSAnimation object which are Animation subclasses. Then you can seek or pause a CSS transition running on an element just like we did above with an animation created using element.animate(). As a developer, you can think of CSS Transitions and Animations as a declarative layer above Web Animations.

Help Wanted

We’re very excited to be bringing the power of Web Animations to WebKit and enabling the technology in Safari Technology Preview 59. But there is still a fair bit of work ahead and we need your help to ensure we have a quality implementation before enabling the feature in Safari. We encourage you to try the new API and report issues that you find, bearing in mind that our current implementation is a bit behind the current state of the specification, and you can track all API changes with bug #186518.

It’s also important to check your existing content using CSS Transitions and Animations for possible regressions. One way to see if a regression you might be seeing is caused by the new Web Animations implementation, try toggling “Web Animations and CSS Integration” under the DevelopExperimental Features menu and see if your page’s behavior differs.

New Recommendation: CSS Color Level 3.

Source: W3C's Cascading Style Sheets home page19 June 2018

19 Jun 2018 New Recommendation: CSS Color Level 3.

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

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

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