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 2015-03-11 • 12 March 2015 12:14 AM
• WWW 2015, the 24th International World Wide Web Conference, … • 10 March 2015 09:01 PM
• The CSS WG updated the Working Draft of CSS Basic User Inter… • 10 March 2015 12:00 AM
• Socialising and (not just) alcohol at Web Industry events • 09 March 2015 04:49 AM
• Minutes Telecon 2015-03-04 • 05 March 2015 01:45 AM
• CSS Fragmentation L3 Last Call for Comments • 28 February 2015 06:23 PM
• Minutes Telecon 2015-02-25 • 26 February 2015 12:39 AM
• Pointer Events W3C Recommendation, Interoperable Touch, and Removing the Dreaded 300ms Tap Delay • 24 February 2015 06:20 PM
• The CSS WG updated the Working Draft of CSS Basic User Inter… • 24 February 2015 12:00 AM
• 60FPS is the new Image Replacement Technique • 17 February 2015 03:31 AM
• The I18N WG updated the Working Draft of Predefined Counter … • 03 February 2015 12:00 AM
• The CSS WG published a Candidate Recommendation of CSS Count… • 03 February 2015 12:00 AM
• Bopomofo on the Web • 29 January 2015 12:07 PM
• Minutes Telecon 2015-01-28 • 29 January 2015 01:44 AM
• The CSS WG updated the Working Draft of CSS Fragmentation Mo… • 29 January 2015 12:00 AM
• Updates for the F12 developer tools in the Windows 10 January Technical Preview • 27 January 2015 11:00 PM
• Project Spartan and the Windows 10 January Preview Build • 22 January 2015 05:08 PM
• Minutes Telecon 2015-01-21 • 22 January 2015 02:10 AM
• Minutes Santa Clara F2F Part IV 2014-10-28: Fonts, Animations, Scrolling Effects and Primitives, Snap Points, Text • 20 January 2015 05:11 PM
• Bengali picker & character & script notes updated • 18 January 2015 08:10 AM
• CSS Pseudo-elements Level 4 First Public Working Draft • 15 January 2015 09:52 PM
• Minutes Telecon 2015-01-14 • 15 January 2015 02:03 AM
• Introducing the second Respond conference • 14 January 2015 01:28 AM
• Initial letter styling in CSS • 13 January 2015 12:13 PM
• The CSS WG published a Candidate Recommendation of Compositi… • 13 January 2015 12:00 AM
• Minutes Telecon 2015-01-07 • 08 January 2015 11:51 AM
• The Combining Character Conundrum • 06 January 2015 05:28 PM
• Khmer character picker v16 • 05 January 2015 10:12 AM
• Devanagari, Gurmukhi & Uighur pickers available • 05 January 2015 09:45 AM
• More picker changes: Version 16 • 04 January 2015 12:53 PM
• [List of feeds]

Minutes Telecon 2015-03-11

• Resolved: Don’t add a property to hide scrollbars at this time.
• Florian brought up the two different allowed implementations of pre-wrap in the CSS Text spec and his belief that it’s confusing to have two different behaviors and that neither of the spec’ed behaviors may meet author expectations. Everyone spent time with the examples and comparing them to text editors and word processing software to determine if there really is an expected behavior. None of the implementors had an interest in changing their version and the group wasn’t convinced this is necessary given that most editing on the web is done with custom code.
• Resolved: Add the trailing-spaces value to text-decoration-skip.
• It was agreed that, though the proposal to create special word-break rules for Korean (available here) was possible, it wasn’t necessary as feedback from Koreans has been that the current default is acceptable behavior.

Full Minutes

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

The CSS WG updated the Working Draft of CSS Basic User Inter…

Socialising and (not just) alcohol at Web Industry events

Certainly in Australia and in my experience in other English speaking countries, and I’d hazard a guess in many countries of European tradition, we tend to socialise with alcohol. Whether it’s purely social, or a professional event after work hours, alcohol is expected, and of course by most, if consumed, then consumed responsibly.

But not everyone is comfortable drinking, or drinks every time they go out, or drinks at all. And not everyone may be entirely comfortable as the evening wears on, and some get the worse for wear.

Having run many many events over the last decade, we’ve always tried to create an environment that was safe and inclusive, as well as fun and engaging. And often (only after hours of course) this has involved serving alcohol.

We limit it to wine and beer, and we’ve also always made sure there are options for those who aren’t drinking (I often don’t drink at all myself, with on many occasions a long drive home at the end of a long day). We try to ensure everyone is a first class citizen at our events.

