The future of style

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

Latest articles

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

W3C Web.br is the main Web conference in Brazil, organized b…

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

13 Oct 2016 W3C Web.br is the main Web conference in Brazil, organized by W3C Brazil, CGI.br, NIC.br and CEWEB.br. This year's special focus is on the Web of Things and Finance. Keynote speakers include Dave Raggett and Bert Bos. (Conference in Portuguese.)

CSS Dev Conf is a conference about CSS in San Antonio TX (US…

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

17 Oct 2016 CSS Dev Conf is a conference about CSS in San Antonio TX (USA), on 17–19 October. A feature of this conference is that part of the conference program is determined by vote.

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

Release Notes for Safari Technology Preview Release 14

Source: Surfin' Safari • Jon Davis • 28 September 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.

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.

Release Notes for Safari Technology Preview Release 13

Source: Surfin' Safari • Jon Davis • 15 September 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

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

Monday Profile: Stephanie Rewis

Source: Web Directions Blog • John • 05 September 2016

One of the things I’ve appreciated most with Scroll Magazine, has been the opportunity to get to know some of our speakers better, particularly some of the things you might not necessarily know about them.

This week we’re featuring an interview with Stephanie Rewis, a long time contributor through books, blog posts, workshops and presentations to the Web. Keep an eye out for my interview with Steph, and more in coming weeks.

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

A: I’ve always had an interest in how the brain works and it seemed logical to introspect, identify my innate skills, and find a career that utilized those. I love puzzles, research, and detective work. I believe life is about continual learning. I didn’t know much about code, but thought it might make use of those abilities.

After taking an HTML class, I was interested, but decided I would rather learn at my own speed. I did tutorials 15 hours a day for the first year. I got friends to let me build websites for them (you don’t know what you don’t know until you try things). I joined a mailing list and obsessively asked questions. As my questions were answered, I asked harder questions and answered the easier ones from new folks.

As time went on, I was doing more answering than asking. Business owners who planned to build their own site then found it to be harder than they anticipated would contact me offlist and ask what I would charge to build it for them. And that’s when I realized I could do this for a living. People helped me and asked nothing in return, I passed that knowledge on to others, and I never did any marketing. Starting my business was organic.

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

A Oh yes. I used to code on stage all the time. But for me, writing code at my desk as opposed to writing it in front of an audience uses different brain modalities. When you’re nervous, you may not notice a typo, a missing semi-colon, etc. And then you can’t see it and the audience has to help you figure out why it isn’t working. It’s a little nerve-wracking.

Over time, I’ve tried different methods of showing code. Sometimes I’ve commented code out in chunks and then uncommented bit by bit while explaining it and showing what it does. Nowadays, I lean more toward making a movie of writing and showing it and then talking through it while it plays, which also saves time from bouncing between Keynote and a browser.

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

A I stay pretty busy these days, so I find myself doing more reading of blogs and articles by people I trust (many times discovered via my RSS reader — Twitter). If I’m searching for specific information, I limit my search parameters to the past year. If a site doesn’t put a date on their posts, I get highly irritated and disregard their information. Web information is not timeless. Things change at a rapid pace. When I get books, I tend to cherry pick the information I read rather than doing a cover to cover read.

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 They work as a team. HTML — or good, accessible, semantic markup — should be the root of all things. You should understand what markup is appropriate to use in specific circumstances. HTML is the only one in the group that could stand alone if needed. If your JS and CSS were turned off, your HTML should look like a nice logical outline with headings, lists, and paragraphs.

CSS is, of course, used for all styling. As CSS has become much more powerful, it’s best for performance reasons to create animations and transitions using CSS instead of JS. More than likely, if you can do it with CSS, you probably should.

JS is used to enhance the experience. And in the true spirit of progressive enhancement, content should be available without it. Maybe it won’t be as sexy, but the user doesn’t miss important things. To me, this is sadly missing in many JS frameworks today. And newer web developers don’t seem to understand why that’s not a good thing, and they don’t attempt to make their sites accessible.

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

A That’s a loaded question, isn’t it? I’ve heard a lot of good ideas about making our work environment more conducive to keeping women, and I think those are great. But quite honestly, I think the root issue is far deeper. It begins with the media and our culture. Where are the amazing geek role models on TV shows (yes, there are a slim few lately)? What is held up to girls as important when they’re young? Is it being smart, or is it being thin and beautiful?

What if we put less influence on the Kardashians — women who have achieved nothing but a lot of plastic surgery and media attention — and more on women who have made really amazing technical and scientific achievements? What if we made being smart sexy? I believe that attracting young women to our industry starts with changing the expectations put on them as a culture.

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

A In the case of JS frameworks, I strongly believe you should be well- grounded in plain vanilla JS and progressive enhancement. Then, if you choose to use a framework, yes, use it smartly and accessibly.

In the case of CSS frameworks — I have strong opinions since I’ve used some and written one. I found in using a couple over the years that they tended to be overbloated and far more than I would write myself. I either didn’t need a good bit of what they included, or I needed to change and override so much of it that it became even bigger. It’s hard to be all things to all sites that might want to use your framework.

That said, I lead the CSS framework we’ve written for the Salesforce Lightning Design System. We work hard to start with reusable micro- patterns and to only write what we actually need. We have the luxury of writing for our specific enterprise ecosystem. It’s not meant to be a generic, “use it for everything” framework. So while some people using our framework may override the branding colors (via tokens or variables), in the end, most want their components to look like the new Salesforce Lightning experience. It’s a great time-saver for both internal and external developers building on our platform.

Q Tabs or spaces?

A I could barely care less than I do. When I was doing a lot of contracting for agencies, I regularly switched my editor to output whatever they preferred. Our team currently uses spaces (I had to look at my preferences to tell you that. LOL). I set the translate_tabs_to_spaces to “true” and then I never think about it again. There are other things I’m more passionate about — like the code that follows those tabs or spaces.

Q What’s on your horizon?

A In five years, Greg and I will be taking off on Amritha, our Lagoon 400 catamaran, to circumnavigate the globe for 8-10 years. Until then, I’m absolutely loving my role at Salesforce. It’s a place where I’m well- supported as a human and encouraged to continually learn, grow, share, and lead. I can’t think of a better, more challenging role to work in until we exit.

Like to watch 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 Scroll magazine.


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

Minutes Telecon 2016-08-31

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

Release Notes for Safari Technology Preview Release 12

Source: Surfin' Safari • Jon Davis • 30 August 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

Minutes Telecon 2016-08-24

Source: CSS WG Blog • Dael Jackson • 25 August 2016

Full Minutes

Minutes Telecon 2016-08-17

Source: CSS WG Blog • Dael Jackson • 18 August 2016

Full Minutes

Release Notes for Safari Technology Preview Release 11

Source: Surfin' Safari • Jon Davis • 17 August 2016

Safari Technology Preview Release 11 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 203771–204289.

JavaScript

Web APIs

ApplePay

Web Inspector

MathML

CSS

Rendering

Media

Accessibility

Content Blockers

Minutes Telecon 2016-08-10

Source: CSS WG Blog • Dael Jackson • 11 August 2016

Full Minutes

Minutes Telecon 2016-08-03

Source: CSS WG Blog • Dael Jackson • 04 August 2016

Full Minutes

Release Notes for Safari Technology Preview Release 10

Source: Surfin' Safari • Jon Davis • 02 August 2016

Safari Technology Preview Release 10 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 203152–203771.

JavaScript

Web APIs

Apple Pay

Web Inspector

MathML

Rendering

Accessibility

Security

What’s new in Chromium 52 and Opera 39

Source: Dev.Opera • Mathias Bynens • 02 August 2016

Opera 39 (based on Chromium 52) 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.

ES2016 exponentiation operator

ES2016 introduces an arithmetic operator equivalent of Math.pow(base, exponent), in which the lefthand-side expression serves as the base value, and the righthand-side expression serves as the exponent.

4 ** 3;
// → 64

let value = 4;
value **= 3;
value;
// → 64

Fetch API: Response construction with ReadableStream

It’s now possible to construct your own ReadableStream instances and to use them as bodies for Response objects, including from within service workers. This functionality is part of the Fetch standard. See Jeff Posnick’s write-up for details, or Jake Archibald’s in-depth blog post on streams for even more info.

Fetch API: referrer policy

Requests made using the Fetch API can use a specific referrer policy, which affects the value of the Referer HTTP header that’s sent to remote servers. This can be done by adding a referrerPolicy property to the options object passed to fetch, which accepts the following values:

See Ehsan Akhgari’s write-up for a straight-forward explanation of these values.

fetch(url, { 'referrerPolicy': 'no-referrer' })
        .then(function(response) {
                // Do something with the `response`…
        });

A demo is available.

2D canvas filters

CanvasRenderingContext2D instances now support the filter property that applies effects to primitives drawn to the canvas. The filter value is parsed in the same way as CSS filters.

const canvas = document.querySelector('canvas');
const context = canvas.getContext('2d');
context.filter = 'saturate(6.3)';

createImageBitmap options

An ImageBitmapOptions object is an options object that can be passed to createImageBitmap().

createImageBitmap(image, options).then(function(response) {
        // Do something with the `response`…
});

The available options are:

Invalid <track kind> values are no longer treated as subtitles

Invalid values for <track kind> were previously treated as 'subtitles'. This means that any new values would be treated as subtitles by old browsers. Chromium now uses 'metadata' instead as the “invalid value default”, to avoid browsers showing <track>s with unrecognized values.

HTMLMediaElement.prototype.srcObject

The srcObject property on HTMLMediaElement instances enables associating a MediaStream to a media element using a simple assignment. Previously, achieving this required first obtaining a URL associated to the MediaStream, and then associating this URL to the media element.

Currently, only MediaStream objects are accepted because it is the only type currently supported by other major browsers, but Chromium aims to support more types in the future. (Per the spec, a MediaProvider can be a MediaStream, a MediaSource, or a Blob.)

Web Audio updates

AudioParam instances now have readonly minValue and maxValue properties that specify the minimum and maximum values the AudioParam can have. The value is clamped to lie in this range

Automation methods for the position and orientation coordinates of PannerNode and the position{X,Y,Z}, up{X,Y,Z}, and forward{X,Y,Z} vectors of AudioListener are now available. This allows smooth changes in the coordinates using AudioParam methods.

Chromium now implements the reduction property on DynamicsCompressorNode instances as a readonly float, matching the spec. Previously, the value was represented as an AudioParam.

IDBKeyRange.prototype.includes()

The includes method on IDBKeyRange instances tests whether or not a key exists within the bounds of the range. Until all other browsers support this natively, a polyfill can be used.

WebRTC: Storing RTCCertificates in IndexedDB

RTCCertificates are self-signed certificates used in the DTLS handshake when setting up a connection with an RTCPeerConnection. Chromium now allows web applications to store RTCCertificates by implementing the structured clone algorithm. This means RTCCertificates can be saved and loaded from an IndexedDB database, saving the cost of generating new certificates for new sessions.

Performance Observer

The Performance Observer API is essentially a streaming interface that can be used to gather low-level timing information asynchronously, as it’s gathered by the browser. Marc Cohen’s write-up does a great job explaining it.

Pause event loop during modal dialogs

When using alert(), confirm() or onbeforeunload, Chromium’s old behavior was to block JavaScript while waiting for the result, but to allow all declarative animations to continue. As of this update, Chromium makes all main-thread tasks (such as <marquee> and CSS 2D animations) also pause during this interval.

Here’s a demo showing the impact of alert() on a CSS 2D animation.

CSS containment

The CSS contain property indicates that an element and its contents are, as much as possible, independent of the rest of the document tree. This allows the browser to recalculate layout (contain: layout), style (contain: style), paint (contain: paint), size (contain: size), or any combination of them for a limited area of the DOM and not the entire page. For more details, check out Paul Lewis’ explanation.

CSS font-variant-caps & font-variant-numeric

The CSS properties font-variant-caps and font-variant-numeric are now supported.

meter { -webkit-appearance: none; }

Previously, there was no way to completely disable the browser’s default rendering of <meter> elements and to restyle them using CSS. As of Chrome 52 / Opera 39, this finally became possible using -webkit-appearance: none.

New CSS Flexbox behavior for absolutely-positioned children

The static position of absolutely-positioned children used to be set as though they were a 0×0 flex item. The CSS Flexible Box Layout spec has since been updated to take such children fully out of flow and to set the static position based on align and justify properties. Check out the demo.

Alternative Services

Alternative Services allow an origin serving an http:// or https:// resource to nominate additional origins that the client can choose to request the resource from instead when making subsequent requests. This can be used, for example, as a protocol upgrade mechanism, for connection pooling, or for load balancing.

This is done through the Alt-Used HTTP header.

For example, if the resource at https://origin.example.com/foo returns the following response headers:

Alt-Used: https://alternate.example.net

…and https://origin.example.com/bar is requested afterwards, then the browser may fetch either https://origin.example.com/bar or https://alternate.example.net/bar.

CSP3 strict-dynamic

The 'strict-dynamic' source expression allows scripts loaded via nonce- or hash-based whitelists to load other scripts. Deploying CSP is now simpler than ever before. A demo is available.

Deprecated and removed features

X-Frame-Options is now ignored when present inside a <meta> tag, e.g. <meta http-equiv="X-Frame-Options" contents="DENY">, matching the spec. Use an HTTP header (X-Frame-Options: DENY) instead.

A non-standard and little-used variant of the postMessage() API is being deprecated, specifically postMessage(message, transferables, targetOrigin). Use postMessage(message, targetOrigin, transferables) instead.

The ended event & property and the onended event handler have been removed from the Media Capture and Streams spec and are now being deprecated in Chromium.

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.

Color Function Syntax Update

Source: CSS WG Blog • fantasai • 29 July 2016

From Tab’s blog post on the recent changes to the Color module:

Yesterday I committed a few changes to the CSS Color spec that are proving a little controversial to people without any background on the changes. Hopefully this will help!

Specifically, I made it so that the rgb() function (and others) can now use the syntax rgb(0 255 0 / 50%) for half-transparent green. Previously you’d write that as rgba(0, 255, 0, 50%). Why’d I make this change?

This is part of a general overhaul to how CSS defines functions that fantasai and I are pushing. The overall strategy is written up on our wiki, but the general idea is that CSS has some informal rules about how to organize things and use certain punctuation characters. In particular, in CSS properties we normally just separate values with spaces, relying on distinguishable syntax (like <string> vs <number> vs <length>) or just careful ordering to keep things unambiguously parseable. We use punctuation separators only for very specific purposes: commas are used to separate repetitions of a base value (like layers in the background property, or font names in the font-family property), and occasionally, when we can’t do anything better, a slash is used to separate two otherwise-ambiguous values (like font-size vs line-height in the font shorthand, transition-delay vs transition-duration in the transition shorthand, or the multiple pieces of syntax in a border-image layer).

However, functions violated those rules. They used commas extensively and somewhat inconsistently, just to separate values from each other. On the one hand, this makes CSS functions look slightly more like functions in a traditional programming language; on the other hand, it meant you had to learn a different mental model of how CSS’s syntax works, and type a bunch of comma characters that weren’t actually necessary. fantasai and I have gradually come to the position that it’s worthwhile to unify CSS’s syntaxes, making functions more property-like. (Our position can be summed up aptly as “functions are just named chunks of CSS syntax”.)

Color

So that brings us to the Color spec. Color 3 was already a function-full spec, and Color 4 more than doubles that number, adding hwb(), gray(), lab() and lch(), and color(). The first four of those look similar to the existing rgb()/etc functions, just taking a couple of numbers, so they were originally designed with the same syntax, separating every number with commas.

But color() was a bit more complex, more like a CSS property. It had to take a colorspace name, an arbitrary number of arguments to the colorspace, an alpha, then finally a fallback value in case the colorspace wasn’t loaded or was invalid. Putting commas between every value there just got ridiculous, not to mention made it difficult to read; in particular, it was hard to tell where the colorspace arguments ended and the alpha began.

So, I opened Issue 266 about it, and discussion eventually led us to making it use CSS property syntax pretty much exactly: color() takes a comma-separated list of colors (each one serving as fallback for the previous), and within each color, everything is space-separated. Because colorspaces can take an arbitrary number of numeric parameters, the alpha value was ambiguous (hard to even tell whether or not there was an alpha at a casual glance), and so we employed the slash to separate it visually from the parameters.

At this point, tho, it was slightly weird to have this one color function use this particular syntax form, while none of the others used anything like it. Welp, all the color functions were on our wiki page’s list of things to overhaul anyway, so bombs away! We went ahead and changed all the new functions to use the same syntax (all values space-separated, with an optional slash-separated alpha), and then added a new syntax variant to the old functions with the same form.

(I stress, this is a new variant syntax, not a replacement. All your old rgb(0, 255, 0) code is fine and will never be incorrect. We’re just classifying it as a legacy syntax; we’ve got a handful of those cluttering up CSS specs.)

So, now all the color functions use the same syntax form, and they all agree with our general push to make functions resemble properties more closely. It may feel a little weird at first, but I think you’ll appreciate it as you get used to it (a few characters less typing, at the very least). And we’ve been edging this way for quite a while – as far back as linear-gradient() we were trying to use commas reasonably, with the complex sizing/positioning part up front completely space-separated and commas used only to separate the color-stop repetitions.

Minutes Telecon 2016-07-27

Source: CSS WG Blog • Dael Jackson • 28 July 2016

Full Minutes

Idea of the Week: Ricky Onsman

Source: Web Directions Blog • John • 26 July 2016

Code conferenceWith our Code conference starting in Sydney in just a few days and in Melbourne next week, our Idea of the Week this week comes from the conference’s Scroll magazine and its editor, Ricky Onsman.

As he explains, you should definitely see what your Sydney and Melbourne code-focused meetups are up to this week and next.

Meetups at Conference Time

by Ricky Onsman

Web Directions has long been a sponsor of meetups that have a focus on web technologies. Often, these meetups in different cities around Australia provide an opportunity for conference speakers to test material in front of a willing and supportive audience, in the process helping to promote the conference and also attracting more people to the meetup.

For that reason, meetups that happen around the time of a conference event are often exciting affairs, with more people than usual and an international flavour.

The SydCSS meetup held the night before our Respond conference in Sydney in April was just such an event. One hundred and thirty of us turned up to the rather cool rooftop bar of the Pyrmont Bridge Hotel on a balmy Sydney early autumn evening, where we found a generous bar tab and regular rounds of tasty snacks circulating through the room. Classy, or what?

There was a real air of excitement as the usual buzz of friends and colleagues seeing each other was heightened (literally!) by the spectacular semi-outdoor setting, as well as the awareness that tonight would be graced by two major speakers from Respond.

Rachel Ilan Simpson is an American UX Designer based in Munich who works on the Chrome team for Google. Her Respond presentation was to be a version of a talk she’d originally created and presented with Guy Podjarnik, and this meetup would give her the chance to test some of the material solo with a live Australian audience.

The topic Rachel addressed was one with which developers and designers alike often struggle: finding the balance between website Usability and Security. Users want sites that can guarantee the security and safety of any information they provide, but they don’t want things to get in their way, like passwords.

Rachel took us through several aspects of the situation, looked at some of the core issues, made us cringe at some of the statistics and wince at some of the examples, and offered some ways all of this might be addressed. It was an excellent preview of her longer presentation at Respond itself.

The other main speaker was Russ Weakley, an Australian designer, front end developer and trainer based in Sydney who has built an international reputation not only as a CSS expert, but as someone who can make the often arcane world of stylesheets comprehensible even to beginners, while inspiring veterans to look at new ways of using CSS.

On this occasion, Russ took us into the world of CSS Property Values and the syntax required to use them properly. That might sound dry – but have you ever seen a Russ Weakley talk? Dry, it was not. He’s a very funny speaker who nonetheless has an excellent grasp of his subject, and that special knack of clarifying things that often look dauntingly complicated.

He even came up with a code puzzle for us to solve, with the winners taking home copies of the excellent Offscreen magazine.

Both speakers received a very warm reception from a knowledgeable crowd. The post-talk questions and answers were informed and technical, which helped to give the whole evening a comfortably techy feel.

As with most meetups, there were short announcements of local projects, opportunities, events and jobs, then a lot of chat until the food and drinks ran out. A top night out.

In Melbourne, a similar event took place the day after the conference, in the form of a mega meetup between the MelbCSS, MelbJS and BeResponsive groups. That time, Jen Simmons and Ryan Seddon spoke to another packed audience.

Wherever you are, whatever your specialties, it’s definitely worth searching out meetups in your area that focus on your interests – especially when they’re sponsored by Web Directions, and even more especially when it’s conference time.

 

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

Monday Profile: Yoav Weiss

Source: Web Directions Blog • John • 25 July 2016

Yoav WeissThe Code conference is upon us this week! Monday Profile is again with one of our international speakers, Yoav Weiss.

Yoav is a Web performance and browser internals specialist, whose talk at Code focuses on third party content on websites, mitigating its impact on performance and security, and its longer term implications.

This interview is also in the second issue of our Scroll Magazine.

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

A I grew up in Israel where software development is the major industry. So, before I started higher education, I decided to work for a while to save up some money that would help me get myself through school. With software being the major (if not only) non-minimum-wage option, I started working as a software tester, picked up programming while doing that, and moved to software development a few weeks later.

I found it to be extremely fun and creative and I loved the problem solving part of it. Before I knew it, I was deep in the trenches in a software engineer position.

Took me few more years to actually take some time off in order to go to school and complete a Computer Science B.Sc.

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

A No, I have not. I don’t think that my typing skills are up for the task. If I had to demonstrate code on stage, I’d probably use a pre-recorded video.

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

A I read professional books from time to time, but most of my reading is done online. A large chunk of my work day (and evenings) is dedicated to reading the latest blog posts, standards discussions and specification changes. Whenever I encounter a new subject that I need to study, I usually tackle it with a mix of tutorial reading and playing around with it in practice.

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 HTML is the foundation upon which the web is built, and it’s certainly not advised to reimplement basic HTML functionality in JavaScript. So, if your job is to build Web pages, you probably want to learn the foundations first, starting from HTML, then CSS and then JavaScript.

That way you can be sure that you’re tackling the problems you encounter with the right tools for the job, creating page components with HTML, styling them with CSS and adding functionality on top of that using JavaScript.

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

A I think the real question is how do we avoid discouraging the women and other under-represented groups about to enter the field from feeling marginalized and unwelcome. To me, the key is to create welcoming and “noob-friendly” environments. Many projects use the “meritocracy” narrative in order to justify shitty behaviour to people new to the project, or to people in general.

That behaviour is particularly hostile to women and other under-represented groups, but at the end of the day, it’s bad for everyone. No-one likes to have to take verbal abuse as part of their work, and certainly not as part of their off-hours open source participation.

I believe that a code of conduct with clear rules regarding unacceptable behaviour and strict enforcement of those rules helps everyone, enables everyone to express themselves, and encourages new people of all kinds to participate.

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

A Frameworks help speed up development and have certain UX advantages, but they often do that at the expense of our users. Our users often have to run more code on their machines than necessary, which can be taxing for both loading and runtime performance. Especially today, when more and more of our users are on mobile devices, the performance price of frameworks must be taken into account when deciding to use them.

At the same time, the wide use and popularity of frameworks indicates that there’s a need for the abstraction they provide. As someone working on browsers and the Web platform, I give a lot of thought to that subject. I’m hoping that one day we can figure out a way to provide the UX and development ease of frameworks as part of the platform itself.

Q Tabs or spaces?

A Vim.

Q What’s on your horizon?

A I plan to continue working on browsers and their performance-related features, at least until I feel that loading performance is no longer an issue. I don’t think that will happen anytime soon :)

Another issue that’s close to my heart is getting more people involved in Web standards and browser work, which is why I took on co-chairing the Web Platform Incubation Community Group (or WICG for short). So I intend to continue to do what I can in order to make “getting involved” as painless a process as possible.

Like to watch 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 Scroll magazine.


The post Monday Profile: Yoav Weiss appeared first on Web Directions.

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