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

Variable Fonts on the Web

Source: Surfin' Safari • Myles Maxfield • 03 November 2016

This year, at the ATypI typography conference in Warsaw, representatives from Adobe, Microsoft, Apple, and Google presented an exciting development in typography: support for variable fonts in OpenType fonts. Font variations are best shown with an example:

Here, you can see the weight of San Francisco being animated on iOS. As you can see, the weights are continuously interpolated, allowing for weights between the previously-available weights of this font. (You can try it here using Safari Technology Preview only on macOS Sierra.)

However, variations can do more than simply change the weight of a font. A font can expose any number of axes, each one controlling a different aspect of the font. The user (or browser) can select a floating-point value to apply to each axis, and each value will contribute to the font’s final look.

In addition to finer-grained control over the font’s look, a font variation can improve loading performance for a website if multiple faces of the same family are used. Currently, a website may load two weights of a font independently, which can lead to a significant amount of duplicated data. Instead, a website may choose to use a font variation and simply apply different variation values to the same font, thereby eliminating the duplicated data and only downloading a single font.

Font weight and width variations

Even with just two axes (weight and width), a single font can be used in a variety of typographical situations. Using the same font file repeatedly with different variations can dramatically decrease the loading time of a website. (This example can be seen here using Safari Technology Preview only on macOS Sierra.)

CSS

The W3C is currently drafting a way to describe variation axis values in CSS. The current draft divides axes into three groups: font selection, common, and other.

There are four CSS properties which affect which fonts are selected to be used in the document: font-weight, font-stretch, font-style, and font-size. With font variation support, each of these four properties will accept a numerical value which will both affect font selection as well as be applied to the font after it is selected. Therefore, a web site declaring font-weight: bold may cause a variable font to be selected, and then bold applied to that variable font. Naturally, CSS animations are supported in all these properties, because the values can be smoothly interpolated. These properties are expected to match the most common variation axes, so most CSS authors won’t need to learn any new properties.

font-weight: 791; /* Intermediate value between 700 and 800. */

Other than the above properties, any well-known or common variation axes will get their own CSS properties. Currently, there is only one axis in this group: optical-sizing. As new variation axes become popular, new properties will be added to control those axes.

Lastly, font creators may wish to include axes which are uncommon or not well known. In this situation, a web author should be able to set these axes without requiring the browser to implement new CSS properties. Therefore, the lowest-level font-variation-settings CSS property allows web authors to specify axis names as CSS values as well as their associated variation values. Similarly to the other properties, font-variation-settings also supports CSS animations. Because this property is only intended to be used as an escape hatch in case no higher-level property exists, it should only be used rarely, if ever.

font-variation-settings: "xhgt" 0.7;

Implementation

While the above announcement is regarding variation support in OpenType fonts, TrueType has had variation support for many years. In fact, all of the operating systems Apple ships currently include system APIs for TrueType font variations. Because of this, I have started implementing font variation support in WebKit in relation to the existing TrueType font support in the platform. Currently, I’ve only implemented the lowest-level font-variation-settings property, but I’m very excited to implement the complete support as soon as I’m able. Please try the existing support out in a Safari Technology Preview only on macOS Sierra and let me know how it works for you!

If you have any questions or comments, please contact me at @Litherum, or Jonathan Davis, Apple’s Web Technologies Evangelist, at @jonathandavis or [email protected].

Minutes Telecon 2016-11-02

Source: CSS WG Blog • Dael Jackson • 03 November 2016

Full Minutes

CSS Scroll Snap Candidate Rec Published

Source: CSS WG Blog • Tab Atkins Jr. • 02 November 2016

The CSS Working Group has published a Candidate Recommendation of CSS Scroll Snap. This module contains features to control panning and scrolling behavior with “snap positions”, to which the UA is biased to land after a scroll operation.