But this year, we’ve decided to really do something more, and make not having a drink no less appealing than a glass wine or a beer. How so?

The Urban Dictionary describes programmers as “an organism capable of converting caffeine into code”. If you’ve attended a recent event of ours, you’ll know we go out of our way to make sure there’s great espresso coffee. But we’re talking this a step further.

At every event we hold, or host (we host numerous events at our HQ, including SydCSS, Hover and IoTSydney) we’ll be serving fantastic hot filter (courtesy of our brand new Mocca Master filter coffee maker), cold brew coffee (if you’ve not tried good cold brew, then you’ve been missing out) and maybe even the odd Aeropress cup if you can twist my arm to make you one. The beans will be freshly ground, and world class, thanks to our friends Sample Coffee. And we’ll make sure there’s decaf for those who (like me), love the whole coffee experience but can sometimes over indulge in the caffeine.

Most importantly, all this is thanks to our wonderful friends at Campaign Monitor. A great Australian success story, a great supporter of Web Directions, and frankly the best email campaign software there is.

The post Socialising and (not just) alcohol at Web Industry events appeared first on Web Directions.

Minutes Telecon 2015-03-04

• Resolved: Publish a new working draft of CSS Grid.
• Resolved: TabAtkins and dbaron are co-editors for Animations.
• Resolved: Do not change the current Flexbox spec for now knowing the compat risk with the change in abspos handling.
• Resolved: Publish a new WD for CSS3 UI.
• Everyone, especially implementors, were actioned to review Florian’s proposal (available here) for a more precise description of how box-sizing works. There will be three weeks to review the proposal before the issue is revisited.
• There was a conversation about potentially reverting vertical percentage padding/margin to match block. The argument for reverting was for consistency in the odd things about CSS so people only have to learn a weird rule, not a weird rule and its exceptions. The argument against reverting was to allow grid and flexbox to work in a way that was more intuitive to app developers that are relying on these tools. A compromise was raised to create a switch, such as creating ph and pw, so that authors can choose their behavior of choice instead of forcing one group or the other to think outside their desired approach. This idea met with favor. The implementors will hold a conversation to find out more about who is willing to implement what while discussion continues on the mailing list to further flesh out people’s opinions and proposals.
• Resolved: We keep selectors not in the fast profile and not implemented as invalid and we clarify it in the spec.

Full Minutes

CSS Fragmentation L3 Last Call for Comments

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

• Which rules are dropped when breaks are overconstrained.
• Anything that appears to be insufficiently specified or explained.

We are particularly looking for reviews from

• Anyone who makes a print or PDF output implementation.
• Anyone who makes an eBook implementation.
• Anyone who authors documents for such implementations.

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

As always, please send feedback to the (archived) public mailing list www-style@w3.org 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

• Everyone should review the proposal for WebVTT from the VTT Working Group and send comments to the email thread.
• Everyone present thought the change to abspos was still the right thing and that more implementors need to make the change. Further discussion on the topic was deferred until next week when more implementors are on the call.
• Florian requested that everyone look over his proposed solution to issue 69 of CSS3 UI.
• Resolved: Add some normative text to make it explicit that the stacking of focus outline is left to the implementor to provide better user experience.
• Resolved: Tighten the language of the directional focus property behavior and include an informative note about the behaviors we’re considering and welcome/actively solicit input.
• Resolved: Add @supports to Cascade Level 4
• Resolved: Create an Editor’s Draft for Cascade Level 4
• Resolved: Properties referencing corners drop the axis mentions and go into the block axis first, for example border-start-end-radius (in CSS Logical Properties)

Full Minutes

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

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:

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 

The CSS WG updated the Working Draft of CSS Basic User Inter…

60FPS is the new Image Replacement Technique

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 canvas “is 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.

The I18N WG updated the Working Draft of Predefined Counter …

The CSS WG published a Candidate Recommendation of CSS Count…

Bopomofo on the Web

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

