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-11-30

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

Full Minutes

Minutes Telecon 2016-11-23

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

Full Minutes

Efficient representation for Web formats

Source: W3C Blog • Daniel Peintner • 22 November 2016

EXI is a format that sends an efficient data stream of parse events that can have noticeable, measurable savings in CPU, memory and bandwidth. Test results have consistently shown EXI advantages for XML, HTML, and now CSS/JavaScript minify, over gzip and zip formats. You may want to look at EXI overview presentation for CSS.

Since the start of the EXI Working Group, the focus of group members has been to make XML interchange more efficient. Participants plan to further continue this effort by making improvements to what has been achieved by EXI and its related specifications. We are now exploring how to consistently apply EXI approaches to other Web formats besides XML.

The acronym “EXI” now stands for “Efficient Extensible Interchange” instead of “Efficient XML Interchange.” This adjustment indicates that EXI is not only useful for XML documents, but improves compactness and performance across many Web technologies.

We encourage everyone to take a look at how EXI for JSON,  EXI for CSS, and EXI for JavaScript work.  All comments are of interest.  We are looking to

Multiple EXI implementations are available.  Public participation and feedback are welcome!  Send a comment to EXI participants through the [email protected] mailing list or leave a comment here in the blog. Thanks for considering these possibilities for the Web.

Minutes Telecon 2016-11-16

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

Release Notes for Safari Technology Preview 18

Source: Surfin' Safari • Jon Davis • 16 November 2016

Safari Technology Preview Release 18 is now available for download for macOS Sierra. If you already have Safari Technology Preview installed, you can update from the Mac App Store’s Updates tab. This release covers WebKit revisions 208261–208427.

Input Events

JavaScript

Shadow DOM

Web Inspector

CSS

Rendering

Indexed Database 2.0

Accessibility

Printing

HTTP Authentication

Web APIs

Release Notes for Safari Technology Preview 17

Source: Surfin' Safari • Jon Davis • 09 November 2016

Safari Technology Preview Release 17 is now available for download for macOS Sierra. If you already have Safari Technology Preview installed, you can update from the Mac App Store’s Updates tab. This release covers WebKit revisions 207669–208261.

Safari Extensions

Custom Elements

Web APIs

Input Events

URL Parser

Fetch API

JavaScript

Web Inspector

CSS

Media

Networking

Indexed Database 2.0

Bug Fixes

Variable Fonts on the Web

Source: Surfin' Safari • Myles Maxfield • 08 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].

The CSS Intro course, written by W3C and Microsoft, is part …

Source: W3C's Cascading Style Sheets home page • 07 November 2016

7 Nov 2016 The CSS Intro course, written by W3C and Microsoft, is part of W3Cx, a collection of MOOCs created by W3C in cooperation with its members.

The CSS Intro course is a MOOC by W3C and Microsoft in weekl…

Source: W3C's Cascading Style Sheets home page • 07 November 2016

7 Nov 2016 The CSS Intro course is a MOOC by W3C and Microsoft in weekly installments. The first module is open since November 7. Enrollment is free and students can start at any time.

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

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.

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