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

CSS Fragmentation L3 Last Call for Comments

Source: CSS WG Blog fantasai • 28 February 2015 06:23 PM

The CSS WG has published an updated Working Draft of the CSS Fragmentation Module Level 3. This module describes the fragmentation model that partitions a flow into pages, columns, or regions and provides controls for breaking.

We expect this to be the last WD before CR, and plan to transition at the end of March. Please review and send us any comments. If you plan to review but aren’t sure you have time, send us a note so that we know to wait for your comments.

We are particularly looking for feedback on

We are particularly looking for reviews from

We also welcome any submissions of better/more examples and diagrams.

As always, please send feedback to the (archived) public mailing list with the spec code ([css-break]) 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 2015-02-25

Source: CSS WG Blog Dael Jackson • 26 February 2015 12:39 AM

Full Minutes

Pointer Events W3C Recommendation, Interoperable Touch, and Removing the Dreaded 300ms Tap Delay

Source: IEBlog ieblog • 24 February 2015 06:20 PM

Today, the W3C published Pointer Events as a final Recommendation standard. This journey began a little over 2 years ago when we first submitted our proposal to the W3C for a common event model across pointing input devices. Since then, the spec has evolved and improved with the collaboration of Mozilla, Google, Opera, jQuery, IBM, Microsoft Open Technologies, and many others. Improvements have included better extensibility for new device types, additional configuration values for scrolling and zooming behavior, event constructors for synthesizing custom pointer events, and more.

We updated and unprefixed our implementation in IE11. With the addition of DOM event constructors in the new rendering engine in the Windows 10 Tech Preview, our implementation is now 100% compliant with the W3C test suite. We’re also excited to see Firefox builds with 100% pass rate now with work underway to ship this to users soon. Additionally, jQuery, Dojo, and other open source contributors are now maintaining a faithful polyfill called “PEP” and intend to use this in jQuery UI, jQuery Mobile, and Dojo. With the polyfill, it’s possible to code to pointer events across browsers today.

We also continue to see great interest from Web developers lobbying for other browsers to implement (Pointer Events has more stars on Chrome’s issue tracker than 99.6% of all other tickets, open or closed). So we’re hopeful that other browsers will join us in advancing interoperability here.

Beyond Pointer Events, we’re also getting ready to update our new rendering engine with additional improvements for touch interoperability. Here’s a few of the changes you can anticipate and what you can do to take advantage of them.

Improving Touch Performance by Removing the 300ms Tap Delay

When modern browsers first came to mobile devices, there was an interesting problem. How do you make sites designed for a big desktop monitor work on a tiny screen? As a result, mobile browsers scaled Web pages in a (complicated) way to make it fit better. The double-tap gesture was then introduced to quickly zoom in and out of relevant content.

This solution provided a reasonable experience for sites that aren’t optimized for mobile. However, it comes with a tradeoff. From the perspective of a gesture recognizer, any single tap could be followed by another making it a double-tap instead. So before committing to the action of a tap (e.g. navigating a link or clicking a button), the browser must pause for a moment to see if another tap is right behind it. This introduces a noticeable delay (300ms) when you’re just tapping to activate something. This problem has been well documented and many fixes or workarounds have been proposed, including the popular FastClick library and others.

Starting in IE10 (and now in Chrome, coming soon to Firefox), sites could disable double-tap zoom with the CSS touch-action property from Pointer Events:

