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.
@pagecontext, so discussion will continue on the mailing list.
bodyor if it has to come from root or if there are other approaches entirely.
writing-mode: vertical-lron the
rtbased on parent’s ‘display’ & ‘ruby-position’
region-breakgets folded into the new property, too.
@charsetparsing rules from CSS3 to CSS2.1. dbaron to propose errata; zcorpan to update tests.
:has()with some previous-child and -parent combinators in fast profile. There were still a lot of concerns about the performance implications. dbaron will test to see what the effects would be so that a more informed decision can be made.
::markerto pseudo-elements spec, takes properties from color module and fonts module (color, font-*, and opacity)
::markerwith font properties and color to pseudo-elements spec (and still plan to do more later in the lists spec).
text-wrap: balanceproposal, there was some concern about the inheritance behavior. Instead, they will work on creating
white-spaceproperties were well received, though it was thought that discard would be a better word than consume.
In recent releases, we’ve talked often about our goal to bring the team and technologies behind our web platform closer to the community of developers and other vendors who are also working to move the Web forward. This has been a driving motivation behind our emphasis on providing better developer tools, resources for cross-browser testing, and more ways than ever to interact with the "Project Spartan" team.
In the same spirit of openness, we’ve been making changes internally to allow other major Web entities to contribute to the growth of our platform, as well as to allow our team to give back to the Web. In the coming months we’ll be sharing some of these stories, beginning with today’s look at how Adobe’s Web Platform Team has helped us make key improvements for a more expressive Web experience in Windows 10.
Adobe is a major contributor to open source browser engines such as WebKit, Blink, and Gecko. In the past, it was challenging for them (or anyone external to Microsoft) to make contributions to the Internet Explorer code base. As a result, as Adobe improved the Web platform in other browsers, but couldn't bring the same improvements to Microsoft's platform. This changed a few months ago when Microsoft made it possible for the Adobe Web Platform Team to contribute to Project Spartan. The team contributes in the areas of layout, typography, graphic design and motion, with significant commits to the Web platform. Adobe engineers Rik Cabanier, Max Vujovic, Sylvain Galineau, and Ethan Malasky have provided contributions in partnership with engineers on the IE team.
The Adobe Web Platform Team hit a significant milestone with their first contribution landing in the March update of the Windows 10 Technical Preview! The feature is support for CSS gradient midpoints (aka color hints) and is described in the upcoming CSS images spec. With this feature, a Web developer can specify an optional location between the color stops of a CSS gradient. The color will always be exactly between the color of the 2 stops at that point. Other colors along the gradient line are calculated using an exponential interpolation function as described by the CSS spec.
linear-gradient(90deg, black 0%, 75%, yellow 100%)
radial-gradient(circle, black 0%, 75%, yellow 100%)
You can check this out yourself on this CSS Gradient Midpoints demo page. Just install the March update to Windows 10 Technical Preview and remember to enable Experimental Web Platform Features in about:flags to enable the new rendering engine. This change will bring IE to the same level as WebKit Nightly, Firefox beta and Chrome.
Another change that Adobe has recently committed is full support for <feBlend> blend modes. The W3C Filter Effects spec extended <feBlend> to support all blend modes per the CSS compositing and blending specification. Our new engine will now support these new values like the other major browsers.
New blend modes expand existing values normal, multiply, screen, overlay, darken and lighten with color-dodge, color-burn, hard-light, soft-light, difference, exclusion, hue, saturation, color and luminosity.
To use the new modes just specify the desired mode in the <feBlend> element. For example:
<feBlend mode='luminosity' in2='SourceGraphic' />
Internet Explorer 11
You can try this out today at Adobe's CodePen demo in Internet Explorer on the Windows 10 Technical Preview by selecting "Enable Experimental Web Platform Features" under about:flags.
Congratulations to the Adobe Web Platform Team on their first commit! We are looking forward to a more expressive Web and moving the Web platform forward! Let us know what you think via @IEDevChat or in the comments below.
— Bogdan Brinza, Program Manager, Project Spartan
As part of our ongoing focus on interoperability with the modern Web, we’ve been working on addressing an interoperability gap by writing an implementation of DOM L3 XPath in the Windows 10 Web platform. Today we’d like to share how we are closing this gap in Project Spartan’s new rendering engine with data from the modern Web.
Prior to IE’s support for DOM L3 Core and native XML documents in IE9, MSXML provided any XML handling and functionality to the Web as an ActiveX object. In addition to XMLHttpRequest, MSXML supported the XPath language through its own APIs, selectSingleNode and selectNodes. For applications based on and XML documents originating from MSXML, this works just fine. However, this doesn’t follow the W3C standards for interacting with XML documents or exposing XPath.
To accommodate a diversity of browsers, sites and libraries wrap XPath calls to switch to the right implementation. If you search for XPath examples or tutorials, you’ll immediately find results that check for IE-specific code to use MSXML for evaluating the query in a non-interoperable way:
In our new rendering engine, the script engine executes modern Web content, so a plugin-free, native implementation of XPath is required.
We immediately began to cost the work to implement the entire feature. Our options included starting from scratch, integrating MSXML, or porting System.XML, but each of these was too costly for its own reasons. We decided to start implementing a subset of XPath while working on the full implementation at the same time.
In order to know what subset of the standard to support, we used an internal crawler that captured the queries used across hundreds of thousands of the most popular sites on the Web. We found buckets of queries that had the form
Each of these queries maps cleanly to a CSS Selector that could return the same results that would be returned from our performant Selectors API. Specifically, the queries above can be converted to
The first native implementation of XPath thus involved supporting queries that can be converted to a CSS selector and exposing the results through the DOM L3 XPath interface objects. Alongside this implementation, we added telemetry to measure the rate of success across broader Web usage, which accounted for the number of successful queries, number of failed queries, and the query string of the first failure.
Our telemetry from internal testing showed that 94% of queries successfully converted to selectors to unblock many Web sites. Of the failures reported through the telemetry, many took the form
which can both be converted to the selector “element.className.” With these additional changes, the success rate improved to 97%, making our new engine ready for broader usage to support the modern Web.
|Internal telemetry showing Xpath query success rates|
In order to support WGX without polluting a Web page’s context, we created a separate, isolated script engine dedicated to WGX. With a few modifications to WGX that provide entry points for invoking functions and accessing results, we marshal the data from the page to the isolated engine and evaluate expressions with WGX. With WGX enabled to handle native XPath queries, we see immediate gains from sites missing content in our new engine rendering the modern Web.
Before and after: Available prices for products now appear correctly on tomtom.com
Before and after: Lottery numbers now correctly display where they were previously missing
While browsing the Web with WGX, we found a few bugs that exhibit behavior which diverges from other browsers’ implementations as well as the W3C spec. We plan to make contributions back to the project that make WGX more interoperable with native implementations.
Our new rendering engine now has support for XPath to run the modern Web to enable more functionality and show more content for our customers. With data-driven development from the modern Web, we landed on a data-driven outcome of a low-cost and performant implementation on existing technologies and standards as well as open source code. Grab the latest flight of the Windows 10 Technical Preview to try for yourself! You can reach us with feedback via the Internet Explorer Platform Suggestion Box on UserVoice, @IEDevChat on Twitter, and in the comments below.
– Thomas Moore, Software Engineer, Internet Explorer Platform
region-fragmentreceived the most attention for bikeshedding. One issue with
continueis that it is a verb when almost all property names have been nouns or adjectives. Some people were inclined to return the name to
fragmentationbut most of the group felt that would have no context outside of the working group. It was suggested that there was likely vocabulary for this concept and that users of programs like inDesign or PhotoShop would likely have some suggestions.
region-fragmentproperties defined outside the overflow context. It was agreed thought they are similar, they’re not the same and therefore should be separate.
allisn’t viewed as particularly accessible since it removes the
:focusoutline on an element. Consensus was the old
defaultthat was removed from the spec would fix the problem. The spec authors will go back and see if there are any reasons that
defaultwas removed that need to be addressed and re-introduce next week for formal resolution.
.icoto the web consortium.
.icoare the standards and they will be expected in new products. It’s an informative note. It will be up to the person writing the note as to what exactly goes inside.
imageCSS value, as well as SVG if the implementation supports SVG and saying for cursor that all non animated formats supported for
imageMUST be supported in cursor, and that all animated formats supported in
imageSHOULD be supported in cursor. However, Microsoft asked for a week to review, so formal resolution will be asked for on next week’s call.
trailing-spaceswill be in CSS Text Level 4
Based on feedback from Windows Insiders, we are working to release preview builds more often. Today we flighted the first update to Insiders on this accelerated cadence, which includes the latest updates to our new rendering engine. Due to the change in cadence, this build does not yet include the Project Spartan preview, which will be available in the next release.
Today’s build has a number of updates to the new engine, including new features and improvements to existing features. Some of these include:
In addition, you may notice some features partially implemented and available for testing in Internet Explorer under about:flags. These features are under active development and will continue to evolve in future preview builds.
Watch this space over the next week as we’ll be diving into these in more detail in a series of individual posts. In the meantime, you can try these improvements out in the latest preview by signing up for the Windows Insiders program and joining the “Fast” update ring. To enable the new engine in Internet Explorer on preview builds, navigate to about:flags and select “Enable experimental Web platform features.” We'll also be updating RemoteIE with the new preview soon. Don’t forget to share your feedback via the Internet Explorer Platform Suggestion Box on UserVoice, @IEDevChat on Twitter, and in the comments below.
– Kyle Pflug, Program Manager, Project Spartan
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.
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
firstname.lastname@example.org with the spec code (
and your comment topic in the subject line. (Alternatively, you can
email one of the editors and ask them to forward your comment.)
@supportsto Cascade Level 4
border-start-end-radius(in CSS Logical Properties)
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.
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.
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.
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
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
a scathing condemnation of the DOM/CSS web standards
Look, I really should let Gruber’s  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
 I actually think a lot of Gruber’s writing is thoughtful, just when it comes to this issue…
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.
contentas the new value for
no-wrapas an alias to
nowrapto 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.
break-*properties to control inline layout. It received a warm reception as an idea worth exploring.
text-wrap: balanceproposal was also well received with a lot of people showing interest in developing it further.
ime-modeas obsolete as described in the draft of CSS3 UI
ime-modeto 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.
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.
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.
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.
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.
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.
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
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.
If you are building a public consumer-facing web site here’s what you need to know:
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:
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
nav-*properties from CSS3 UI might help address some of the issues.
justify-contenton grid containers operate on the grid tracks (allows distributing extra space between grid tracks)
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.
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.
The CSS Working Group has published an updated Working Draft of
Level 4. This module describes the syntax, styling, and
inheritance/cascading models for each of the existing CSS pseudo
::selection (with a much more
comprehensive description of how it’s supposed to work), and
introduces a few new ones, such as
This is a First Public Working Draft, and is in a somewhat rough
state. Feedback is welcome, especially corrections. The
section in particular could use a close review.
As always, please send feedback to the (archived)
public mailing list
email@example.com with the spec code (
and your comment topic in the subject line. (Alternatively, you can
email one of the editors and ask them to forward your comment.)
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.