We expect some minor adjustments to be made to the module as we gather
implementation experience in the CR cycle, however the module should be
mostly stable now. Significant changes since the last Working Draft are listed in the Changes section and include renaming ‘scroll-snap-padding’ to ‘scroll-padding’ and expanding
its application to exclude the scroll padding area in other forms of scroll
position calculations, such as scrolling to a :target or using PageUp/Down
operations. (See https://www.w3.org/TR/css-scroll-snap-1/#scroll-padding for details.)

Please send feedback by filing an issue in GitHub (preferable) with the spec code ([css-scroll-snap]) 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 Candidate Rec Published

Source: CSS WG Blog • Tab Atkins Jr. • 02 November 2016

The CSS Working Group has published a Candidate Recommendation of CSS Grid. Grid 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 spec is the culmination of years of design. In 2005, Bert Bos published the first draft of Advanced Layout, containing the proto-forms of what would eventually become Grid and Flexbox (along with tabbed layout, which never became a thing). While this received occasional updates, the Grid part didn’t receive much implementor interest until 2011, when editors from Microsoft published the first draft of Grid Layout. This attracted the attention of fantasai and Tab, who’d always liked the very similar Template Layout proposal from Bert’s draft, and they gradually merged the two proposals into the Grid spec now being published. Yay for collaboration!

We expect some minor adjustments to be made to the module as we gather
implementation experience in the CR cycle, however the module should be
mostly stable now. Changes since the last Working Draft are listed in the Changes section.

Please send feedback by filing an issue in GitHub (preferable) with the spec code ([css-grid]) 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 2016-10-26

Source: CSS WG Blog • Dael Jackson • 27 October 2016

Full Minutes

Release Notes for Safari Technology Preview 16

Source: Surfin' Safari • Jon Davis • 25 October 2016

Safari Technology Preview Release 16 is now available for download for macOS Sierra. If you are using Safari Technology Preview on OS X El Capitan, update to macOS Sierra to ensure you continue to receive updates. If you already have Safari Technology Preview installed, you can update from the Mac App Store’s Updates tab. This release covers WebKit revisions 206808–207669.

URL Parser

Gamepad API

CSS

Media

Fetch API

JavaScript

Web APIs

Web Inspector

Accessibility

Shadow DOM

Bug Fixes

The CSS WG published the first Working Draft of CSS Table Mo…

Source: W3C's Cascading Style Sheets home page • 25 October 2016

25 Oct 2016 The CSS WG published the first Working Draft of CSS Table Module Level 3

What’s new in Chromium 54 and Opera 41

Source: Dev.Opera • Mathias Bynens • 25 October 2016

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

Web Components: Custom Elements v1

Custom elements form the foundation of web components. The initial version of the API, also known as Custom Elements v0, has been supported since Opera 20 & Chrome 33. With the v0 API, a new custom element was defined using document.registerElement().

Since then, the spec has been updated based on web developer and browser vendor feedback. The improved API is called Custom Elements v1. The new hip & trendy way of defining a custom element is through customElements.define(). The v0 API is now deprecated and will be removed in a future release.

For more details, check out Eric Bidelman’s custom elements guide.

DOM convenience methods on ParentNode & ChildNode

We now support the following convenience methods on ParentNode and ChildNode for working with DOM trees:

CanvasRenderingContext2D.prototype.imageSmoothingQuality

CanvasRenderingContext2D.prototype.imageSmoothingQuality allows developers to balance performance and image quality by adjusting resolution when scaling.

const canvas = document.querySelector('canvas');
const context = canvas.getContext('2d');
const image = new Image();
image.src = 'image.png';
image.onload = function() {
        context.imageSmoothingEnabled = true;
        context.imageSmoothingQuality = 'high'; // or 'low', or 'medium'
        context.drawImage(image, 0, 0, 320, 180);
};

BroadcastChannel API

The BroadcastChannel API allows same-origin scripts to send messages to other browsing contexts. It can be thought of as a simple message bus that allows publish-subscribe semantics between windows, tabs, iframes, web workers, and service workers. Think of it as a simpler, same-origin version of the good ol’ postMessage() API.

For more information, check out this article.

Cache Storage API: CacheQueryOptions

The full set of CacheQueryOptions is now supported, making it easier to find the cached responses you’re looking for. Here’s the complete list of available options:

See Jeff Posnick’s excellent article for more information.

CSS text-size-adjust

The text-size-adjust property lets web developers control and disable the text autosizing feature which increases font sizes on mobile.

Unprefixed CSS user-select

You can now use user-select instead of -webkit-user-select in CSS. The user-select property makes it possible to specify which elements in the document can be selected by the user and how.

Navigations initiated in an unload handler are now blocked. Instead, any prior navigation will continue. This matches the behavior in Firefox, and matches Edge’s behavior more closely than before.

Node.prototype.getRootNode

Sites can use Node.prototype.getRootNode(options) to obtain the root for a given node.

Experimenting with post-quantum crypto for TLS

CECPQ1 is a post-quantum cipher suite: one that is designed to provide confidentiality even against an attacker who possesses a large quantum computer. It is a key-agreement algorithm plugged into TLS that combines X25519 and NewHope, a ring-learning-with-errors primitive. Even if NewHope turns out to be breakable, the X25519 key-agreement will ensure that it provides at least the security of our existing connections.

Note that this is only an experiment. In fact, the plan is to discontinue this experiment within two years, hopefully by replacing it with something better. See “Experimenting with post-quantum cryptography” for more details.

Deprecated and removed features

URL.createObjectURL and URL.revokeObjectURL are now deprecated in service worker contexts.

The MediaStream API dropped MediaStream.prototype.ended a long time ago. Its usage has been deprecated since Opera 32 & Chromium 45. As of this release, the ended event is no longer supported.

Similarly, the File API spec once removed the FileError interface. It has been deprecated since 2013. Any usage of FileError triggered a warning in the DevTools console since Opera 40 & Chromium 53. As of this release, FileError is no longer supported.

Support for the non-standard TouchEvent.prototype.initTouchEvent has been removed, after being deprecated since Opera 36 & Chromium 49. Use the Touch and TouchEvent constructors instead.

To more closely match other browser’s behavior, window.external.IsSearchProviderInstalled and window.external.AddSearchProvider (originally intended to add search engines programmatically) are now both no-ops. This functionality was never implemented in Safari. In IE10, these methods are (mostly) no-ops: IsSearchProviderInstalled always returns 2, and AddSearchProvider always returns S_OK. Firefox still implements this, but notes that it may be removed at any time.

KeyboardEvent.prototype.keyIdentifier has been removed. Use KeyboardEvent.prototype.key (or its polyfill) instead.

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.

Idea of the Week: Web Directions Alumni

Source: Web Directions Blog • Ricky Onsman • 24 October 2016

Those of you who have seen the Scroll Magazine we produced for our Code 16 conference (and if you haven’t, you should) will have noticed that we published a list of all our speakers and their topics at previous Code conferences.

That resulted in a list of 80+ presentations and a bit of a who’s who of web coding, programming, engineering over the preceding five years. We’ve reproduced the list below.

Now, when it came to Direction 16, we had to decide how we would handle this idea, if at all.

Long story short, we decided we would do it, so the Direction 16 edition of Scroll has a pretty amazing list of over 300 presentations from 2006 to 2015, but this time sorted in alphabetical order of speaker name so it’s easy to see who has addressed the conference more than once.

As a point of curiosity, there’s just one speaker who has given five talks at Web Directions during that period. Care to guess?

In any case, have a browse of our previous Code speakers below and make sure you get a copy of the Direction 16 edition of Scroll – all conference and workshop attendees receive a free print edition (88 bound pages of articles and interviews with full colour photos and illustrations) while it will also be available for digital download post-conference.

 

Speaker Name (Year) Topic

Alex Russell (2015) What comes next for the Web Platform?

Rachel Nabors (2015) State of the Animation

Alex Sexton (2015) Current best practice in front end ops

Clark Pan (2015) ES6 Symbols, what they are and how to use them

Ben Teese (2015) A Deep-Dive into ES6 Promises

James Hunter (2015) Async and await

Alex Mackey (2015) JavaScript numbers

Andy Sharman (2015) Classing up ES6

Jess Telford (2015) Scope Chains & Closures

Kassandra Perch (2015) Stop the Fanaticism – using the right tools for the job

Mark Nottingham (2015) What does HTTP/2 mean for Front End Engineers?

Mark Dalgleish (2015) Dawn of the Progressive Single Page App

Elijah Manor (2015) Eliminate JavaScript Code Smells

Domenic Denicola (2015) Async Frontiers in JavaScript

Chris Roberts (2015) Getting offline with the Service Worker

Simon Knox (2015) Crossing the Streams

Jonathon Creenaune (2015) Back to the future with Web Components

Rhiana Heath (2015) Pop-up Accessibility

Warwick Cox (2015) Console dot

Simon Swain (2015) Canvas Cold War

Raquel Vélez (2014) You can do what with math now?

Alex Feyerke (2014) Offline First: faster, more robust and more fun (web) pages

Ryan Seddon (2014) Web Components: the future of web dev

Rod Vagg (2014) Embrace the asynchronous

Fiona Chan (2014) The declarative power of CSS selectors

Ben Birch (2014) When all you have is a hammer, every problem looks like a nail

Ben Schwarz (2014) CSS Variables

Mark Dalgleish (2014) Taking JavaScript out of context

Rob Manson (2014) The Augmented Web is now a reality

Damon Oehlman (2014) Streaming the Web (it’s not what you think)

Barbara Bermes (2014) A publisher’s take on controlling 3rd party scripts

Paul Theriault (2014) Taking front-end security seriously

Jared Wyles (2014) On readable code

Mark Nottingham (2014) What’s happening in TLS (transport layer security)?

Andrew Fisher (2014) A Device API Safari

Alex Mackey (2014) Harden up for ajax!

Allen Wirfs-Brock (2014) ECMAScript 6: A Better JavaScript for the Ambient Web Era

Tantek Çelik (2014) The once and future IndieWeb

Dmitry Baranovskiy (2014) You Don’t Know SVG

Angus Croll (2013) The politics of JavaScript

Jeremy Ashkenas (2013) Taking JavaScript seriously with backbone.js

Alex Danilo (2013) Create impact with CSS Filters

Julio Cesar Ody (2013) What’s ECMAScript 6 good for?

Glen Maddern (2013) JavaScript’s slightly stricter mode

Nicole Sullivan (2013) The Top 5 performance shenanigans of CSS preprocessors

Tony Milne (2013) Making and keeping promises in JavaScript

Cameron McCormack (2013) File > Open: An introduction to the File API

Silvia Pfeiffer (2013) HTML5 multi-party video conferencing

Elle Meredith (2013) Source Maps for Debugging

Jared Wyles (2013) See the tries for the trees

Garann Means (2013) HTML, CSS and the Client-Side App

Michael Mahemoff (2013) What every web developer should know about REST

Mark Nottingham (2013) HTTP/2.0: WTF?

Ryan Seddon (2013) Ghost in the Shadow DOM

Troy Hunt (2013) Essential security practices for protecting your modern web services

Marc Fasel (2013) Put on your asynchronous hat and node

Alex Mackey (2013) Typescript and terminators

Aaron Powell (2013) IndexedDB, A database in our browser

Andrew Fisher (2013) The wonderful-amazing-orientation-motion-sensormatic machine

Chris Ward (2013) Test, tweak and debug your mobile web apps with ease

Steven Wittens (2013) Making things with maths

Faruk Ates (2012) The Web’s Third Decade

Divya Manian (2012) Designing in the browser

John Allsopp (2012) Getting off(line): appcache, localStorage and more for faster apps that work offline

Dave Johnson (2012) Device APIs-closing the gap between native and web

Damon Oehlman (2012) HTML5 Messaging

Silvia Pfeiffer (2012) Implementing Video Conferencing in HTML5

Max Wheeler (2012) Drag and Drop and give me twenty

Anson Parker (2012) The HTML5 History API: PushState or bust!

Tammy Butow (2012) Fantastic forms for mobile web

Andrew Fisher (2012) Getting all touchy feely with the mobile web

Rob Hawkes (2012) HTML5 technologies and game development

Jed Schmidt (2012) NPM: Node’s Personal Manservant

Dmitry Baranovskiy (2012) JavaScript: enter the dragon

Anette Bergo (2012) Truthiness, falsiness and other JavaScript gotchas

Ryan Seddon (2012) Debugging secrets for the lazy developer

Jared Wyles (2012) Removing the dad from your browser

Mark Dalgleish (2012) Getting Closure

Tony Milne (2012) Party like it’s 1999, write JavaScript like it’s (2012)!

Tim Oxley (2012) Clientside templates for reactive UI

Damon Oehlman (2012) The mainevent: Beyond event listeners

Dave Johnson (2012) Building Native Mobile Apps with PhoneGap and HTML5

The post Idea of the Week: Web Directions Alumni appeared first on Web Directions.

Minutes Telecon 2016-10-19

Source: CSS WG Blog • Dael Jackson • 20 October 2016

Full Minutes

The CSS WG published a Candidate Recommendation of CSS Scrol…

Source: W3C's Cascading Style Sheets home page • 20 October 2016

20 Oct 2016 The CSS WG published a Candidate Recommendation of CSS Scroll Snap Module Level 1

AI Internet Solutions released version 16 of CSE HTML Valida…

Source: W3C's Cascading Style Sheets home page • 18 October 2016

18 Oct 2016 AI Internet Solutions released version 16 of CSE HTML Validator, an HTML editor that validates HTML, CSS and/or PHP code, with integrated syntax checker, spell checker, link checker, accessibility checker, SEO and more. (Windows, free ‘Lite’ version, Standard/Pro/Enterprise versions with free trial)

Minutes Telecon 2016-10-12

Source: CSS WG Blog • Dael Jackson • 13 October 2016

Full Minutes

Release Notes for Safari Technology Preview 12

Source: Surfin' Safari • Jon Davis • 11 October 2016

Safari Technology Preview Release 12 is now available for download for both macOS Sierra betas and OS X El Capitan. If you already have Safari Technology Preview installed, you can update from the Mac App Store’s Updates tab. This release covers WebKit revisions 204289–204876.

This release of Safari Technology Preview will be the last that will install and run on OS X El Capitan 10.11.4 and 10.11.5. To continue testing or living on the latest enhancements to WebKit, please upgrade to OS X El Capitan 10.11.6 or the macOS Sierra betas.

JavaScript

Web APIs

Web Inspector

MathML

CSS

Rendering

Accessibility

Security

Release Notes for Safari Technology Preview 13

Source: Surfin' Safari • Jon Davis • 11 October 2016

Safari Technology Preview Release 13 is now available for download for both macOS Sierra betas and OS X El Capitan 10.11.6. If you already have Safari Technology Preview installed, you can update from the Mac App Store’s Updates tab. This release covers WebKit revisions 204876–205519.

Fetch API

Custom Elements

JavaScript

Web APIs

Web Inspector

CSS

Rendering

Security

Plugins

Release Notes for Safari Technology Preview 14

Source: Surfin' Safari • Jon Davis • 11 October 2016

Safari Technology Preview Release 14 is now available for download for both macOS Sierra and OS X El Capitan 10.11.6. If you already have Safari Technology Preview installed, you can update from the Mac App Store’s Updates tab. This release covers WebKit revisions 205519–206196.

This release of Safari Technology Preview will be one of the last that will install and run on OS X El Capitan. To continue testing or living on the latest enhancements to Safari and WebKit, please upgrade to macOS Sierra in the next few weeks.

Safari Extensions

Custom Elements

Fetch API

JavaScript

Web APIs

Apple Pay

Web Inspector

Rendering

WebDriver

Starting in Release 14, Safari Technology Preview now includes regular updates and bug fixes to Safari’s WebDriver implementation. You can run your WebDriver tests with the updated driver by using the safaridriver executable that is included in the Safari Technology Preview application bundle. By default, this is located at: /Applications/Safari Technology Preview.app/Contents/MacOS/safaridriver. The driver executable located at /usr/bin/safaridriver will continue to launch Safari 10 on macOS Sierra and OS X El Capitan.

For more information about using WebDriver with Safari, check out the blog post WebDriver Support in Safari 10.

Release Notes for Safari Technology Preview 15

Source: Surfin' Safari • Timothy Hatcher • 11 October 2016

Safari Technology Preview Release 15 is now available for download for both macOS Sierra and OS X El Capitan 10.11.6. If you already have Safari Technology Preview installed, you can update from the Mac App Store’s Updates tab. This release covers WebKit revisions 206196–206808.

This is the last release of Safari Technology Preview that will install and run on OS X El Capitan. To continue testing or living on the latest enhancements to Safari and WebKit, please upgrade to macOS Sierra.

Fetch API

JavaScript

CSS

Web APIs

Web Inspector

Media

Accessibility

URL Handling

Security

Safari Extensions

We have to talk about JavaScript

Source: Web Directions Blog • John • 10 October 2016

It seems that almost weekly concerns about the complexity of the ecosystem around JavaScript, build tools and frameworks bubble over. Certainly, the JavaScript and Front End development world is a lot more complex than even a few years ago.  

The latest round kicked off with Jose Aguinaga musing on “How it feels to learn JavaScript in 2016“. Depending on your feelings about the state of JavaScript in 2016, it’s inflammatory, amusing, or depressing. But it certainly started some conversations.

Recent Code speaker Tim Kadlec responded, or at least took this piece as a starting point for some less satirical thoughts about the place of tooling in the Front End Engineering world:

Mostly, I think the evolution is healthy. We should be iterating and improving on what we know. And each build tool does things a little differently and different people will find one or the other fits their workflow a bit better. The problem is if we blindly race after the next great thing without stopping to consider the underlying problem that actually needs solving.

Tim provides a framework for thinking about whether and how to use a particular tool. I won’t quote any of it, I simply recommend you go read it.

But it isn’t just Tim who responded. One of the folks I admire most in our field (who’s also responsible for many of the tools we use, the over reliance on which I’ve been critical of at times) is Addy Osmani, who observes

I encourage folks to adopt this approach to keeping up with the JavaScript ecosystem: first do it, then do it right, then do it better.

Most acerbically, long time contributor to the Web PPK of Quirksblog fame more bluntly observed about Tim’s comment that “it’s not the ecosystem that’s the problem”,

I disagree. I think the problem is in fact the ecosystem — by which I not only mean the combined toolsets and the expectations they set, but also the web development community as a whole.

Again, it’s worth reading, because it challenges us to question a lot of assumptions about how we do things. He also references a related piece by Bastian Allgeier, who observes:

in the end it’s all about what works for you. What is the best, fastest and most stable tool to transfer your ideas from your brain, via your fingers, into your keyboard and finally into your computer?

To which PPK responds:

I disagree. It’s not about what works for you. It’s about what works for your users.

With which, I most definitely agree.

On this topic I honestly recommend you drop everything and go and watch Rich Hickey, the inventor of Closure, on Easy versus Simple. I based my Full Frontal presentation from 2012 on his ideas and I think there’s tremendous value in considering his thesis that what is easy for us as developers often gives rise to complex code bases that are difficult to maintain, and with attendant security and performance implications. 

My take on all this?
I’m on the record as being pretty old fashioned about software engineering and the Web (I still, for the most part, stand by the above-mentioned presentation from Full Frontal in 2012). At our Code conference a couple of months back, I tried to tease apart some of these issues with not one but two round table discussions (one in each of Sydney and Melbourne) about how we should be architecting and engineering things for the Web.

Sadly (and as the moderator I’ll take responsibility for this), the conversation sort of went around and around two “strange attractors”. There were those who fell into the JavaScript/React camp, and those more traditional developers who think in terms of the traditional layered (HTML/CSS/JavaScript) architecture.

There are really smart people I admire who build complex applications on the Web platform and who, in all honesty, know a lot more about this in a practical sense than me, who will argue very strongly that the sorts of things they are building simply aren’t feasible, or at the very least, would take a great deal more work and time to build, using the more traditional approach.

And I’m in no position to disagree with them. I simply don’t build things like that, and have no data points other than their – respected – position.

But, what I think we often miss is that not everything on the Web is like that. Or if it is, it often shouldn’t be – time and again, things that could be plain old web sites use complex JavaScript approaches for reasons I simply cannot fathom.

So, where does all this leave us? I know it sounds like a cliché, and I feel I’m repeating myself until I’m blue in the face (Tim Kadlec, too, makes the observation in the article I referenced above, as does Addy Osmani), but foundations matter.

Understanding core technologies like CSS (many of the criticisms of CSS are really a reflection of the misunderstanding of the technology by the critic) and even HTML (it can do a lot of heavy lifting around accessibility, and just plain old better user experiences), as well as JavaScript, and the DOM.

These really are the foundations for everything that sits on top – whether it’s a framework, build tool or CSS pre- or post-processor (if you don’t understand CSS well enough to understand what your pre-processor is reducing, is it good engineering practice to even use it? Then again, most software engineers have long since lost the capability to understand the machine code produced by compilers. But I’m not sure the analogy holds). 

My intuition is that there are likely differing kinds of architecture appropriate for different kinds of things we’re building on the Web platform. As yet, our understanding of what these kinds of things are is relatively nascent – we have things we call apps, and things we call pages – and I suspect over time these high level patterns will more clearly emerge, and with them a better understanding of the appropriate architectures and tooling.

What’s certainly beyond doubt is that we’re building very complex, sophisticated and often important things on the Web, and yet the Web as a platform, and its enabling technologies like HTML, CSS, JavaScript and the DOM, are still often perceived by those in the computing fields as they were two decades ago: as “toys”– anaemic and under-powered.

Above all, I find these conversations, while sometimes tiring, also very valuable – they’re evidence of our capacity to critically appraise what we do, and how we do it. What’s certain is our field is not static. And while that provides challenges, it’s better than the alternative.

So softness and tenderness are attributes of life,
And hardness and stiffness, attributes of death.

The GNL Tao Te Ching, ©Peter A. Merel

 

directionad

Want more?

Like to see and read more like this? Be the first to score invitations to our events? Then jump on our once-a-week mailing list where we round up the week’s best reading and watching on all things Web. And you’ll get a complimentary digital copy of our brand new magazine, Scroll.


The post We have to talk about JavaScript appeared first on Web Directions.

Minutes Telecon 2016-10-05

Source: CSS WG Blog • Dael Jackson • 05 October 2016

Full Minutes

WebDriver Support in Safari 10

Source: Surfin' Safari • Brian Burg • 03 October 2016

As web content has become increasingly interactive, responsive, and complicated, ensuring a good user experience across multiple platforms and browsers is a huge challenge for web developers and QA organizations. Not only must web content be loaded, executed, and rendered correctly, but a user must be able to interact with the content as intended, no matter the browser, platform, hardware, screen size, or other conditions. If your shopping cart application has a clean layout and beautiful typography, but the checkout button doesn’t work because of a configuration mishap in production—or an incorrect CSS rule hides the checkout button in landscape mode—then your users are not going to have a great experience.

Ensuring a good user experience via automation is difficult in part because each browser has its own way of interpreting keyboard and mouse inputs, performing navigations, organizing windows and tabs, and so on. Of course, a human could manually test every interaction and workflow of their website on every browser prior to deploying an update to production, but this is slow, costly, and impractical for all but the largest companies. The Selenium open source project was created to address this gap in automation capabilities for browsers by providing a common API for automation. WebDriver is Selenium’s cross-platform, cross-browser automation API. Using WebDriver, a developer can write an automated test that exercises their web content, and run the test against any browser with a WebDriver-compliant driver.

Safari + WebDriver

I am thrilled to announce that Safari now provides native support for the WebDriver API. Starting with Safari 10 on OS X El Capitan and macOS Sierra, Safari comes bundled with a new driver implementation that’s maintained by the Web Developer Experience team at Apple. Safari’s driver is launchable via the /usr/bin/safaridriver executable, and most client libraries provided by Selenium will automatically launch the driver this way without further configuration.

I’ll first introduce WebDriver by example and explain a little bit about how it’s implemented and how to use Safari’s new driver implementation. I will introduce some important safeguards that are unique to Safari’s driver implementation, and discuss how these may affect you when retargeting an existing WebDriver test suite to run using Safari’s driver.

WebDriver By Example

WebDriver is a browser automation API that enables people to write automated tests of their web content using Python, Java, PHP, JavaScript, or any other language with a library that understands the de facto Selenium Wire Protocol or upcoming W3C WebDriver protocol.

Below is a WebDriver test suite for the WebKit feature status page written in Python. The first test case searches the feature status page for “CSS” and ensures that at least one result appears. The second test case counts the number of visible results when various filters are applied to make sure that each result shows up in at most one filter. Note that in the Python WebDriver library each method call synchronously blocks until the operation completes (such as navigating or executing JavaScript), but some client libraries provide a more asynchronous API.

from selenium.webdriver.common.by import By
from selenium import webdriver
import unittest

class WebKitFeatureStatusTest(unittest.TestCase):

def test_feature_status_page_search(self):
self.driver.get("https://webkit.org/status/")

# Enter "CSS" into the search box.
search_box = self.driver.find_element_by_id("search")
search_box.send_keys("CSS")
value = search_box.get_attribute("value")
self.assertTrue(len(value) > 0)
search_box.submit()

# Count the results.
feature_count = self.shown_feature_count()
self.assertTrue(len(feature_count) > 0)

def test_feature_status_page_filters(self):
self.driver.get("https://webkit.org/status/")

filters = self.driver.find_element(By.CSS_SELECTOR, "ul#status-filters li input[type=checkbox]")
self.assertTrue(len(filters) is 7)

# Make sure every filter is turned off.
for checked_filter in filter(lambda f: f.is_selected(), filters):
checked_filter.click()

# Count up the number of items shown when each filter is checked.
unfiltered_count = self.shown_feature_count()
running_count = 0
for filt in filters:
filt.click()
self.assertTrue(filt.is_selected())
running_count += self.shown_feature_count()
filt.click()

self.assertTrue(running_count is unfiltered_count)

def shown_feature_count(self):
return len(self.driver.execute_script("return document.querySelectorAll('li.feature:not(.is-hidden)')"))

def setup_module(module):
WebKitFeatureStatusTest.driver = webdriver.Safari()

def teardown_module(module):
WebKitFeatureStatusTest.driver.quit()

if __name__ == '__main__':
unittest.main()

Note that this code example is for illustration purposes only. This test is contemporaneous with a specific version of the Feature Status page and uses page-specific DOM classes and selectors. So, it may or may not work on later versions of the Feature Status page. As with any test, it may need to be modified to work with later versions of the software it tests.

WebDriver Under the Hood

WebDriver is specified in terms of a REST API; Safari’s driver provides its own local web server that accepts REST-style HTTP requests. Under the hood, the Python Selenium library translates each method call on self.driver into a REST API command and sends the corresponding HTTP request to local web server hosted by Safari’s driver. The driver validates the contents of the request and forwards the command to the appropriate browser instance. Typically, the low-level details of performing most of these commands are delegated to WebAutomationSession and related classes in WebKit’s UIProcess and WebProcess layers. When a command has finished executing, the driver finally sends an HTTP response for the REST API command. The Python client library interprets the HTTP response and returns the result back to the test code.

Running the Example in Safari

To run this WebDriver test using Safari, first you need to grab a recent release of the Selenium open source project. Selenium’s Java and Python client libraries offer support for Safari’s native driver implementation starting in the 3.0.0-beta1 release. Note that the Apple-developed driver is unrelated to the legacy SafariDriver mentioned in the Selenium project. The old SafariDriver implementation is no longer maintained and should not be used. You do not need to download anything besides Safari 10 to get the Apple-developed driver.

Once you have obtained, installed, and configured the test to use the correct Selenium library version, you need to configure Safari to allow automation. As a feature intended for developers, Safari’s WebDriver support is turned off by default. To turn on WebDriver support, do the following:

Once you have enabled Remote Automation, copy and save the test as test_webkit.py. Then run the following:

python test_webkit.py

Safari-exclusive Safeguards

While it’s awesome to be able to write automated tests that run in Safari, a REST API for browser automation introduces a potential vector for malicious software. To support a valuable automation API without sacrificing a user’s privacy or security, Safari’s driver implementation introduces extra safeguards that no other browser or driver has implemented to date. These safeguards also double as extra insurance against “flaky tests” by providing enhanced test isolation. Some of these safeguards are described below.

When running a WebDriver test in Safari, test execution is confined to special Automation windows that are isolated from normal browsing windows, user settings, and preferences. Automation windows are easy to recognize by their orange Smart Search field. Similar to browsing in a Private Browsing window, WebDriver tests that run in an Automation window always start from a clean slate and cannot access Safari’s normal browsing history, AutoFill data, or other sensitive information. Aside from the obvious privacy benefits, this restriction also helps to ensure that tests are not affected by a previous test session’s persistent state such as local storage or cookies.

The Smart Search field in Automation windows is bright orange to warn users that the window is not meant for normal browsing.

As a WebDriver test is executing in an Automation window, any attempts to interact with the window or web content could derail the test by unexpectedly changing the state of the page. To prevent this from happening, Safari installs a “glass pane” over the Automation window while the test is running. This blocks any stray interactions (mouse, keyboard, resizing, and so on) from affecting the Automation window. If a running test gets stuck or fails, it’s possible to interrupt the running test by “breaking” the glass pane. When an automation session is interrupted, the test’s connection to the browser is permanently severed and the automation window remains open until closed manually.

If a user interacts with an active Automation Window, a dialog will appear that allows the user to end the automation session and interact with the test page.

Along with being able to interact with a stopped test, Safari’s driver implementation also allows for the full use of Web Inspector during and after the execution of a WebDriver test. This is very useful when trying to figure out why a test has hung or is providing unexpected results. safaridriver supports two special WebDriver capabilities just for debugging. The automaticInspection capability will preload the Web Inspector and JavaScript debugger in the background; to pause test execution and bring up Web Inspector’s Debugger tab, you can simply evaluate a debugger; statement in the test page. The automaticProfiling capability will preload the Web Inspector and start a timeline recording in the background; if you later want to see details of what happened during the test, you can open the Timelines tab in Web Inspector to see the captured timeline recording in its entirety.

Safari’s driver restricts the number of active WebDriver sessions. Only one Safari browser instance can be running at any given time, and only one WebDriver session can be attached to the browser instance at a time. This ensures that the user behavior being simulated (mouse, keyboard, touch, etc.) closely matches what a user can actually perform with real hardware in the macOS windowing environment. For example, the system’s text insertion caret can only be active in one window and form control at a time; if Safari’s driver were to allow multiple tests to run concurrently in separate windows or browsers, the text insertion behavior (and resulting DOM focus/blur events) would not be representative of what a user could perform themselves.

Summary

With the introduction of native WebDriver support in Safari 10, it’s now possible to run the same automated tests of web content on all major browsers equally, without writing any browser-specific code. I hope WebDriver support will help web developers  catch user-visible regressions in their web content much more quickly and with less manual testing. Safari’s support comes with new, exclusive safeguards to simultaneously protect user security and privacy and also help you write more stable and consistent tests. You can try out Safari’s WebDriver support today by installing a beta of macOS Sierra or Safari 10.

This is our first implementation of WebDriver for Safari. If you encounter unexpected behavior in Safari’s WebDriver support, or have other suggestions for improvement, please file a bug at https://bugreport.apple.com/. For quick questions or feedback, email [email protected] or tweet @webkit or @brrian on Twitter. Happy testing!

Addendum

After this post was published, we received a lot of useful feedback from users. This section contains information on some common problems and how to work around them.

safaridriver quits immediately after launch when running Safari 10 on El Capitan

Some users reported that they could not get safaridriver to run correctly after installing Safari 10 on El Capitan. The main symptom of this issue is that safaridriver will quit immediately when launched manually via the command line. This happens because a launchd plist used by safaridriver is not automatically loaded. Here’s the workaround:

# Check the status of the com.apple.webdriverd launchd plist:
launchctl list | grep webdriverd

# If it's not loaded, use this command to load the launchd plist:
launchctl load /System/Library/LaunchAgents/com.apple.webdriverd.plist

This issue only manifests on El Capitan when installing a newer Safari through an application update instead of an OS update. Users running safaridriver on macOS Sierra should be unaffected.

The CSS WG published a Candidate Recommendation of CSS Grid …

Source: W3C's Cascading Style Sheets home page • 29 September 2016

29 Sep 2016 The CSS WG published a Candidate Recommendation of CSS Grid Layout Module Level 1 and updated the Candidate Recommendation of CSS Values and Units Module Level 3

Idea of the Week: Progressive Web Apps

Source: Web Directions Blog • John • 26 September 2016

At our Code 2016 conference a couple of months ago, Progressive Web Apps received quite a bit of attention. Marcos Caceres talked about how they are enabled by Service Workers, Elise Chant showed us how to use Manifests to install them, and several presenters referred to PWA in their presentations.

You might remember that PWAs were introduced as a concept by Alex Russell back at Web Directions 2015, so we figured it would be a good idea to use Scroll Magazine to put Progressive Web Apps in perspective.

Progressive Web Apps for everyone

By John Allsopp

The launch of the iPhone in 2007 was a watershed moment in modern technology, for all manner of reasons, but I want to focus on one particular aspect: its impact on the Web.

Back in the 1990s, those of us thinking about the future of Web design were already imagining a genuinely mobile Web. No small part of the impetus behind CSS, and the then radical “standards based” approach to Web development, revolved around the realisation that the Web wasn’t going to be desktop-only for ever (even if, at the time, laptop computers were rare and expensive, wi-fi non-existent, and accessing even email via a mobile phone was considered Jetsons-like futuristic).

The iPhone changed all that, despite in many ways being worse than the phones that came before it: slower CPUs, slower networks (2G only!), no physical keyboard. And as hard as it is to imagine now, it had no apps.

So, why did it succeed? My largely-impossible-to-verify speculation is that it was in no small part because it was the first genuinely usable mobile Web experience, and this set it apart from all other mobile devices at the time.

Almost no-one before had even tried – let alone come close to – making the mobile Web experience not totally suck. Apple did an end-run around these previous efforts. Controversially (among the handful of people aware of CSS media types at the time) it didn’t support the mobile media type in CSS, choosing rather to present the full web page, rendered into a theoretical 960px wide window and scaling the page to fit the ‘real’ viewport width of 320px.

I’d argue that the Web was critically important to the success of the iPhone, and the relationship between the two over the intervening nine years is instructive, and might point to the future of the Web.

That future looked, for many, kind of shaky not all that long ago. Indeed, some like Alex Russell – to whom we’ll return in a moment – argue that now is very much a watershed moment in the Web’s history. Apple’s interest in moving the Web forward, highly evident in the period between 2003 and around 2009 as they released a brand new best-of-breed browser – Safari – implemented then proposed as standards many of the features we now take for granted in modern web design (CSS animations, transitions, transforms, gradients, Web Fonts among many others), has slowed to a trickle.

Apple took years to adopt IndexedDB, among many other important Web technologies, and while all other browsers adopted an “evergreen” approach of continual improvement and automatic updating of both desktop and mobile browsers, Apple seemed stuck on an upgrade cycle for their browsers which marched in lock step with their Operating Systems, and ran in the order of years not weeks.

As the iOS App Store added more and more apps – they now number in the millions – the Web seemed less and less important to Apple (the same is not untrue of Android, too) and, indeed, to the future of computing. Web Apps were widely considered slow and ‘janky’, and lacked access to many of the device capabilities native apps could tap into that made Web content look endangered in the world of shiny 60FPS apps, with their access to the underlying device APIs and features, and – importantly – ability to be easily installed on the user’s home screen.

Meanwhile, Android is also an important part of this story. Coming from a company whose DNA was the Web, hope might have been had that Android would pick up the mantle, and make the Web a first class citizen. But Android increasingly went toe-to-toe with iPhone and the stock Android browser became increasingly outdated, even as Google was instrumental in moving the Web forward through Chrome.

Usage rates for the Web in comparison with native mobile apps fell, the importance of mobile computing rose and Wired famously declared the Web to be dead.

But. A funny thing happened on the way to the funeral.

All along, Google had been acquiring a team of smart, deeply experienced Web-native people, people who cared deeply about the Web, people exemplified by (although he’s far from alone) Alex Russell. Alex, who helped give the world Dojo, one of the earliest richly featured JavaScript frameworks, and ChromeFrame, an ingenious approach to getting a modern Web rendering engine into older Internet Explorer versions using ActiveX.

Folks like Alex, and Domenic Denicola, and many others at Google never lost faith in the Web.

Along with others at browser vendors like Mozilla and Opera and framework developers like Ember and elsewhere, these folks thought long and hard about what worked and what didn’t when it comes to moving the Web platform forward in an age of sophisticated native platforms like iOS and Android. They gathered and published their thoughts in the ‘Extensible Web Manifesto’. And over the last 12 months or so we’ve really started to see the fruits of this way of thinking, under the moniker of “Progressive Web Apps”.

Alex kicked this phase off when he published “Progressive Web Apps, escaping tabs without losing our soul“, and a few weeks later we were fortunate to have him open our Code 2015 conference with a keynote that expanded on these ideas.

The last 12 months has really seen these ideas start to become very much part of the everyday life of front end developers. Service worker is reaching a level of maturity in Chrome, and increasingly Mozilla, has strong interest from the Edge team at Microsoft, and even cautious public interest from the Webkit team. Other pieces of the puzzle, including push notifications, and Web Manifests (not to be confused with AppCache!) are becoming usable. And more importantly still, a pattern for developing Web apps that are progressive, that start life in the browser tab, and potentially migrate onto the user’s home screen has emerged.

Suddenly, I feel a renewed optimism for the Web, not simply that it can keep up with or compete with native, but that it can continue to embody the “webbiness” central to its success and importance.

The technologies that enable this new approach to Web development are maturing, and the philosophies and users’ mental models are still emerging, but it is a time of tremendous opportunity and promise. If you’re not already exploring Web Manifests, Service Workers, and Push notifications, these are low barrier to entry technologies that can be used to progressively improve your sites and apps today, even as we wait for their full adoption.

These are exciting times, full of promise and opportunity, and they don’t come around very often.

The emergence of CSS in the late 1990s, Ajax, jQuery and a more application-like Web experience in the early 2000s, mobile in the late part of the 2000s – just a small number of similar revolutionary shifts come to mind.

Don’t waste this opportunity.

directionad

Want more?

Like to see and read more like this? Be the first to score invitations to our events? Then jump on our once-a-week mailing list where we round up the week’s best reading and watching on all things Web. And you’ll get a complimentary digital copy of our brand new magazine, Scroll.


The post Idea of the Week: Progressive Web Apps appeared first on Web Directions.

MotionMark:A New Graphics Benchmark

Source: Surfin' Safari • Jon Lee • 21 September 2016

Co-written with Said Abou-Hallawa and Simon Fraser

MotionMarkLogo

Today, we are pleased to introduce MotionMark, a new graphics benchmark for web browsers.

We’ve seen the web grow in amazing ways, making it a rich platform capable of running complex web apps, rendering beautiful web pages, and providing user experiences that are fast, responsive, and visibly smooth. With the development and wide adoption of web standards like CSS animations, SVG, and HTML5 canvas, it’s easier than ever for a web author to create an engaging and sophisticated experience. Since these technologies rely on the performance of the browser’s graphics system, we created this benchmark to put it to the test.

We’d like to talk about how the benchmark works, how it has helped us improve the performance of WebKit, and what’s in store for the future.

Limitations of Existing Graphics Benchmarks

We needed a way to monitor and measure WebKit rendering performance, and looked for a graphics benchmark to guide our work. Most graphics benchmarks measured performance using frame rate while animating a fixed scene, but we found several drawbacks in their methodology.

First, some test harnesses used setTimeout() to drive the test and calculate frame rate, but that could fire at more than 60 frames per second (fps), causing the test to try to render more frames than were visible to the user. Since browsers and operating systems often have mechanisms to avoid generating frames that will never be seen by the user, such tests ran up against these throttling mechanisms. In reality, they only tested the optimizations for avoiding work when a frame was dropped, rather than the capability of the full graphics stack.

Second, most benchmarks we found were not written to accommodate a wide variety of devices. They failed to scale their tests to accommodate hardware with different performance characteristics, or to leave headroom for future hardware and software improvements.

Finally, we found that benchmarks often tested too many things at once. This made it difficult to interpret their final scores. It also hindered iterative work to enhance WebKit performance.

The Design of MotionMark

We wanted to avoid these problems in MotionMark. So we designed it using the following principles:

  1. Peak performance. Instead of animating a fixed scene and measuring the browser’s frame rate, MotionMark runs a series of tests and measures how complex the scene in each test can become before falling below a threshold frame rate, which we chose to be 60 fps. Conveniently, it reports the complexity as the test’s score. And by using requestAnimationFrame() instead of setTimeout(), MotionMark avoids drawing at frame rates over 60 fps.
  2. Test simplicity. Rather than animating a complicated scene that utilized the full range of graphics primitives, MotionMark tests draw multiple rendering elements, each of which uses the same small set of graphics primitives. An element could be an SVG node, an HTML element with CSS style, or a series of canvas operations. Slight variations among the elements avoid trivial caching optimizations by the browser. Although fairly simple, the chosen effects aim to reflect techniques commonly used on the web. Tests are visually rich, and are designed to stress the graphics system rather than JavaScript.
  3. Quick to run. We wanted the benchmark to be convenient and quick to run while maintaining accuracy. MotionMark runs each test within the same period of time, and calculates a score from a relatively small sample of animation frames.
  4. Device-agnostic. We wanted MotionMark to run on a wide variety of devices. It adjusts the size of the drawing area, called the stage, based on the device’s screen size.

Mechanics

MotionMark’s test harness contains three components:

  1. The animation loop
  2. The stage
  3. A controller that adjusts the difficulty of the test

The animation loop uses requestAnimationFrame() to animate the scene. Measurement of the frame rate is done by taking the difference in frame timestamps using performance.now().

For each frame in the animation loop, the harness lets the test animate a scene with a specified number of rendering elements. That number is called the complexity of the scene. Each element represents roughly the same amount of work, but may vary slightly in size, shape, or color. For example, the “Suits” test renders SVG rects with a gradient fill and a clip, but each rect’s gradient is different, its clip is one of four shapes, and its size varies within a narrow range.

The stage contains the animating scene, and its size depends on the window’s dimensions. The harness classifies the dimensions into one of three sizes:

The controller has two responsibilities. First, it monitors the frame rate and adjusts the scene complexity by adding or removing elements based on this data. Second, it reports the score to the benchmark when the test concludes.

MotionMark uses this harness for each test in the suite, and takes the geometric mean of the tests’ scores to report a single score for the run.

The Development of MotionMark

The architectural modularity of the benchmark made it possible for us to do rapid iteration during its development. For example, we could iterate over how we wanted the controller to adjust the complexity of the tests it was running.

Our initial attempts at writing a controller tried to arrive at the exact threshold, or change point, past which the system could not maintain 60 fps. For example, we tried having the controller perform a binary search for the right change point. The measurement noise inherent in testing graphics performance at the browser level required the controller to run for a long time, which did not meet one of our requirements for the benchmark. In another example, we programmed a feedback loop using a technique found in industrial control systems, but we found the results unstable on browsers that behaved differently when put under stress (for example dropping from 60 fps directly down to 30 fps).

So we changed our focus from writing a controller that found the change point at the test’s conclusion, to writing one that sampled a narrow range which was likely to contain the change point. From this we were able to get repeatable results within a relatively short period of time and on a variety of browser behaviors.

The controller used in MotionMark animates the scene in two stages. First, it finds an upper bound by exponentially increasing the scene’s complexity until it drops significantly below 60 fps. Second, it goes through a series of iterations, repeatedly starting at a high complexity and ending at a low complexity. Each iteration, called a ramp, crosses the change point, where the scene animates slower than 60 fps at the higher bound, and animates at 60 fps at the lower bound. With each ramp the controller tries to converge the bounds so that the test runs across the most relevant complexity range.

With the collected sample data the controller calculates a piecewise regression using least squares. This regression makes two assumptions about how increased complexity affects the browser. First, it assumes the browser animates at 60 fps up to the change point. Second, it assumes the frame rate either declines linearly or jumps to a lower rate when complexity increases past the change point. The test’s score is the change point. The score’s confidence interval is calculated using a method called bootstrapping.

MotionMark’s modular architecture made writing new tests fast and easy. We could also replicate a test visually but use different technologies including DOM, SVG, and canvas by substituting the stage.

Creating a new test required implementing the rendering element and the stage. The stage required overriding three methods of the Stage class:

Because some graphics subsystems try to reduce its refresh rate when it detects a static scene, tests had to be written such that the scenes changed on every frame. Moreover, the amount of work tied to each rendering element had to be small enough such that all systems could handle animating at least one of them at 60 fps.

What MotionMark’s Tests Cover

MotionMark’s test suite covers a wide wariety of graphics techniques available to web authors:

We hope to expand and update this suite with more tests as the benchmark matures and graphics performance improves.

Optimizations in WebKit

MotionMark enabled us to do a lot more than just monitor WebKit’s performance; it became an important tool for development. Because each MotionMark test focused on a few graphics primitives, we could easily identify rendering bottlenecks, and analyze the tradeoffs of a given code change. In addition we could ensure that changes to the engine did not introduce new performance regressions.

For example, we discovered that WebKit was spending time just saving and restoring the state of the graphics context in some code paths. These operations are expensive, and they were happening in critical code paths where only a couple properties like the transform were being changed. We replaced the operations with setting and restoring those properties explicitly.

On iOS, our traces on the benchmark showed a subtle timing issue with requestAnimationFrame(). CADisplayLink is used to synchronize drawing to the display’s refresh rate. When its timer fired, the current frame was drawn, and the requestAnimationFrame() handler was invoked for the next frame if drawing completed. If drawing did not finish in time when the timer fired for the next frame, the timer was not immediately reset when drawing finally did finish, which caused a delay of one frame and effectively cut the animation speed in half.

These are just two examples of issues we were able to diagnose and fix by analyzing the traces we gathered while running MotionMark. As a result, we were able to improve our MotionMark scores:

MotionMark on macOSMotionMark on iOS

Conclusion

We’re excited to be introducing this new benchmark, and using it as a tool to improve WebKit’s performance. We hope the broader web community will join us. To run it, visit http://browserbench.org/MotionMark. We welcome you to file bugs against the benchmark using WebKit’s bug management system under the Tools/Tests component. For any comments or questions, feel free to contact the WebKit team on Twitter at @WebKit or Jonathan Davis, our Web Technologies Evangelist, at @jonathandavis.

What’s new in Chromium 53 and Opera 40

Source: Dev.Opera • Mathias Bynens • 20 September 2016

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

Improved <input pattern="…">

The u flag (which stands for Unicode) is now applied to any regular expressions compiled through the pattern attribute for <input> and <textarea> elements. This enables more Unicode-friendly features, and generally more sensible behavior.

<input pattern="[🍪🎂🍩]">
<!--
        The input only validates when it is either 🍪, 🎂, or 🍩.
        (Previously, those strings would fail validation.)
-->

A demo is available.

<iframe sandbox="allow-presentation">

The Presentation API defines the nw allow-presentation sandboxing flag for <iframe sandbox="…"> which gives web developers control over whether an iframe can start a presentation session. By default, the Presentation API is disabled in sandboxed <iframe>s.

Shadow DOM v1

All browser vendors finally agreed on the Shadow DOM spec, called v1. The new Shadow DOM APIs include:

For more information, check out Hayato Ito’s overview of the differences between Shadow DOM v0 and v1.

MediaStreamTrack Constraints API

The following MediaStreamTrack methods are now supported:

These APIs allow getting, setting, and querying constraints on a MediaStreamTrack.

Additionally, MediaTrackConstraints instances now have video and audio properties.

Promise-based getUserMedia

The navigator.mediaDevices.getUserMedia() API, which returns a promise, is now supported. Also, the unprefixed version of navigator.getUserMedia() (which uses callbacks) is now available. For more info, see Sam Dutton’s write-up.

Unprefixed CSS filter

The CSS filter property is now supported in its unprefixed form. For now, -webkit-filter is still supported as an alias for filter. A demo featuring SpongeBob SquarePants is available.

CSS -webkit-user-select: all

Chromium already supported -webkit-user-select, the prefixed version of user-select, but it didn’t recognize every value the spec defines. As of this update, the -webkit-user-select: all is supported. This property/value pair makes it so that if a selection would contain only part of an element, then the selection must contain the entire element including all its descendants.

For example, if you apply this on all <p> elements, and you then try to select a single word in a paragraph, the entire paragraph is selected automatically.

The CSS Tricks Almanac entry for user-select features a nice demo.

Force flattening when ancestor has opacity

3D-positioned descendants are now flattened by an ancestor that has opacity. Previously that didn’t happen if that ancestor also specified transform-style: preserve-3d. A visual demo explains this better than words ever could.

Rasterization & will-change: transform

Generally, all content is re-rastered when its transform scale changes, unless will-change: transform is applied to it. In other words, will-change: transform effectively means “please apply the transformation quickly, without taking the additional time for rasterization”. This only applies to scaling that happens via JavaScript manipulation, and does not apply to CSS animations. For more information, see the technical summary for this change. A demo is available.

Deprecated and removed features

Synthetic events (i.e. those who are created by JavaScript, and are thus untrusted) are now prevented from executing their default action. click is the only exception for backwards compatibility with legacy content. This change matches the spec and other browsers.

The HTML spec was changed so that <label> elements aren’t form-associated elements anymore. As a result, support for the form attribute on <label> elements was removed, and labelElement.form is now an alias for labelElement.control.form (instead of mapping to the form attribute value).

HTTP/0.9, the predecessor to HTTP/1.x, is now deprecated, and will be removed in a future release. Its replacement, HTTP/1.0, was standardized 20 years ago.

Support for DHE-based TLS ciphers has been removed, after being deprecated in Chromium 51 & Opera 38. Servers should upgrade to ECDHE ciphers instead.

A long time ago, the File API spec was changed to remove the FileError interface. It has been deprecated since 2013. As we’re preparing to remove this interface entirely in a future release, any usage of FileError now triggers a warning in the DevTools console.

The TextEncoder API no longer accepts an argument that specifies the encoding. Instead, it always uses UTF-8. If an argument is passed, it is ignored. This means that new TextEncoder('utf-16') and new TextEncoder('utf-16be') no longer work.

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.

Monday Profile: Alicia Sedlock

Source: Web Directions Blog • John • 19 September 2016

Alicia SedlockAt our Code 16 conference, Alicia Sedlock gave a very popular presentation on testing – not, you might think, the most rivetting subject but one made practical and accessible by Alicia.

It probably didn’t hurt that Alicia featured a few snaps of her favourite companion, Mabel the hedgehog. Here’s the interview we conducted with Alicia (but not Mabel) for Scroll Magazine before the conference.

Q What made you decide you could do this for a living?
A Well, the glamourous way it all began was sitting on my parents’ Dell PC making custom LiveJournal and MySpace layouts. Seriously. I thought I’d end up being able to make layouts for famous Internet personae and make a lot of money doing it.

That’s what sparked my initial web development interests, which inspired me to sign up for my high school’s Intro to Web Design elective. It was a half year elective that opened me up to what HTML really was, how CSS works, and how to do animations and interactivity in Flash. I went on to sign up for the full year course in my junior year, and as independent study in my senior year, and ended up majoring in Web Design and Interactive Media in college. I was always a creator at heart (don’t even ask me how many art mediums I’ve tried to pick up) and web development stuck, for some reason.

Q Have you ever coded live on stage, or in front of an audience? How did it go?
A I recently attempted my first live code talk at my work, giving a Lunch & Learn talk to our development team about CSS flex and grid layouts. I thought, “I know this fairly well, I’ll just dive right in!” Turns out, that didn’t work too well. Debugging on a giant projector is somehow even more nerve wracking than anything I’ve done in front of a group before.

Q How do you further develop and extend your skills? Books, courses? Noodling by yourself?
A I follow a lot of people on Twitter. A lot. And even though it’ll take me all day to catch up on my timeline, I get exposed to a lot of new and upcoming things – SVG, React, animations, accessibility, new web standards, you name it.

I essentially use it as a filter, so that when a topic comes across the feed that I’m excited about, I have a place to start digging in. I end up reading a lot of blog posts, forking a lot of pens on CodePen, messing around with them, then building something small and dinky to get my teeth into something.

Q Is it better to learn HTML then CSS then JavaScript, or JavaScript then HTML then CSS, or all three at once, or something else?
A I think it depends on what your goals are for learning. If your goal is to have a visual interface that you can interact with to do cool things, then getting a handle on HTML/CSS before JavaScript might be the better approach. If you don’t care about interfaces and simply want to punch out crazy computations or algorithms, perhaps learning JavaScript first would get you there. I’d say it’s a case-by-case basis.

Q What’s the best way to get more women coding?
A There are already a lot of women in programming. It’s about how do we keep them from leaving the industry, which requires looking at the hard truth about why women leave the industry. Lack of work life balance, lack of support for new mothers, and then, you know, the constant harassment and abuse many women experience throughout their careers, both online and in their workplaces. So if we want to keep women in the industry, we need to address these types of systemic issues right where they are – in our workplaces, our open source communities, our conferences.

Q Frameworks. What’s your take? Are they good, bad or does it depend on how you use them?
A It absolutely depends on how and why you use them. The impression I get these days is that many developers are looking for THE framework, the framework that they’ll use for every project for the rest of their days. If they work on one particular kind of application, and make that same application over and over again, then maybe that can be a reality. But every framework has their upsides and downsides, so for the majority of us, it’ll never be that easy.

Developers need to really look at frameworks and say, “What is this really giving me that I can’t live without? What problems am I facing that this framework solves that I can’t solve without it?” I’d say the mentality of “always use a framework” is more dangerous than the frameworks themselves.

Q Tabs or spaces?
A Soft tabs. Fight me.

Q What’s on your horizon?
A To be quite honest, I’m not really sure. None of my career thus far has been part of a long-term plan. I only end up making decisions as opportunities arise. However, the one thing I would like to achieve eventually is to make a game that works in the browser, and on all devices.

directionad

Want more?

Like to see and read more like this? Be the first to score invitations to our events? Then jump on our once-a-week mailing list where we round up the week’s best reading and watching on all things Web. And you’ll get a complimentary digital copy of our brand new magazine, Scroll.


The post Monday Profile: Alicia Sedlock appeared first on Web Directions.

Minutes Telecon 2016-09-14

Source: CSS WG Blog • Dael Jackson • 15 September 2016

Full Minutes

Countdown to Direction 16

Source: Web Directions Blog • John • 13 September 2016

10th anniversaryWe’re counting down to Direction, our big end of year conference, the 10th anniversary of our very first event. For this year we’ve made some changes (while keeping to the essence of the event thousands of attendees over the last decade have found so engaging and valuable). We’d love you to join us, as we set sail for the next exciting decade.

Long-time (and even more recent) attendees of Web Directions will probably have noticed a few changes across all the various activities we run.

But none is bigger than the (r)evolution of our major annual event, which for the last decade since it started in 2006 has been known as Web Directions.

Way back then, our focus was almost entirely on Web design and our audience was that many-hatted expert of all things Web, from HTML and CSS to visual design, usability and accessibility, content, SEO and much more besides.

But just as the Web, and the community of professionals around this core technology have changed profoundly in the last decade, we’ve changed too. We added tracks to help those specialising in specific areas of practice develop their knowledge and skills. And we found, over time, that it was the ideas that ran across specialisations that particularly engaged and energised our audience.

Over the decade, and particularly in recent years, we’ve developed new conferences focusing on specific areas of practice, like Code for front-end engineering, Respond for web and interaction design, and most recently this year Transform, focusing on the revolution occurring around the world in Government Services Delivery. All these will continue — and, indeed, grow — into the future.

As we turned toward the second decade of Web Directions, we spent a lot of time (and I mean a lot) thinking about the role of our “big” event. From its name (we’ve felt for a while now the word “Web” is limited in its reach and appeal, backed up by emails from people who’ve told us their boss won’t send them to a “Web Design” conference), to how many tracks it would comprise, to the overall focus of the event.

And so, after a lot of consideration, and many conversations with people close to the events,  was (re)born — Direction.

The name both links to our past and looks to the future. The choice of the singular “Direction” over the plural “Directions” was very deliberate, and aims to capture the key mission of the event. When we know where we want to go, we ask for directions. But on the bigger journeys of our life, both personal and professional, there is no single destination, no one specific place we are looking to go. Rather, there’s an overall direction in which we are headed. And it’s that choice of direction that this event is all about. This idea is for me captured poignantly in Robert Frost’s perhaps too-often quoted poem “The Road Not Taken”

Two roads diverged in a wood, and I—
I took the one less traveled by,
And that has made all the difference.

Each of us likely has a story of paths taken and not: junctures in our lives, personal and professional. Those of us who work in and on the Web, and at the intersection of design and technology, almost certainly did not follow the sorts of paths associated with more traditional professions and careers. Our ‘field’ (a term too constrained to describe the landscape we inhabit) continues to evolve (we continue to evolve it). The novel ideas and skills and techniques we learned last year become “table stakes”, even obsolete – replaced, superseded or subsumed by what comes next. And keeping up is both exciting and challenging. This restlessness almost defines our field.

At the heart of our events (and everything else we’ve done over the last decade and more, and at the heart of my own writing, speaking, and even the software I’ve written over the last 20 years) has been the effort to make sense of where we are, and where we are going. I think this is in no small part why such ground breaking, and diverse ideas as OOCSS (first introduced to the world by a then little known Nicole Sullivan at Web Directions North in 2009) and “The New Aesthetic” (an idea originally outlined by James Bridle at Web Directions South 2012), alongside now world renowned speakers who first spoke at our events, have originated at our conferences. We spend a significant part of our lives here thinking about these divergent roads, and finding ways to introduce them to our audience.

And it’s this that’s the animating focus of Direction. Not a prescriptive “here are the things you should be doing”, not directions to get you from A to B, but ideas about which direction to take, about where our field at the intersection of design, the Web and technology seems to be going.

Over the next two months, as we lead up to the 10th anniversary of our first event, and the first Direction conference (which will also be very familiar in many ways from previous Web Directions you’ve been to) I’ll be going into more detail about the sessions we’ve programmed, and my thinking behind what interested me about the ideas, and the experts delivering them, and how all this fits into the broader themes and patterns and trends I see emerging in our field.

But if there’s a theme, among others that will emerge in the coming weeks and at the conference, it’s that we don’t face that fork in the road just once in our careers in this field: we face these choices, in large ways and small, over and over.

And when we choose a path, it’s also to the exclusion of the road not taken, so these choices really do matter, they shape our lives, sometimes a little, and sometimes much more.

Which is an enormous privilege that we have – in many other fields, the choices and opportunities are far more constrained.

But there’s no doubt it can be challenging to face this constant change, the incessant requirement to keep up with currents of practice, with technologies and ideas.

The phrase “I’m too old for this” passes my lips perhaps bit too frequently. But then I look to the work emerging where design and technology meet, on the Web, with physical objects, in the built environment, and the excitement overcomes my anxiety, as I’m sure it does for you. And ironically, it keeps me young.

Direction is all about that excitement, helping fuel it, through amazing presentations, and experiences outside the theatre, and channel it toward what comes next.

I can’t wait for it to come around, and to share it with you.

The post Countdown to Direction 16 appeared first on Web Directions.

The CSS WG and the SVG WG updated the Working Draft of Web A…

Source: W3C's Cascading Style Sheets home page • 13 September 2016

13 Sep 2016 The CSS WG and the SVG WG updated the Working Draft of Web Animations

Monday Profile: Greg Rewis

Source: Web Directions Blog • John • 12 September 2016

Greg RewisOur series of interviews with conference speakers for Scroll Magazine has proven very popular, both for the insights each has given into that particular speaker but also how they compare to each other. This week, we profile Greg Rewis, speaker at Code 16.

For another perspective, later in the week you can also see the video interview I conducted with Greg.

Q: What made you decide you could do this for a living?

A: I actually kind of tripped into my career. I was working in the late 80s in Denmark at a newspaper and magazine publisher as a journalist. And one day, some boxes containing some Mac IIfx computers showed up. I was the only one in the office that had any experience on a Mac, so I went about setting them up, installing software (QuarkXPress 1.12 and Illustrator 88!), and showing my colleagues how to work them. Any time someone would get stuck, I ended up being the person they called. Needless to say, my career as a journalist quickly turned into my career in IT.

Through that transition, I began thinking about the software we were using to create our publications, which took me to the first MacWorld in Berlin. I had the good fortune to talk with a couple of developers out of Hamburg who were building a publishing system based around QuarkXPress. A few conversations later and a trip to Hamburg and I had a new job as the product manager for their publishing system.

A few years later, we began working on a project to mark up the stories in the database for re-use on things like CD-ROMs. That little project turned into one of the first HTML authoring tools, originally named GoLive, which would become GoLive Cyberstudio, and eventually Adobe GoLive. After Adobe’s acquisition of GoLive, I “defected” to Macromedia to help build Dreamweaver. Of course, the joke was on me, as Macromedia was eventually acquired by Adobe.

As a product manager, you have an opportunity to do presentations. And I ended up, not only liking to do presentations, but actually being really good at it! So somewhere along the line, I transitioned to being a full time developer evangelist.

 

Q: Have you ever coded live on stage, or in front of an audience? How did it go?

A: All the time. I actually really enjoy live coding, as I think it helps establish credibility. As a developer evangelist, it’s important that the audience understands that I really do know what I’m talking about and I’m not simply doing a marketing or sales pitch.

And, at least for me, live coding helps with that. The one key is that the coding actually accomplishes something — in other words, I’m doing it so that I can simultaneously explain something without having someone “read ahead” on a slide.

 

Q: How do you further develop and extend your skills? Books, courses? Noodling by yourself?

A: A large part of my job is “noodling”. In fact, that’s how almost every demo I’ve ever done has come about. Whenever I’m learning something new, I try to think “what could I build”? As an example, when I joined Salesforce and began learning the platform, I immediately pulled out an old project built on a different technology stack and thought “how could I rebuild this for Salesforce”. I find that building my own project helps me learn faster than simply doing someone else’s tutorial.

 

Q: Is it better to learn HTML then CSS then JavaScript, or JavaScript then HTML then CSS, or all three at once, or something else?

A: On the question of HTML or CSS, I think they should probably be learned together, because without CSS, HTML is pretty boring. And although there are roles in which you only need HTML and CSS, I think most front-end roles today also require a good understanding of JavaScript.

The important thing about learning JavaScript is to learn JavaScript, and not a framework or library. I know a lot of developers that started with jQuery, and that’s fine. But even if you are using jQuery (or Angular/React/Backbone/etc), it behoves you to understand the plain vanilla JavaScript. Because at the end of the day, even if you are “writing jQuery”, you’re still writing JavaScript.

 

Q: What’s the best way to get more women coding?

A: The simple answer is to get them interested. But doing that means that we have to do two things. The first is to break down the typical nerd or geek stereotype in a way that makes young girls think “I could see myself doing that”. Having the typical image of a developer being someone who is socially awkward, with no sense of style, would make even a younger me not want to pursue that job!

The other — and perhaps much harder — challenge is to craft an environment where those girls and women who choose to become developers feel safe and welcome. No one wants to work in a hostile environment, but that is what many women in the industry feel about working as developers.

 

Q: Frameworks. What’s your take? Are they good, bad or does it depend on how you use them?

A: Frameworks can be awesome — but they also can be a crutch. The important thing, as I mentioned before, is that you know how to survive without them. I once saw someone include jQuery in order to do something that could’ve been achieved in less than 10 lines of plain JavaScript.

 

Q: Tabs or spaces?

A: For? It’s actually quite simple. Tabs are for indentation, spaces separate words.

 

Q: What’s on your horizon?

A: Setting off to sail around the world … in 5 years. But before that, continuing to learn and grow as a developer. It’s really awesome (and tiring) to be in an industry that is growing and changing so quickly.

 

The post Monday Profile: Greg Rewis appeared first on Web Directions.

Minutes Telecon 2016-09-07

Source: CSS WG Blog • Dael Jackson • 08 September 2016

Full Minutes

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