.disable300msDelay {
touch-action: manipulation;

Additionally in IE11, if you disable zoom altogether in your viewport rule (e.g. user-scalable: no) then this also disables the 300ms delay.

Now in the new engine, setting a viewport rule with a width less than or equal to the device-width (a strong signal that you’re not a desktop site we need to optimize for small screens) will also disable the 300ms delay. This results in significant performance wins for mobile sites.

Touch Interop Improvements

We recognize that not all browsers support Pointer Events, and so for interoperability we added Touch Events to Windows Phone 8.1 Update. In a future update to Windows 10, we’ll be improving the support in a few ways based on site compatibility and defacto behavior. We’ll also provide toggles in about:flags to enable/disable these changes to aid developers with testing.

Remove MSPointer events – we deprecated the experimental vendor-prefixed version of pointer events, MSPointer, in IE11. Now that unprefixed pointer events have been shipping for a while, we’re ready to remove MSPointer from the platform. Sites should update to use the standardized unprefixed events.

Fire touchmove during scroll – in Windows Phone 8.1, IE11 would fire a touchcancel event whenever a pan gesture was detected and scrolling begins (ending the event stream for that touch). Chrome recently changed to closer match Safari and we’re joining them. Now, touchmove events will continue to fire (asynchronously) during a scroll.

Simplify mouse events for touch – all modern touch browsers synthesize mouse events for touch in order to be more compatible with sites designed only with mouse in mind. IE previously used a more advanced algorithm for generating these events. However, oddly enough, many sites that use touch events also use mouse events and expect those to follow the webkit model. In this new model, only a tap gesture will produce mouse events (and the events produced are a predefined sequence that all fire at once: mousemove, mousedown, mouseup, click).

Support Touch Events for more devices – we’ve talked before about the compatibility issues resulting from supporting touch events on devices with a mouse. We’ve been working on outreach to sites to be more compatible with browsers supporting touch events on these types of devices. As a step towards touch events on all devices (regardless of input capabilities), we’re rolling out behavior where touch events are enabled on any device (desktop, tablet, or phone) that has a touch screen, which is how Chrome works today. In about:flags, you’ll be able to override this for testing and enable/disable touch events on any device.

There's a lot of positive changes here and we’d love your help in testing them. Look for these changes and more in updates to the Windows 10 Technical Preview and RemoteIE soon. We look forward love to hearing your feedback via the Internet Explorer Platform Suggestion Box on UserVoice, @IEDevChat on Twitter, and in the comments below.

Jacob Rossi, Senior Program Manager, Project Spartan


Update (2/25/2015) - Google has closed public comments on their Pointer Events issue tracker (however, you can still star the issue).  We've reached out to Google for their preferred forum for web developers to provide feedback and we'll update this post when that becomes available.

Update 2 (2/25/2015) - Google has reopened comments 

60FPS is the new Image Replacement Technique

Source: Web Directions Blog John • 17 February 2015 03:31 AM

I always hated image replacement techniques. Not that I didn’t appreciate the cleverness of FIR, SiFR and the myriad other hacks folks developed to deliver text as images in an accessible way, so that we could use any fonts and typographical effects on our Web pages (at least sparingly).

But it always smelled wrong. So much effort for something which of course with the arrival of Web fonts became utterly redundant (and as it turns out a whole font we embed is probably smaller than a single image we used to send down for every heading on a page).

At least IR technique innovators tried heroically to make their techniques accessible. But underneath the techniques was this fundamental misunderstanding of what the Web was. We kept trying to turn it into paper. Because print design is inherently better, more capable than Web design.

In recent days, the concern du jour among designers and developers for the Web (and various lookers-on and pundits with various axes to grind) has been performance. Well, specifically getting 60FPS performance from animated UI experiences. Because somehow if we don’t get 60 frames per second of eye candy on our latest shiniest phones, the Web is broken, the sky is falling and so forth.

Indeed so horrendous is this shortcoming (of a platform which has reached more people, and supported more devices by perhaps an order of magnitude than any ever before, and likely any ever to come) that the choice by a single San Francisco based startup to (in the case solely of their Web application for mobile devices, their “normal” Web application uses traditional DOM based techniques) eschew the DOM for their own rendering engine using the canvasis a scathing condemnation of the DOM/CSS web standards stack”.

Look, I really should let Gruber’s [1] never ending focus on how native is inherently better, faster, whatever, than the Web go, but when someone so influential keeps it up, I can’t help myself.

Ironically, years ago, Gruber wrote about comparing Apples to Oranges. In it he wrote

The point of all this is that in some cases, some people seem unwilling to concede that any criteria other than the ones they themselves deem important actually matter, or even exist.

That’s dogmatism and the nature of dogma is such that it pretty much kills any reasonable discussion or debate.

60FPS being a “must have”, and any shortcoming right now dammit is to be scathingly condemned, while ignoring the enormous and extraordinary achievement of the technologies underlying the Web, as I mentioned reaching many more people, across a vastly greater diversity of platforms and devices than was even imaginable a decade ago, seems like ignoring more than a few criteria than “the ones deem[ed] important” by critics like John Gruber.

Now, do I wish these performance issues weren’t with us? Sure. Would I trade that performance for the interoperability, accessibility, universality of the Web. Is that even a question?

Because this is what we do when we obsess (and John Gruber is far from alone in this) about the performance of Web technologies for the particular use cases we have in mind (in the case of Flipboard, animating not all element transitions, but those that can’t be hardware accelerated, and smooth scrolling. Always the smooth scrolling).

We completely overlook what these poor benighted Web technologies have achieved, and enable you, and me, and 10 year old kids, and folks in Nairobi and well, a goodly chunk of the planets population to do.

So if John Gruber were to have said “man this stuff these guys at Flipboard have achieved in the browser is amazing, I wish they didn’t have to do these awful hacks and hopefully some folks at the W3C take notice” (because the folks on the W3C working groups responsible for this stuff and the developers of the browsers, it’s never occurred to them that maybe performance of rendering is an issue, or maybe they’re maliciously trying to hold the Web back?) I would have agreed with him. Well, at least not arced up, like I always do at this nonsense.

But no, it’s a “scathing indictment” of the DOM.

Sorry for the sarcasm, but this is a broken, broken record, where we fetishize a single shortcoming of the Web platform over its many unique strengths.

And it comes from a place of privilege and self indulgence, where our wants, our need for 60FPS on the latest shiney shiney device that will be the equivalent of an entry level device in 6 or 7 years time is the only defining factor. The Web is otherwise doomed.

Which is all fine and dandy for those of us who have the luxury or inclination or whatever of solely caring about people like us. But there’s a whole world of folks out there who’ve only just connected to the Web. Perhaps in half a decade they’ll get 60FPS on their devices. Perhaps not. Perhaps there are far bigger issues at stake?

OK, enough, I’m bookmarking this for the next time I see this nonsense is bandied around. Meantime for a far less sarcastic, overheated and far more sensible and lucid response to all this see Faruk Ateş and Christian Heilmann

[1] I actually think a lot of Gruber’s writing is thoughtful, just when it comes to this issue…

The post 60FPS is the new Image Replacement Technique appeared first on Web Directions.

WWW 2015, the 24th International World Wide Web Conference, …

Source: W3C's Cascading Style Sheets home page05 February 2015 02:01 PM

18 May 2015 WWW 2015, the 24th International World Wide Web Conference, will be held in Florence, Italy, May 18–22, 2015.

The I18N WG updated the Working Draft of Predefined Counter …

Source: W3C's Cascading Style Sheets home page03 February 2015 12:00 AM

3 Feb 2015 The I18N WG updated the Working Draft of Predefined Counter Styles

The CSS WG published a Candidate Recommendation of CSS Count…

Source: W3C's Cascading Style Sheets home page03 February 2015 12:00 AM

3 Feb 2015 The CSS WG published a Candidate Recommendation of CSS Counter Styles Level 3 and updated the Working Draft of CSS Positioned Layout Module Level 3

Bopomofo on the Web

Source: ishida blog » cssr12a • 29 January 2015 12:07 PM

Three bopomofo letters with tone mark.

Light tone mark in annotation.

A key issue for handling of bopomofo (zhùyīn fúhào) is the placement of tone marks. When bopomofo text runs vertically (either on its own, or as a phonetic annotation), some smarts are needed to display tone marks in the right place. This may also be required (though with different rules) for bopomofo when used horizontally for phonetic annotations (ie. above a base character), but not in all such cases. However, when bopomofo is written horizontally in any other situation (ie. when not written above a base character), the tone mark typically follows the last bopomofo letter in the syllable, with no special handling.

From time to time questions are raised on W3C mailing lists about how to implement phonetic annotations in bopomofo. Participants in these discussions need a good understanding of the various complexities of bopomofo rendering.

To help with that, I just uploaded a new Web page Bopomofo on the Web. The aim is to provide background information, and carry useful ideas from one discussion to the next. I also add some personal thoughts on implementation alternatives, given current data.

I intend to update the page from time to time, as new information becomes available.

Minutes Telecon 2015-01-28

Source: CSS WG Blog Dael Jackson • 29 January 2015 01:44 AM

Full Minutes

The CSS WG updated the Working Draft of CSS Fragmentation Mo…

Source: W3C's Cascading Style Sheets home page29 January 2015 12:00 AM

29 Jan 2015 The CSS WG updated the Working Draft of CSS Fragmentation Module Level 3

Updates for the F12 developer tools in the Windows 10 January Technical Preview

Source: IEBlog ieblog • 27 January 2015 11:00 PM

Last week, we shared the latest news for the Windows 10 Web platform and introduced Project Spartan, the browser built for Windows 10. In addition to building Project Spartan, we have been hard at work updating the Internet Explorer developer tools in Windows 10. Today we want to show you the latest enhancements, which are now available in the latest Windows 10 Technical Preview build. Going forward, we will bring these same enhancements to Project Spartan.

User interface

Last month, we modified the F12 tools navigation interface from a vertical layout to a text-based horizontal layout, removing the icons and replacing them with the tool’s names. This change is now part of the F12 developer tools for Windows 10 Technical Preview.

We have also added the capability to change the zoom level on the UI. Using the Ctrl + + and Ctrl + - keyboard shortcuts, you can now increase or decrease the zoom.

Changing zoom level in F12 Developer Tools


In response to your feedback, we added the ability to add XHR breakpoints. When enabled, the debugger will break whenever all the response data is available (readyState property equals 4). You can enable XHR breakpoints directly on the Breakpoints pane.

Setting XHR breakpoints on the Breakpoints pane

Once the XHR breakpoint is hit, you can use the call stack pane to investigate the resulting async call stack. In the example below, you can see the resulting async call stack of a simple XHR request and how it shows the frames in the context of the event handler. Selecting the initial frame takes you to the line of code who originated the call.

Async call stack of a simple XHR request

We have added CSS source maps support to the tools so that when using LESS or SASS to build our Web site or app, you can now view and navigate to the LESS or SASS source file directly, rather than the generated CSS file.

The tools will now display links to the original LESS or SASS files directly in the DOM Explorer tool.

DOM Explorer tool linking to the original LESS or SASS files

This support is enabled through a reference to the sourcemap’s path in the CSS file generated from the LESS or SASS compiler. To round-off the set of improvements in the Debugger tool, we extended the “Pretty Printing” functionality to also support HTML & CSS. To toggle the “Pretty Printing” formatting on the file, press the “Pretty Printing” button or use the Ctrl+Shift+P keyboard shortcut.


We have added a “View in DOM Explorer” feature to allow you to quickly move from a selected DOM element in the Console tool, to the actual node in the DOM Explorer. This is especially useful where the Console and DOM Explorer tools are used together as shown below.

One common feature request we received was for the ability to display network errors directly in the Console. As you can see below, we now log all the 4xx & 5xx type network errors directly in the Console tool. Like other Console errors, you'll see the error type and a message explaining the error. If you prefer not to see these, use the "error filter" to hide them.

Console now logs all 4xx & 5xx type network errors.

UI Responsiveness and Memory tools

In this preview, you will notice that the Profiler tool is no longer available. In our observations, we typically saw developers using the Profiler and the UI Responsiveness tools together, and having to move from one tool to the next. In response, we decided to make this workflow smoother by providing a more cohesive interface that combines both tools into one. Now the Profiler becomes the “JavaScript call stacks” tab inside the UI Responsiveness tool.

Profiler is now

We see the UI Responsiveness tool as the one stop for all your performance related needs. We’ll be covering the tool more deeply in the future but all the same great information that you have come to expect out of the previous UI Responsiveness tool can be found inside the Timeline tab and the “JavaScript call stacks” tab (image below) provides functionality similar to the old JavaScript profiler.

The same great information that you have come to expect out of the previous UI Responsiveness tool can be found inside the Timeline tab and the “JavaScript call stacks” tab (image below) provides functionality similar to the old JavaScript profiler.

Just as we did in the console, the UI Responsiveness and Memory tools also take advantage of the DOM Explorer integration. When you select an event that is logically associated with a DOM element (e.g. a DOM event handler, layout or style calculation), the associated element will be highlighted on the page, which makes it much easier to identify what occurred (e.g. which div element triggered a mouseover event).

If you want to view more details about the associated element such as the applied CSS rules, you can right-click it and select “Show in DOM Explorer” in order to navigate to the element in the DOM Explorer tool.

Example of navigation from the UI Responsiveness tool to an element in the DOM Explorer tool.

Additionally, CSS source maps are also supported in the UI Responsiveness and Memory tools too, so that you can link to and view the file in the debugger, as shown here.

Example of CSS source maps in the UI Responsiveness tool.

New Network Inspector

The preview comes with an entirely refreshed and updated Network tool. This tool not only has all the previous features in a cleaner, more easily understood way, but we’ve included many requests from developers, such as auto-start capturing and content type filtering.

Screencap of refreshed and updated Network tool.

Given its preview state, there is still more to come from the tool. Some examples are HAR export, timing information, Response payload “Pretty Printing” as well as reliability and overall refinements. We plan to talk more about the network tool soon, but in the meantime, we encourage you to take this preview build for a spin and provide as much feedback as you can!

Remember we value your feedback and we want to encourage you to continue providing suggestions, bugs, or requesting experiences you believe can make your daily development activities easier and more impactful. Let us know your thoughts about all the features announce today by leaving a comment below, reaching out on Twitter, or visiting our User Voice site to voice your opinion on what we should work on next!

— Ruben Rios, Program Manager, Internet Explorer

Project Spartan and the Windows 10 January Preview Build

Source: IEBlog ieblog • 22 January 2015 05:08 PM

Yesterday, we announced that Windows 10 will ship with a brand new browser, codenamed “Project Spartan.” Designed for Windows 10, Spartan provides a more interoperable, reliable, and discoverable experience with advanced features including the ability to annotate on web pages, a distraction-free reading experience, and integration of Cortana for finding and doing things online faster.

Project Spartan on Windows 10 desktop

Spartan is a single browser designed to work great across the entire Windows 10 device family - from keyboard and mouse on the Windows 10 desktop to touch, gestures, voice, controllers and sensors.

Project Spartan on Windows 10 phone with dark theme     Project Spartan on Windows 10 phone with light theme

Powered by a new rendering engine, Spartan is designed for interoperability with the modern web. We’ve deliberately moved away from the versioned document modes historically used in Internet Explorer, and now use the same markup as other modern browsers. Spartan’s new rendering engine is designed to work with the way the web is written today.

Like Windows 10 itself Spartan will remain up-to-date: as a service, both providing new platform capabilities, security and performance improvements, and ensuring web developers a consistent platform across Windows 10 devices. Spartan and the new rendering engine are truly evergreen.

Spartan provides compatibility with the millions of existing enterprise web sites designed for Internet Explorer. To achieve this, Spartan loads the IE11 engine for legacy enterprise web sites when needed, while using the new rendering engine for modern web sites. This approach provides both a strong compatibility guarantee for legacy enterprise web sites and a forward looking interoperable web standards promise.

We recognize some enterprises have legacy web sites that use older technologies designed only for Internet Explorer, such as custom ActiveX controls and Browser Helper Objects. For these users, Internet Explorer will also be available on Windows 10. Internet Explorer will use the same dual rendering engines as Spartan, ensuring web developers can consistently target the latest web standards.

Dual rendering engine architecture animation

What does this mean to web developers?

If you are building a public consumer-facing web site here’s what you need to know:

  1. Our new rendering engine will be the default engine for Windows 10, Spartan, and Internet Explorer. This engine has interoperability at its core and consumes the same markup you send other modern browsers. Our standards support and roadmap can be found at
  2. Public Internet web sites will be rendered using the new engine and modern standards, and legacy Internet Explorer behaviors including document modes are not supported in the new engine. If your web sites depends on legacy Internet Explorer behaviors we encourage you to update to modern standards.
  3. Our goal is interoperability with the modern web and we need your help! You can test the new engine via the Windows Insider Program or using Please let us know (via Connect or Twitter) when you find interoperability problems so we can work with the W3C and other browser manufacturers to ensure great interoperability.

New features and fixes in the January Insider Update

On Friday, we’re also rolling out a new preview build to Windows 10 Insiders. This new preview will also be available on RemoteIE soon. This build doesn’t have Project Spartan yet, but does have lots of updates to the new web rendering engine that Spartan will use. We started testing our new rendering engine by rolling it out to a portion of Insiders using the Windows Technical Preview in November.

Since that time, we’ve received over 12,000 feedback reports through the smiley face icon alone. This new build has over 2000 changes to the new platform, largely influenced by that feedback. In addition to many fixes, there are also several new platform features we are thrilled to be releasing in the updated preview:

Additionally, you’ll find updated F12 developer tools that include the updated UI we shipped to IE11 users last month as well as several new features and improvements. Here’s a few of our favorites:

New F12 network tools

With these improvements, we’re increasing the number of Insiders that get the new engine as we work towards this as the default for all users. If you’re curious and want to opt-in now, remember to navigate to about:flags and set “Enable Experimental Web Platform Features” to Enabled.

We’re excited to share our continued progress with you and to introduce Project Spartan to the Microsoft family. Please continue to share your feedback via Twitter, UserVoice (feature requests) and Connect (bug reports) and help shape our next browser. We’ll also be holding our next Twitter #AskIE session on Tuesday, January 27th from 10AM-12PM PST so you can ask questions to the team. See you there!

— Jason Weber, Group Program Manager, Internet Explorer

Minutes Telecon 2015-01-21

Source: CSS WG Blog Dael Jackson • 22 January 2015 02:10 AM

Full Minutes

Minutes Santa Clara F2F Part IV 2014-10-28: Fonts, Animations, Scrolling Effects and Primitives, Snap Points, Text

Source: CSS WG Blog Dael Jackson • 20 January 2015 05:11 PM


Full Minutes || Spec Referenced

Animations, Scrolling Effects and Primitives

Full Minutes || Spec Referenced

Snap Points

Full Minutes || Spec Referenced


Full Minutes || Spec Referenced

Bengali picker & character & script notes updated

Source: ishida blog » cssr12a • 18 January 2015 08:10 AM

Screen Shot 2015-01-18 at 07.42.56

Version 16 of the Bengali character picker is now available.

Other than a small rearrangement of the selection table, and the significant standard features that version 16 brings, this version adds the following:

For more information about the picker, see the notes at the bottom of the picker page.

In addition, I made a number of additions and changes to Bengali script notes (an overview of the Bengali script), and Bengali character notes (an annotated list of characters in the Bengali script).

About pickers: Pickers allow you to quickly create phrases in a script by clicking on Unicode characters arranged in a way that aids their identification. Pickers are likely to be most useful if you don’t know a script well enough to use the native keyboard. The arrangement of characters also makes it much more usable than a regular character map utility. See the list of available pickers.

CSS Pseudo-elements Level 4 First Public Working Draft

Source: CSS WG Blog fantasai • 15 January 2015 09:52 PM

The CSS Working Group has published an updated Working Draft of CSS Pseudo-elements Level 4. This module describes the syntax, styling, and inheritance/cascading models for each of the existing CSS pseudo elements, re-introduces ::selection (with a much more comprehensive description of how it’s supposed to work), and introduces a few new ones, such as ::placeholder.

This is a First Public Working Draft, and is in a somewhat rough state. Feedback is welcome, especially corrections. The ::selection section in particular could use a close review.

As always, please send feedback to the (archived) public mailing list with the spec code ([css-foo]) 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 2015-01-14

Source: CSS WG Blog Dael Jackson • 15 January 2015 02:03 AM

Full Minutes

Introducing the second Respond conference

Source: Web Directions Blog John • 14 January 2015 01:28 AM

Last year, in a whirlwind, we pulled together our first Respond conference, focussing on the broad challenges of contemporary Web design. It brought together one of our most diverse crowds, including many Art and Creative Directors, and many more strategic types than we expected. We designed the day as something of a symposium, with a mixture of presentations from both international experts, and local practitioners, alongside Q&A sessions, which went extremely well, and were one of the high points of the day.

to kick off 2015, we’ve just taken the wraps off our second Respond conference. Based on last year’s feedback, were continuing the symposium feel, with an intimate venue, and plenty of time for conversation and Q&A.

Our goal as always with all our events to to carefully curate the content to address what we feel are the most pressing concerns right now when it comes to responsive web design. And to this end we’ve brought together a fantastic lineup from around the world, as well as wonderful local experts, including

As always with the Web, quite a bit has changed in the last 12 months. We’re here to help you keep up to date with those changes, and to help you build better, more effective solutions.

We look forward to you joining the conversation, in Sydney, March 19 (for the conference) and 20 (for Andrew’s Workshop). And if you can’t make Sydney, Andrew is visiting Melbourne on March 25th, Brisbane on March 27th, and Perth March 31.

The post Introducing the second Respond conference appeared first on Web Directions.

Initial letter styling in CSS

Source: W3C i18n and cssr12a • 13 January 2015 12:13 PM


The CSS WG needs advice on initial letter styling in non-Latin scripts, ie. enlarged letters or syllables at the start of a paragraph like those shown in the picture. Most of the current content of the recently published Working Draft, CSS Inline Layout Module Level 3 is about styling of initial letters, but the editors need to ensure that they have covered the needs of users of non-Latin scripts.

The spec currently describes drop, sunken and raised initial characters, and allows you to manipulate them using the initial-letter and the initial-letter-align properties. You can apply those properties to text selected by ::first-letter, or to the first child of a block (such as a span).

The editors are looking for

any examples of drop initials in non-western scripts, especially Arabic and Indic scripts.

I have scanned some examples from newspapers (so, not high quality print).

In the section about initial-letter-align the spec says:

Input from those knowledgeable about non-Western typographic traditions would be very helpful in describing the appropriate alignments. More values may be required for this property.

Do you have detailed information about initial letter styling in a non-Latin script that you can contribute? If so, please write to (how to subscribe).

The CSS WG published a Candidate Recommendation of Compositi…

Source: W3C's Cascading Style Sheets home page13 January 2015 12:00 AM

13 Jan 2015 The CSS WG published a Candidate Recommendation of Compositing and Blending Level 1, updated the Working Draft of CSS Exclusions Module Level 1 and published the first draft of CSS Pseudo-Elements Module Level 4

Minutes Telecon 2015-01-07

Source: CSS WG Blog Dael Jackson • 08 January 2015 11:51 AM

Full Minutes

The Combining Character Conundrum

Source: ishida blog » cssr12a • 06 January 2015 05:28 PM

I’m struggling to show combining characters on a page in a consistent way across browsers.

For example, while laying out my pickers, I want users to be able to click on a representation of a character to add it to the output field. In the past I resorted to pictures of the characters, but now that webfonts are available, I want to replace those with font glyphs. (That makes for much smaller and more flexible pages.)

Take the Bengali picker that I’m currently working on. I’d like to end up with something like this:


I put a no-break space before each combining character, to give it some width, and because that’s what the Unicode Standard recommends (p60, Exhibiting Nonspacing Marks in Isolation). The result is close to what I was looking for in Chrome and Safari except that you can see a gap for the nbsp to the left.


But in IE and Firefox I get this:


This is especially problematic since it messes up the overall layout, but in some cases it also causes text to overlap.

I tried using a dotted circle Unicode character, instead of the no-break space. On Firefox this looked ok, but on Chrome it resulted in two dotted circles per combining character.

I considered using a consonant as the base character. It would work ok, but it would possibly widen the overall space needed (not ideal) and would make it harder to spot a combining character by shape. I tried putting a span around the base character to grey it out, but the various browsers reacted differently to the span. Vowel signs that appear on both sides of the base character no longer worked – the vowel sign appeared after. In other cases, the grey of the base character was inherited by the whole grapheme, regardless of the fact that the combining character was outside the span. (Here are some examples ে and ো.)

In the end, I settled for no preceding base character at all. The combining character was the first thing in the table cell or span that surrounded it. This gave the desired result for the font I had been using, albeit that I needed to tweak the occasional character with padding to move it slightly to the right.

On the other hand, this was not to be a complete solution either. Whereas most of the fonts I planned to use produce the dotted circle in these conditions, one of my favourites (SolaimanLipi) doesn’t produce it. This leads to significant problems, since many combining characters appear far to the left, and in some cases it is not possible to click on them, in others you have to locate a blank space somewhere to the right and click on that. Not at all satisfactory.


I couldn’t find a better way to solve the problem, however, and since there were several Bengali fonts to choose from that did produce dotted circles, I settled for that as the best of a bad lot.

However, then i turned my attention to other pickers and tried the same solution. I found that only one of the many Thai fonts I tried for the Thai picker produced the dotted circles. So the approach here would have to be different. For Khmer, the main Windows font (Daunpenh) produced dotted circles only for some of the combining characters in Internet Explorer. And on Chrome, a sequence of two combining characters, one after the other, produced two dotted circles…

I suspect that I’ll need to choose an approach for each picker based on what fonts are available, and perhaps provide an option to insert or remove base characters before combining characters when someone wants to use a different font.

It would be nice to standardise behaviour here, and to do so in a way that involves the no-break space, as described in the Unicode Standard, or some other base character such as – why not? – the dotted circle itself. I assume that the fix for this would have to be handled by the browser, since there are already many font cats out of the bag.

Does anyone have an alternate solution? I thought I heard someone at the last Unicode conference mention some way of controlling the behaviour of dotted circles via some script or font setting…?

Update: See Marc Durdin’s blog for more on this topic, and his experiences while trying to design on-screen keyboards for Lao and other scripts.

Khmer character picker v16

Source: ishida blog » cssr12a • 05 January 2015 10:12 AM


I have uploaded a new version of the Khmer character picker.

The new version uses characters instead of images for the selection table, making it faster to load and more flexible. If you prefer, you can still access the previous version.

Other than a small rearrangement of the default selection table to accomodate fonts rather than images, and the significant standard features that version 16 brings, there are no additional changes in this version.

For more information about the picker, see the notes at the bottom of the picker page.

About pickers: Pickers allow you to quickly create phrases in a script by clicking on Unicode characters arranged in a way that aids their identification. Pickers are likely to be most useful if you don’t know a script well enough to use the native keyboard. The arrangement of characters also makes it much more usable than a regular character map utility. See the list of available pickers.

Devanagari, Gurmukhi & Uighur pickers available

Source: ishida blog » cssr12a • 05 January 2015 09:45 AM




I have updated the Devanagari picker, the Gurmukhi picker and the Uighur picker to version 16.

You may have spotted a previous, unannounced, version of the Devanagari and Uighur pickers on the site, but essentially these versions should be treated as new. The Gurmukhi picker has been updated from a very old version.

In addition to the standard features that version 16 of the character pickers brings, things to note include the addition of hints for all pickers, and automated transcription from Devanagari to ISO 15919, and vice versa for the Devanagari picker.

For more information about the pickers, see the notes at the bottom of the relevant picker page.

About pickers: Pickers allow you to quickly create phrases in a script by clicking on Unicode characters arranged in a way that aids their identification. Pickers are likely to be most useful if you don’t know a script well enough to use the native keyboard. The arrangement of characters also makes it much more usable than a regular character map utility. See the list of available pickers.

More picker changes: Version 16

Source: ishida blog » cssr12a • 04 January 2015 12:53 PM

A couple of posts ago I mentioned that I had updated the Thai picker to version 16. I have now updated a few more. For ease of reference, I will list here the main changes between version 16 pickers and previous versions back to version 12.

Minutes Santa Clara F2F Part III 2014-10-28: Zoom Effects, Flexbox, :role(), Selectors 4, Fragmentations, Transforms, Text, Selections, Counter Styles

Source: CSS WG Blog Dael Jackson • 02 January 2015 03:52 PM

Zoom Effects

Full Minutes


Full Minutes || Spec Referenced


Full Minutes || Spec Referenced

Selectors 4

Full Minutes || Spec Referenced


Full Minutes || Spec Referenced


Full Minutes || Spec Referenced


Full Minutes || Spec Referenced


Full Minutes || Spec Referenced

Counter Styles

Full Minutes || Spec Referenced

Language Subtag Lookup tool updated

Source: ishida blog » cssr12a • 26 December 2014 08:11 AM

This update to the Language Subtag Lookup tool brings back the Check function that had been out of action since last January. The code had to be pretty much completely rewritten to migrate it from the original PHP. In the process, I added support for extension and private use tags, and added several more checks. I also made various changes to the way the results are displayed.

Give it a try with this rather complicated, but valid language tag: zh-cmn-latn-CN-pinyin-fonipa-u-co-phonebk-x-mytag-yourtag

Or try this rather badly conceived language tag, to see some error messages: mena-fr-latn-fonipa-biske-x-mylongtag-x-shorter

The IANA database information is up-to-date. The tool currently supports the IANA Subtag registry of 2014-12-17. It reports subtags for 8,081 languages, 228 extlangs, 174 scripts, 301 regions, 68 variants, and 26 grandfathered subtags.

CSS Box Alignment Level 3 Updated

Source: CSS WG Blog fantasai • 19 December 2014 09:48 PM

The CSSWG has published an updated Working Draft of CSS Box Alignment Level 3. This module defines extends the Flexbox alignment properties to apply to all layout models and adds additional controls for logical positioning, space distribution, and handling overflowing elements.

This is the vertical centering module, people.

This module’s syntax and functionality is in the process of stabilizing now and we need your feedback. Think of all the cool things you could do with the new alignment properties! Imagine them! Examine them! Make examples! Write rants! And tell us what is awesome and what is stupid so that we can fix it to be better before it gets locked down in shipped browsers.

Changes since the last Working Draft are listed in the Changes section.

As always, ideally send feedback to the (archived) public mailing list with the spec code ([css-align]) and your comment topic in the subject line. Alternatively, post your comment here or in the more discussion-friendly cross-post. (Or, if that’s still too scary, email the editors directly.) Please do not expect us to go fishing for your comments in the ether. We won’t know it’s there and we will therefore deliberately and mercilessly ignore it. If it’s on your blog, email the link or post it as a comment. It’s super not that hard. Thanks.

CSS Box Alignment Level 3 Updated

Source: CSS3 . Infofantasai • 19 December 2014 06:45 PM

The CSSWG has published an updated Working Draft of CSS Box Alignment Level 3. This module extends the Flexbox alignment properties to apply to all layout models and adds additional controls for logical positioning, space distribution, and handling overflowing elements. This is the vertical centering module, people. This module’s syntax and functionality is in the […]

This week: CSP for Gmail, CSS1 is 18 years old, W3C CEO on after HTML5, etc.

Source: W3C Blog Coralie Mercier • 19 December 2014 04:20 PM

This is the 12-19 December 2014 edition -the last of the year 2014- of a “weekly digest of W3C news and trends” that I prepare for the W3C Membership and public-w3c-digest mailing list (publicly archived). This digest aggregates information about W3C and W3C technology from online media —a snapshot of how W3C and its work is perceived in online media.

W3C and HTML5 related Twitter trends

[What was tweeted frequently, or caught my attention. Most recent first]

Open Web

W3C in the Press (or blogs)

5 articles since the last Digest; a selection follows. You may read all articles in our Press Clippings page.


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.


Made with CSS! Valid CSS!Valid HTML 4.0! RSS feed Atom feed