• dbaron asked that everyone review the Transitions editor’s draft since he hopes to bring it up for publication at the F2F.
• Since both chairs, and likely many others, will be traveling next Wednesday (4 Feb.), there will be no telecon.
• Everyone was reminded to add items to the wiki for discussion in Sydney.
• Resolved: Turn the old roadmap into a 301 redirect to /TR/CSS and discuss updating /TR/CSS at the F2F
• Resolved: Use content as the new value for flex-basis
• TabAktins explained his rational for in Flexbox creating no-wrap as an alias to nowrap to alleviate author confusion. However, the group remained unconvinced as to if it was the best way forward. This issue will remain open while the group explores more possibilities and looks for more information.
• The remaining Flexbox issues still need some work and/or understanding before they’re ready for the group, though they should be ready by the F2F.
• fantasai brought her proposal for extending the break-* properties to control inline layout. It received a warm reception as an idea worth exploring.
• The text-wrap: balance proposal was also well received with a lot of people showing interest in developing it further.
• fantasai stated that she and astearns will be bringing their unofficial editor’s draft for CSS4 Text to the group shortly to formalize it.
• Resolved: Change the ‘must’ into a ‘should’ and remove the reference to “may ignore” for issue 38 of CSS3 UI
• Resolved: Document ime-mode as obsolete as described in the draft of CSS3 UI
• There was discussion on changing the language for ime-mode to say browsers “should not” support, however that wasn’t resolved upon so the previously resolved upon publication will go forward with the existing language and the “should not” language will wait for a formal resolution.

Full Minutes

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

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

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.

Debugger

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.

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.

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.

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.

Console

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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 http://status.modern.ie.
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 http://remote.modern.ie. 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:

• HTTP Strict Transport Security (HSTS)—an HTTP header to inform the browser to always request a given domain over SSL, reducing MITM attack surface area.
• HTTP Live Streaming (HLS) and Dynamic Adaptive Streaming over HTTP (DASH) –expands our plugin-free adaptive video streaming to support the popular HLS and DASH protocols.
• Video Tracks — adds the ability to get information about multiple video tracks, and switch between them using the VideoTrack.selected attributes.
• DOM L3 XPath – initial support for accessing the DOM tree using the XPath syntax. Expanded support will come in a future release.

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 and Improved Network Tool—capture and debug network traffic with new UX and capabilities, such as auto-start, a content type filter, and error highlighting.
• HTML & CSS Pretty Printing—just as you’ve been able to nicely reformat minified JavaScript in the debugger, you’ll now be able to do this for HTML and CSS.
• Async Callstacks for Events and Timers—quickly view the “async callstack” to connect the dots between event dispatch and the original addEventListener call or between setting a timer and the timer being fired.
• Sourcemaps for Styles and in the Memory Profiler—jump to your original sources, such as TypeScript or SASS, directly from the Styles pane or Memory Profiler tools.
• Find Reference and Go To Definition—jump directly to a function call’s definition or find the references to a given variable.

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

• BCampbell brought his revised proposal for addressing the accessibility concerns created when Flexbox changes the visual order of the boxes and the tab order. The new proposal is to create a method for authors to designate if the order is important so that only those items with the important signifier will have their tab order changed in line with the visual order.
  • There were several questions about the implications of the proposal and clarifications about if a change is even needed.
  • Another suggestion what the the directional nav-* properties from CSS3 UI might help address some of the issues.
  • Several people brought up that this issue seems larger than just Flexbox and has been around since early CSS.
  • It was agreed that this topic would be best solved at a F2F meeting. bcampbell said he’d try and make it to Sydney, but likely it would have to wait until NYC in May.
• Resolved: align-content and justify-content on grid containers operate on the grid tracks (allows distributing extra space between grid tracks)
• Resolved: Publish a new working draft of CSS3 UI
  • tantek will make note of the outstanding issues and objections in the working draft so that they’re a part of the publication
• Resolved: Accept the proposed change for the serialization order for final-bg-color (available here)
• fantasai brought her and dauwhe’s potential solutions for when a float is interacting with an initial letter in Inline. SteveZ raised an alternate proposal that he thought might handle the problem a bit better. Several people were unsure as to which proposal is best without visual examples, so this topic was also declared a good fit for the F2F in February.

Full Minutes

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

Fonts

• The expressed desire to have Kai classified as a cursive font from the Chinese publishing group as a way to distinguish that is is a different style garnered a lot of mixed thoughts and concern that the group didn’t have the expertise to make the right decision.
• There was also concern that Kai isn’t widely downloaded as a font and more research is needed to see if it’s common in devices marketed to a Chinese-speaking population.
• Resolved: Topic (above) goes back to the mailing list to find a good solution
• Resolved: Only download a single font per family when unicode-range values overlap
• Google’s proposal for a timeout function for font downloading was discussed and fleshed out further.
  • A better definition of when timeout occurs needs to be created.
  • This also needs to be optional when only the real font will do, such as icon fonts.
  • There was neither full opposition or support, so discussion will continue on the mailing list.
• Resolved: Start editor’s draft of CSS4 Fonts

Full Minutes || Spec Referenced

Animations, Scrolling Effects and Primitives

• Resolved: start work on Animations level 2
• Additive Animation will be a part of Animations level 2.
• Using Animations to smooth out scrolling effects had a lot of support and there was substantial feedback to be put in a more concrete linguistic proposal.
  • One expressed concern was that scroll effects need to be able to be turned off by the user.
  • rbyers presented his proposal to create a set of primitives in order to allow developers the ability to be innovative in their designs without resorting to building mobile-native apps. In specific, he proposed:
    • scroll-delay which lets you do anything on the main thread, with sync
    • beforescroll which lets you just intercept scrolls – you get an event when there’s a “scroll intention” from the user
  • volick also presented his set of proposals and there was a lot of interest in potentially being able to control a bunch of animations with UI Worker, which lets you do some things on the scroll thread, with synchronization.

Full Minutes || Spec Referenced

Snap Points

• The group reviewed progress on Snap Points. Discussed some concerns over:
  • behavior at the start/end of a scroller
  • travelling past multiple snap points during scroll gesture/animation
  • graceful degradation on smaller-than-expected screen sizes
• Resolved: Publish FPWD of Snap Points

Full Minutes || Spec Referenced

Text

• Discussed options for specifying justification behavior for untagged content.
• Resolved: No examples of justification algorithm for text-justify: auto
• Resolved: Link to a wiki or NOTE collating information about language-specific justification conventions.

Full Minutes || Spec Referenced

Bengali picker & character & script notes updated

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:

• three new buttons for automatic transcription between latin and bengali. You can use these buttons to transcribe to and from latin transcriptions using ISO 15919 or Radice approaches.
• hinting to help identify similar characters.
• the ability to select the base character for the display of combining characters in the selection table.

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

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 www-style@w3.org 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

• Resolved: Add Tamil back to Counter Styles spec
• The discussion of order affecting tab order and speech order in Flexbox will wait until Bo Campbell is on the call.
• Resolved: Re-add the mandatory minimum of one million tracks to Grid for repeat()
• Resolved: Drop the stack value from Grid
• Resolved: Allow “auto” in minmax() for Grid, have it look at min-width/height for value, using same “auto” behavior as Flexbox
• Resolved: Accept repeat(auto, ...) syntax for Grid
• Deferring on a decision about justifying grid tracks to give a chance to consider the implications.
• Resolved: Unprefix min/max-content keywords
• Resolved: Require quoting :lang() values as a string if they have asterisks
• There was some concerns about the implications of the change regarding ‘direction’ propagation from body, but due to the limited amount of time remaining on the call, nothing was resolved or decided.

Full Minutes

Introducing the second Respond conference

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

• Scott Jehl, author of the recent Responsible Responsive Design from A Book Apart. Scott worked alongside Ethan Marcotte to deliver the groundbreaking Boston Globe responsive redesign. Few people are more knowledgeable about this whole area than Scott, and we’re excited and privileged to have him here.
• Andrew Clarke will be known to many in our audience. He’s come to Australia to speak at various events for us a number of times, he’s the author of several significant books on Web design, and has worked for some extraordinary clients. Not only keynoting, Andrew will be delivering his new CSS3 for Responsive Design workshop as well.
• Yesenia Pere-Cruz may not be as immediately well known as Scott and Andrew, but she’s deeply experienced, having worked with legendary agencies like Jeffrey Zeldman’s Happy Cog, non prestigious global sites for the likes of MTV. Her focus is an area we consider one of this year’s biggest issues, the intersection of Design and performance. While what happens on the screen has long been one of the primary areas of focus when we design across devices, since so much traffic increasingly happens over mobile networks, which are intrinsically slower than typical fixed networks, and on mobile devices, which also has a significant performance implication, how we design is increasingly a key to getting the best possible performance.
• Kris Howard from Mi9 on the implications of 3rd party content like ads for modern responsive sites
• Nabeelah Ali fron Atlassian on responsive typography
• Felicity Evans from Fairfax Media on responsive workflows
• Simon Elvery from the ABC on the ever challenging issue of images and responsive design
• Ben Buchanan from Ansarada on the dilemma of using responsive frameworks or rolling your own
• Peter Wilson on making the case for, and selling a responsive approach to clients or internally

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

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 www-style@w3.org (how to subscribe).

The CSS WG published a Candidate Recommendation of Compositi…

Minutes Telecon 2015-01-07

• Resolved: Meet 18, 19, 20 of May in NYC hosted by Bloomberg
• Everyone received an action to post topics for the meeting in Sydney on the wiki for the F2F
• Resolved: Publish with the Pseudo-Elements draft as-is, noting that what’s there for the OM is just some ideas as a starting point for discussion
• Resolved: keep ::grammar-error and ::spelling-error in the Pseudo-Elements draft
• Resolved: Publish FPWD of CSS Pseudo-Elements
• fantasai will put her proposal for having descendants of p::selection inherit the style into the spec.
• Everyone received an action to review the wiki tracking Flexbox accessibility concerns created by bcampbell in order to discuss it next week.
• Resolved: For CSS3 UI we intend ‘auto’ to cover behaviors that can’t be described by other styles in the UA style sheet, and we want to define it more precisely, but we need to work out on the list what that definition should be
• There didn’t seem to be much interest in implementing ::value and ::choices in the near future from implementors, however the group will wait on a formal write-up for ::placeholder before deciding on if ::value and ::choices should be moved to Pseudo-Elements from CSS3 UI.

Full Minutes

The Combining Character Conundrum

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

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

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

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.

• Fonts rather than graphics. The main selection table in version 12 used images to represent characters. These have now gone, in favour of fonts. Most pickers include a web font download to ensure that you will see the characters. This reduces the size and download time significantly when you open a picker. Other source code changes have reduced the size of the files even further, so that the main file is typically only a small fraction of the size it was in version 14.

  It is also now possible, in version 16, to change the font of the main selection table and the font size.

• UI. The whole look and feel of the user interface has changed from version 14 onwards, and includes useful links and explanations off the top of the normal work space.

  In particular, the vertical menu, introduced in version 14, has been adjusted so that input features can be turned on and off independently, and new panels appear alongside the others, rather than toggling the view from one mode to another. So, for example, you can have hints and shape-based selectors turned on at the same time. When something is switched on, its label in the menu turns orange, and the full text of the option is followed by a check mark.

• Transcription panels. Some pickers had one or more transcription views in versions below 16. These enable you to construct some non-Latin text when working from a Latin transcription. In version 16 these alternate views are converted to panels that can be displayed at the same time as other information. They can be shown or hidden from the vertical menu. When there is ambiguity as to which characters to use, a pop up displays alternatives. Click on one to insert it into the output. There is also a panel containing non-ASCII Latin characters, which can be used when typing Latin transcriptions directly into the main output area. This panel is now hidden by default, but can be easily shown from the vertical menu.

• Automated transcription. Version 16 pickers carry forward, and in some cases add, automated transcription converters. In some cases these are intended to generate only an approximation to the needed transcription, in order to speed up the transcription process. In other cases, they are complete. (See the notes for the picker to tell which is which.) Where there is ambiguity about how to transcribe a sequence of characters, the interface offers you a choice from alternatives. Just click on the character you want and it will replace all the options proposed. In some cases, particularly South-East Asian scripts, the text you want to transcribe has to be split into syllables first, using spaces and or hyphens. Where this is necessary, a condense button it provided, to quickly strip out the separators after the transcription is done.

• Layout The default layout of the main selection table has usually been improved, to make it easier to locate characters. Rarely used, deprecated, etc, characters appear below the main table, rather than to the right.

• Hints Very early versions of the pickers used to automatically highlight similar and easily confusable characters when you hovered over a character in the main selection table. This feature is being reintroduced as standard for version 16 pickers. It can be turned on or off from the vertical menu. This is very helpful for people who don’t know the script well.

• Shape-based selection. In previous versions the shape-based view replaced the default view. In version 16 the shape selectors appear below the main selection table and highlight the characters in that table. This arrangement has several advantages.

• Applying actions to ranges of text. When clicking on the Codepoints and Escapes buttons, it is possible to apply the action to a highighted range of characters, rather than all the characters in the output area. It is also possible to transcribe only highlighted text, when using one of the automated transcription features.

• Phoneme bank. When composing text from a Latin transcription in previous versions you had to make choices about phonetics. Those choices were stored on the UI to speed up generation of phonetic transcriptions in addition to the native text, but this feature somewhat complicated the development and use of the transcription feature. It has been dropped in version 16. Hopefully, the transcription panels and automated transcription features will be useful enough in future.

• Font grid. The font grid view was removed in version 16. It is of little value when the characters are already displayed using fonts.

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

Feeds

The Future of Style features:

• CSS WG Blog
• CSS3 . Info
• IEBlog
• W3C Blog
• W3C Blog
• W3C i18n and css
• W3C's Cascading Style Sheets home page
• Web Directions Blog
• ishida blog » css

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.

Site navigation