The future of style

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

Environments for Humans organizes the 3-day CSS Dev Conf 201…

Source: W3C's Cascading Style Sheets home page27 August 2014 04:31 AM

13 Oct 2014 Environments for Humans organizes the 3-day CSS Dev Conf 2014, in New Orleans, Louisiana, USA, on 13–15 October. Deadline for paper submissions is April 15.

The CSS WG issued a new last call for CSS Counter Styles Lev…

Source: W3C's Cascading Style Sheets home page26 August 2014 12:00 AM

26 Aug 2014 The CSS WG issued a new last call for CSS Counter Styles Level 3

The CSS WG and the SVG WG jointly published a Candidate Reco…

Source: W3C's Cascading Style Sheets home page26 August 2014 12:00 AM

26 Aug 2014 The CSS WG and the SVG WG jointly published a Candidate Recommendation of CSS Masking Module Level 1

Burmese divergence on the Web

Source: ishida blog » cssr12a • 22 August 2014 09:23 AM

It’s disappointing to see that non-standard uses of UTF-8 are being used by the BBC on their BBC Burmese Facebook page.

Take, for example, the following text.

On the actual BBC site it looks like this (click on the burmese text to see a list of the characters used):

အိန္ဒိယ မိန်းမငယ် ၂ဦး အမှု ဆေးစစ်ချက် ကွဲလွဲနေ

As far as I can tell, this is conformant use of Unicode codepoints.

Look at the same title on the BBC’s Facebook page, however, and you see:

အိႏၵိယ မိန္းမငယ္ ၂ဦး အမႈ ေဆးစစ္ခ်က္ ကြဲလြဲေန

Depending upon where you are reading this (as long as you have some Burmese font and rendering support), one of the two lines of Burmese text above will contain lots of garbage. For me, it’s the second (non-standard).

This non-standard approach uses visual encoding for combining characters that appear before or on both sides of the base, uses Shan or Rumai Palaung codepoints for subjoining consonants, uses the wrong codepoints for medial consonants, and uses the virama instead of the asat at the end of a word.

I assume that this is because of prevalent use of the non-standard approach on mobile devices (and that the BBC is just following that trend), caused by hacks that arose when people were impatient to get on the Web but script support was lagging in applications.

However, continuing this divergence does nobody any long-term good.

[Find fonts and other resources for the Myanmar script]

Minutes Telecon 2014-08-20

Source: CSS WG BlogDael Jackson • 21 August 2014 12:33 AM

Full Minutes

Native Responsive Images

Source: Dev.OperaYoav Weiss • 18 August 2014 10:00 PM

How It All Began

Our story starts in ancient times, when WURFLs roamed the wilderness, and mobile-only websites were a thing. In these times, a developer that wanted to provide access to his website to mobile users created a simpler, dumbed down version of the “real” website, and served that based on UA detection.

As you surely know, the proliferation of devices with numerous viewport dimensions and many different capabilities called out for a better way to target mobile (and not-so-mobile) users. Responsive Web Design combined new browser capabilities and CSS techniques to create websites that adapt to the device displaying them, and look ideal everywhere. That enabled developers to stop worrying about unreliable device detection and think of their websites in terms of viewport dimensions.

But, even though RWD sites looked different on each device, underneath, most of them continued to download the same resources for all devices. And since images comprised the major part of the bytes that websites were downloading, the developer community started to look into possible solutions to avoid this waste.

That started a (very) long process in which multiple proposals were suggested on various mailing-lists, the problem was analyzed over blog post debates, and the various use-cases that emerged were taken into consideration. The developer community united to form the Responsive Images Community Group, and eventually, browser vendors got involved and consensus was reached. The picture element specification that was written in collaboration between the community and browser vendors was merged into the HTML spec, and both Blink & Gecko’s implementations are destined to ship early this fall!

But, hold on a minute. That’s a great story and all, but why should I care about responsive images? What can responsive images do for me?

Fixed Width Images

So, let’s say that the website you’re building has images that are always of the same dimensions regardless of viewport size. E.g. the website you’re building is not responsive. The only thing “responsive” about these images is that you want them to look good on high-end devices with a higher Device-Pixel-Ratio (or DPR, as his parents fondly call him), but you don’t want to send “retina images” to devices that don’t need them.

Let’s say that you have a 500px image. You want it to be displayed at these same dimensions on retina screens, only with higher quality.

The syntax that enables you to do that would look something like:

<img src="cat_500px.jpg"
        srcset="cat_750px.jpg 1.5x, cat_1000px.jpg 2x"
        width="500px" alt="lolcat">

Short and sweet, right? No need for too many explanations there. You just give the browser a comma-separated list of resources and their x descriptors (describing the screen’s DPR), and the browser picks the best fit.

Note that the 1x image resource is in the src attribute, where it doubles as a fallback resource. There’s no need to write the same resource twice!

Variable Width Images

Now, if your site is a “classical” responsive website with “stretchy” images, the above is not enough. It’s better than nothing, sure, but a 1920px wide screen and a 360px screen with the same density will get the same image, which means you’ll be making significant UX compromises, either on blurriness or on slowness.

What you really want is to define the image resources in a way that allows a browser to pick the right one for the current DPR and viewport size. But how can we do that?

Ideally, we’d want to define the set of available image resources along with their physical dimensions (i.e. their width in pixels), and have the browser download one based on the image’s display dimensions.

But there’s a problem: the browser doesn’t know what the image’s display dimensions will be when it needs to choose which resource to download. The image’s display dimensions depend on the final page’s layout, which often relies on external CSS, and can be influenced by the image’s dimensions, as well as the dimensions of other images on the page. That’s some circularity madness right there!

So, if we want the browser to download the right resource, we need to provide it with a hint regarding the final display dimensions — there’s just no way around that. Of course, depending on our design, the image’s dimensions can vary at the various layouts.

These are rather complex constraints, which is one of the reasons it took a long while to get a proper definition of the problem. Eventually, Google’s Tab Atkins and John Mellor came up with a proposal for a syntax that would resolve this “stretchy images” use case, and it was happily adopted into the overall responsive images spec (with Tab as well as Simon Pieters from Opera doing most of the spec’s editing).

Let’s look at an example of what you would do if you have an image that takes up different dimensions at different layout breakpoints:

<img sizes="(max-width: 30em) 100vw,
                        (max-width: 50em) 50vw,
                        calc(33vw - 100px)"
        srcset="swing-200.jpg 200w,
                        swing-400.jpg 400w,
                        swing-800.jpg 800w,
                        swing-1600.jpg 1600w"
        src="swing-400.jpg" alt="Kettlebell Swing">

That may seem overwhelming at first, so let’s break it up into pieces. The w descriptors of the srcset syntax are not very different from the x descriptors that we saw earlier. The srcset attribute contains a grocery list of resources that the browser can pick from, and the w descriptors tell the browser each resource’s physical dimensions.

But, didn’t we just say that the browser cannot wait for the image’s display dimensions to be calculated because doing so would result in significant delays and possible double downloads? And if the browser cannot wait for the display dimensions, how can it use the image’s physical dimensions to determine which resource to download?

This is where the sizes attribute comes into play. It is comprised of value pairs, where the first (optional) value is a media condition (a media query without the media type) and the second value is a CSS length.

The browser goes over the media conditions and looks for the first one that matches the current environment (in most cases, “current environment” == current viewport). The second value of the pair (or the first one if the media condition is missing), is set as the pair’s “effective size”, and it describes the estimated display dimensions of the image. This is the hint the developer has to give the browser in order for it to know which resource to pick.

The effective size of the matching pair is used by the browser, along with the screen’s DPR (and possibly other factors) to figure out which resource would be the best to download and display.

Going back to our code example above, assuming we’re running with a browser viewport of 20em over the default root font size of 16px (i.e. a viewport width of 320px), the browser will go over the sizes pairs and pick the first one: (max-width: 30em) 100vw. That would indicate it that the image is likely to be displayed at the full width of the viewport, so assuming a DPR of 1, the browser is likely try to download the first resource that is larger than 320px wide and end up downloading swing-400.jpg. If the DPR value is 2, in order to match the screen’s density the required resource needs to be twice as large, so the browser will probably download the first resource larger than 640px, which is swing-800.jpg.

Now, if our viewport is 40em (640px), the (max-width: 50em) 50vw pair matches, and the image is likely to take up half of the viewport’s width. That means the image picked it probably the first one larger than 320px for 1x screens and 640px for 2x screens, and the downloaded resources are likely to be identical in both cases.

Why did I use all of those “likely”s and “probably”s in the sections above? They’re there because for the resources inside srcset, the browser is free to pick whatever resource its algorithms see fit. That means that you, as a web developer, can’t rely on the browser downloading and displaying the exact resource you want it to. That’s a Good Thing™, since it leaves the browser room to innovate in this space, by adding user preferences, network considerations and other future optimizations to the decision-making process. And since all of the different resources should only differ in quality, differing resource choices shouldn’t have any impact on your page’s layout.

It’s worth noting that if the sizes attribute is missing, a default value of 100vw is used as the effective size instead, as it represents the largest display dimensions the image might be displayed in without horizontal scrolling.

So what happens if you want to see slightly different images on different layouts, showing images whose proportions are different, whose subject is more visible, or anything else your creative selves desire?

That’s what the art direction use case is all about!

Art Direction

The term “Art Direction” with regard to responsive images was first coined by Jason Grigsby, and refers to cases where you want to tailor-fit the displayed image to a specific responsive layout breakpoint. Art direction should be used when your image resources differ not only in their quality, but also in their proportions, crop area, copy text location, shot angle, etc, etc. The possibilities are limitless!

In these cases, you want to make sure that the image displayed to your users at a certain design breakpoint is in fact the image you intended they’d see.

The art direction syntax goes something like:

<picture>
        <source media="(min-width: 45em)" srcset="large.jpg">
        <source media="(min-width: 32em)" srcset="med.jpg">
        <img src="small.jpg" alt="The president giving an award.">
</picture>

Here again we hand out a grocery list of resources to the browser. The difference is that this is a list of <source> tags, and their selection algorithm is well-defined by the spec.

The browser follows that algorithm to the letter and picks the source tag that you intended, every time.

Very much like it does when using the sizes algorithm, the browser goes over the list of sources and picks the first one that matches. A match can happen based on both media and type attributes. (Why type? We’ll see that in a bit.)

If both attributes either match or are missing, the matching source is picked. If none of the <source>s match, the <img> is picked. And once we have an element that’s picked as the source for this image, the resource that will be downloaded is chosen using the source’s srcset and sizes attributes, according to the same mechanisms we discussed earlier.

A few things to take note of:

Why can’t we do art-direction with sizes/srcset?

By design, the sizes/srcset syntax takes into account the viewport’s width as well as the screen’s DPR. Adding art-direction into the same syntax would have meant that the web developer has to explicitly specify all the DPR and viewport width combinations in the markup.

That would have made the web developer’s job much more difficult and would have made the syntax much harder to grasp and significantly more verbose.

Image Format Fallback

One more thing you may want to do related to images (not necessarily responsive ones) is to serve different file formats to different browsers, according to the browser’s support for them. On top of the “traditional” file formats that browsers support (i.e. PNG, JPEG and GIF), there are several newer file formats that browser vendors are trying to push. These formats usually perform better than the traditional formats, since they include all kinds of algorithmic improvements that make image compression more efficient. Specifically, Google is pushing the WebP format and Microsoft is pushing JPEG-XR.

The problem here is that these new formats lack the traditional formats’ level of ubiquitous support, which means that if you serve these formats as your <img src> value, even though the browsers that support them will show an improved user experience, the ones that don’t won’t show any image at all. That’s hardly good.

Up until today, the only way to serve such formats without breaking the user experience in non-supporting browsers was content-negotiation, using the Accept HTTP header or UA sniffing. While that mostly works fine, it has some caveats. It requires server-side fiddling, which some developers can’t do or lack interest in doing. It also introduces difficulties with regard to making these images publicly cacheable.

With the picture syntax, we finally have a way to define a client-side fallback mechanism. By using the type attribute on <source> we can provide the browser with multiple resource URLs, and let the browser pick the one it supports. Such mechanisms have been available for other resource types for years (e.g. fonts, videos). Now a fallback mechanism is also available for images.

The syntax for client-side format fallback looks something like:

<picture>
        <source type="image/webp" srcset="president.webp">
        <source type="image/vnd.ms-photo" srcset="president.jpxr">
        <img src="president.jpg" alt="The president fistbumps someone.">
</picture>

Can I Use It Today?

Native support for most of the features we discussed is still a few weeks away from reaching stable browsers, but you certainly can start using these features right now.

The srcset x descriptor is already supported in browsers since Chrome 34, Opera 21 and will be supported in Safari 8.

Picture element support is destined to ship in a few weeks in Chrome 38, Opera 25 and Firefox 33. The implementation of the sizes/srcset part of the syntax in WebKit is complete, but unfortunately, it did not ship in Safari 8. There’s also still work to be done (read: I need to work on it) to implement the full <picture> syntax there.

Regarding IE, officially <picture> is “under consideration”, but the IE development team show up on the #respimg IRC channel quite often and ask good questions. Let’s hope the status will switch to “in development” shortly.

Picture element support was also implemented in the W3C’s validator, so you can use that to spot mistakes in your markup, should you run into trouble with it.

The feature has a standard compliant polyfill called picturefill, and even without it, the inherent <img> fallback makes it so that legacy browsers would still download and display the fallback image, meaning that the user experience in these browsers won’t be any different than what they get if you simply use an <img> tag.

The Proposal Left Behind

Those of you who followed the responsive images saga closely may remember yet another proposal, called “Client-Hints”. That proposal suggested solving some of the use cases by using HTTP request headers to tell the server regarding the browser’s environmental conditions, and letting the server adapt the images it sends accordingly. That kind of solution is generally referred to as “content negotiation”.

Unfortunately some browser vendors were reluctant to add new content negotiation-based solutions, because of past bad experience with this kind of solutions. Without support from these browser vendors, progress on Client-Hints stalled and now the proposal is not being actively worked on.

Community

The responsive images effort, unlike the development process behind most web platform features, was community-driven. It was championed by the RICG, supported by the developer community, and taken home when browser folks got involved too. One big happy family.

In the same spirit, the feature’s implementation in Blink (the rendering engine behind Chrome and Opera) also set something of a precedent.

In order to defuse initial implementation concerns from the Blink project, I devised an implementation plan with the Blink team and started to work on related infrastructure.

At first, I worked on that during my free time, but later on, after I saw how long that was going to take, I completed the feature’s implementation as my day job. I was financed by the community via a crowd funding campaign which was put together with the help of the RICG gang (particularly Mat Marquis and Geri Coady).

Web developers, agencies, as well as Google and Opera contributed to the campaign, making it possible for me to work full-time on the implementation, and bring it to where it is today.

To Sum It Up

Responsive images have been a pain point when developing responsive websites for quite some time. Now, finally, a native solution is getting close.

You can start using it today, with or without picturefill, and start savings your users’ time and money!

Vivliostyle Inc. has launched an Open Source project to crea…

Source: W3C's Cascading Style Sheets home page18 August 2014 12:00 AM

18 Aug 2014 Vivliostyle Inc. has launched an Open Source project to create the Vivliostyle formatter, a print formatter to produce high-quality PDF, using CSS. (See also the Vivliostyle Browser.)

Vivliostyle Inc. has launched an Open Source project to crea…

Source: W3C's Cascading Style Sheets home page18 August 2014 12:00 AM

18 Aug 2014 Vivliostyle Inc. has launched an Open Source project to create the Vivliostyle browser, a viewer for EPUB and HTML documents. (See also the Vivliostyle Formatter.)

Announcing new F12 dev tools features in August update

Source: IEBlog ieblog • 14 August 2014 05:58 PM

Today we’re excited to share all the F12 features that shipped in the August update to IE11!

In April, we shipped a swath of new features of F12 Developer Tools in Internet Explorer 11 focusing on providing accurate data in the DOM Explorer, actionable data in the memory and performance tools and a smoother debugging experience with Just My Code.

With the IE Developer Channel in June we previewed more features in the F12 Developer Tools and now all of these features are shipping out to all of our customers. It’s a long list which you’ll find below or on MSDN but the highlights are:

With this update to IE11 and F12, we’re keeping the pace of updating the F12 developer tools more often, getting you the latest features and bug fixes as soon as we can. Expect to see and hear from us more and if you’d like to provide feedback, or ask for new features and help simply reach out on Twitter @IEDevChat, or on Connect.

— Andy Sterland, Senior Program Manager, Internet Explorer


Changes to the F12 user interface

Console changes

DOM Explorer changes

HTML5 and RWD training: early bird rates extension!

Source: W3C Blog Marie-Claire Forgue • 13 August 2014 01:41 PM

Do not miss the early bird registration extension to 27 August for two online training courses from W3C: HTML5 and Responsive Web Design!

W3DevCampus logoLearn more about W3DevCampus, the official W3C online training for Web developers and watch our fun intro video.

Get new skills, earn certificates and start collecting W3C training badges!

Minutes Telecon 2014-08-06

Source: CSS WG BlogDael Jackson • 07 August 2014 01:00 AM

Full Minutes

Grid Style Sheets (GSS) (warning: the site requires turning …

Source: W3C's Cascading Style Sheets home page06 August 2014 12:00 AM

6 Aug 2014 Grid Style Sheets (GSS) (warning: the site requires turning on JavaScript or turning off CSS!) is an extension of Constraint CSS (CCSS), which is itself an extension of CSS. GSS and CCSS are aimed at laying out boxes by means of constraints, instead of explicit positions or margins. An automatic constraint solver then finds the optimal solution. An implementation in JavaScript (built on the Cassowary constraint solver) is available.

The CSS WG updated the Working Draft of CSS Ruby Layout Modu…

Source: W3C's Cascading Style Sheets home page04 August 2014 12:00 AM

4 Aug 2014 The CSS WG updated the Working Draft of CSS Ruby Layout Module Level 1

UniView 7.0.0: Final spec version; links to detailed notes

Source: ishida blog » cssr12a • 31 July 2014 07:24 PM

Picture of the page in action.

>> Use UniView

This version updates the app per the changes during beta phase of the specification, so that it now reflects the finalised Unicode 7.0.0.

The initial in-app help information displayed for new users was significantly updated, and the help tab now links directly to the help page.

A more significant improvement was the addition of links to character descriptions (on the right) where such details exist. This finally reintegrates the information that was previously pulled in from a database. Links are only provided where additional data actually exists. To see an example, go here and click on See character notes at the bottom right.

Rather than pull the data into the page, the link opens a new window containing the appropriate information. This has advantages for comparing data, but it was also the best solution I could find without using PHP (which is no longer available on the server I use). It also makes it easier to edit the character notes, so the amount of such detail should grow faster. In fact, some additional pages of notes were added along with this upgrade.

A pop-up window containing resource information used to appear when you used the query to show a block. This no longer happens.

Changes in version 7beta

I forgot to announce this version on my blog, so for good measure, here are the (pretty big) changes it introduced.

This version adds the 2,834 new characters encoded in the Unicode 7.0.0 beta, including characters for 23 new scripts. It also simplified the user interface, and eliminated most of the bugs introduced in the quick port to JavaScript that was the previous version.

Some features that were available in version 6.1.0a are still not available, but they are minor.

Significant changes to the UI include the removal of the ‘popout’ box, and the merging of the search input box with that of the other features listed under Find.

In addition, the buttons that used to appear when you select a Unicode block have changed. Now the block name appears near the top right of the page with a I icon icon. Clicking on the icon takes you to a page listing resources for that block, rather than listing the resources in the lower right part of UniView’s interface.

UniView no longer uses a database to display additional notes about characters. Instead, the information is being added to HTML files.

Minutes Telecon 2014-07-30

Source: CSS WG BlogDael Jackson • 31 July 2014 03:44 PM

Full Minutes

The Mobile Web should just work for everyone

Source: IEBlog ieblog • 31 July 2014 03:09 PM

Update 8/4/2014 - Developers can now preview these updates by joining the Windows Phone Preview for Developers or downloading the Windows Phone 8.1 Update Emulator. Details on platform changes described in this post can be found on MSDN. We have also published updated best practices on updating tailored sites to support standards.


Windows Phone 8.1 Update includes hundreds of Internet Explorer 11 enhancements that greatly increase compatibility with the mobile web.

Based on your feedback, we pursued a web experience for IE users consistent with what is available on iOS and Android devices – even where this meant we would be adding non-standard web platform features. We believe that this is a more pragmatic approach to running today's less-standardised mobile web.

We tested more than 500 of the top mobile web sites and found that the IE11 update improves the experience on more than 40% of them.

For example, if you visit www.twitter.com with IE11, you used to see:

Screenshot of www.twitter.com with Windows Phone 8.1
Windows Phone 8.1

Here is what you see in IE11 with the update, on Firefox OS and on an iPhone:

Screenshot of www.twitter.com with Windows Phone 8.1 Update
Windows Phone 8.1 Update
Screenshot of www.twitter.com with Firefox OS
Firefox OS
Screenshot of www.twitter.com with iPhone
iPhone with iOS7

Similarly, if you visit www.baidu.com with IE11 and Firefox OS, you see:

Screenshot of www.baidu.com with Windows Phone 8.1
Windows Phone 8.1
Screenshot of www.baidu.com with Firefox OS
Firefox OS

Here is what you see in IE11 with the update and on an iPhone:

Screenshot of www.baidu.com with Windows Phone 8.1 Update
Windows Phone 8.1 Update
Screenshot of www.baidu.com with iPhone
iPhone with iOS7

Analysing the most popular web sites

Unlike the mostly standards-based ‘desktop' web, many modern mobile web pages were designed and built for iOS and the iPhone. This results in users of other devices often receiving a degraded experience.

A few weeks ago we talked about our vision and priorities for the web. We believe that "The Web should just work for everyone – users, developers and businesses." We started researching what it would take to make the mobile web "just work" for our customers.

As we investigated the most popular mobile web sites from around the world we started to see common patterns causing problems. Often sites would use poorly written browser detection code that would result in the desktop site experience for Windows Phone users. Desktop web sites tend to be larger and slower to load costing more of a user's data plan. These sites end up with tiny text and you have to spend a lot of time zooming and panning around to read the content. They also expect you to be using a mouse and so menus and forms are hard to work with.

When Windows Phone 8.1 reached RTM, it included the same fast, standards-based, IE11 browser engine that powers the PC version of IE on the desktop. For the last several years we've talked about providing the same mark-up to all browsers using feature detection and graceful degradation. Although we still see broken desktop sites not following this guidance from time to time, the situation has improved on the desktop. We found a much different situation on the mobile web. Many sites use features via a legacy vendor specific prefix without supporting the un-prefixed standard version or only support vendor prefixes for certain devices. Other sites use non-standard proprietary APIs that only work with Safari or Chrome. Of course there were also bugs or missing features in IE that became particularly apparent on mobile sites designed specifically for our competitors' browsers.

Updating Internet Explorer in Windows Phone 8.1 Update

We gathered all of this compatibility data and then we began to plan what changes we should make to IE. The remainder of this blog post discusses some of the most important changes and the rationale for why we made them. The issues affecting mobile web sites fall primarily into five main categories:

Changing the User Agent string

One of the most significant issues we saw was related to sites not detecting that IE on Windows Phone is a mobile browser and therefore providing desktop content. This often results in sites displayed with tiny text that you need to zoom in to read and then pan around. It also often means more data is transmitted over the phone's data connection because the content isn't mobile optimised. Images are large and many more ads are downloaded and shown.

There are many different ways that sites try to detect whether to deliver the mobile experience. Here is one such check we found on a real site:

window.mobileCheck = function() {

var check = false;

(function(a){if(/(android|bb\d+|meego).+mobile|avantgo|bada\/|blackberry|blazer|compal|elaine|fennec|hiptop|iemobile|ip(hone|od)|iris|kindle|lge |maemo|midp|mmp|mobile.+firefox|netfront|opera m(ob|in)i|palm( os)?|phone|p(ixi|re)\/|plucker|pocket|psp|series(4|6)0|symbian|treo|up\.(browser|link)|vodafone|wap|windows (ce|phone)|xda|xiino/i.test(a)||/1207|6310|6590|3gso|4thp|50[1-6]i|770s|802s|a wa|abac|ac(er|oo|s\-)|ai(ko|rn)|al(av|ca|co)|amoi|an(ex|ny|yw)|aptu|ar(ch|go)|as(te|us)|attw|au(di|\-m|r |s )|avan|be(ck|ll|nq)|bi(lb|rd)|bl(ac|az)|br(e|v)w|bumb|bw\-(n|u)|c55\/|capi|ccwa|cdm\-|cell|chtm|cldc|cmd\-|co(mp|nd)|craw|da(it|ll|ng)|dbte|dc\-s|devi|dica|dmob|do(c|p)o|ds(12|\-d)|el(49|ai)|em(l2|ul)|er(ic|k0)|esl8|ez([4-7]0|os|wa|ze)|fetc|fly(\-|_)|g1 u|g560|gene|gf\-5|g\-mo|go(\.w|od)|gr(ad|un)|haie|hcit|hd\-(m|p|t)|hei\-|hi(pt|ta)|hp( i|ip)|hs\-c|ht(c(\-| |_|a|g|p|s|t)|tp)|hu(aw|tc)|i\-(20|go|ma)|i230|iac( |\-|\/)|ibro|idea|ig01|ikom|im1k|inno|ipaq|iris|ja(t|v)a|jbro|jemu|jigs|kddi|keji|kgt( |\/)|klon|kpt |kwc\-|kyo(c|k)|le(no|xi)|lg( g|\/(k|l|u)|50|54|\-[a-w])|libw|lynx|m1\-w|m3ga|m50\/|ma(te|ui|xo)|mc(01|21|ca)|m\-cr|me(rc|ri)|mi(o8|oa|ts)|mmef|mo(01|02|bi|de|do|t(\-| |o|v)|zz)|mt(50|p1|v )|mwbp|mywa|n10[0-2]|n20[2-3]|n30(0|2)|n50(0|2|5)|n7(0(0|1)|10)|ne((c|m)\-|on|tf|wf|wg|wt)|nok(6|i)|nzph|o2im|op(ti|wv)|oran|owg1|p800|pan(a|d|t)|pdxg|pg(13|\-([1-8]|c))|phil|pire|pl(ay|uc)|pn\-2|po(ck|rt|se)|prox|psio|pt\-g|qa\-a|qc(07|12|21|32|60|\-[2-7]|i\-)|qtek|r380|r600|raks|rim9|ro(ve|zo)|s55\/|sa(ge|ma|mm|ms|ny|va)|sc(01|h\-|oo|p\-)|sdk\/|se(c(\-|0|1)|47|mc|nd|ri)|sgh\-|shar|sie(\-|m)|sk\-0|sl(45|id)|sm(al|ar|b3|it|t5)|so(ft|ny)|sp(01|h\-|v\-|v )|sy(01|mb)|t2(18|50)|t6(00|10|18)|ta(gt|lk)|tcl\-|tdg\-|tel(i|m)|tim\-|t\-mo|to(pl|sh)|ts(70|m\-|m3|m5)|tx\-9|up(\.b|g1|si)|utst|v400|v750|veri|vi(rg|te)|vk(40|5[0-3]|\-v)|vm40|voda|vulc|vx(52|53|60|61|70|80|81|83|85|98)|w3c(\-| )|webc|whit|wi(g |nc|nw)|wmlb|wonu|x700|yas\-|your|zeto|zte\-/i.test(a.substr(0,4)))check = true})(navigator.userAgent||navigator.vendor||window.opera);

return check;
}

We updated the User Agent string in IE on Windows Phone to increase the number of sites that would correctly deliver the best mobile content. This continues an unfortunate pattern that all browsers have had to deal with and most web developers have run into. For example, there is an interesting discussion from as early as 2006 in a WebKit bug entitled "Safari lies. Reports itself as Mozilla, Gecko and KHTML too." When we shipped IE11 on the desktop, we added the token "like Gecko" to the string because it significantly improved compatibility with desktop sites. Chrome and Opera claim to be like Gecko and Safari in order to be compatible with web content.

If you visit www.hawaiianairlines.com with IE11 and Firefox OS, you see the desktop experience:

Screenshot of www.hawaiianairlines.com with Windows Phone 8.1
Windows Phone 8.1
Screenshot of www.hawaiianairlines.com with Firefox OS
Firefox OS

Here is what you see in IE11 with the update and on an iPhone:

Screenshot of www.hawaiianairlines.com with Windows Phone 8.1 Update
Windows Phone 8.1 Update
Screenshot of www.hawaiianairlines.com with iPhone
iPhone with iOS7

If you visit www.nytimes.com with IE11 and Firefox OS, you also see the desktop experience:

Screenshot of www.nytimes.com with Windows Phone 8.1
Windows Phone 8.1
Screenshot of www.nytimes.com with Firefox OS
Firefox OS

Here is what you see in IE11 with the update and on an iPhone:

Screenshot of www.nytimes.com with Windows Phone 8.1 Update
Windows Phone 8.1 Update
Screenshot of www.nytimes.com with iPhone
iPhone with iOS7

In general, our advice is to develop a responsive site that can adapt to the capabilities of different devices. If you choose to build a mobile-specific experience then we recommend looking for the sub-string "mobile" in the user agent string to determine when to deliver mobile optimised content:

function isMobile() {
    return navigator.userAgent.toLowerCase().indexOf("mobile")>=0;
}

Mapping legacy webkit-prefixed features to IE implementation

After changing the user agent string so that IE receives the same content as other phone browsers we could begin to analyse issues that were breaking mobile experiences. The first important problem we identified was that many mobile sites only send webkit-prefixed content for CSS gradients, flexbox, transitions, and animations. These are features that IE11's web standards-based engine already supports for sites with cross-browser mark-up. As Mozilla found, WebKitCSSMatrix is commonly used on mobile devices. IE supports MSCSSMatrix. Many sites also use window.orientation instead of the emerging standard screen.orientation. The second problem we found here is that sites also often use old syntax in their code. For example, using the old gradient syntax instead of the updated standards based approach.

In Windows Phone 8.1 Update, we added a mapping of popular webkit-prefixed APIs to the standards based support already part of IE11. This means that sites that only send WebKit code are translated into standards based code as the page loads. We are not planning to support all webkit-prefixed APIs. We have added mappings for the ones that are so prevalent in mobile sites that the web won't work without them.

If you visit www.macys.com with IE11, you see:

Screenshot of www.macys.com with Windows Phone 8.1
Windows Phone 8.1

Here you can see the gradients drawn correctly in IE11 with the update and on an iPhone:

Screenshot of www.macys.com with Windows Phone 8.1 Update
Windows Phone 8.1 Update
Screenshot of www.macys.com with iPhone
iPhone with iOS7

If you visit www.answers.com with IE11, you see:

Screenshot of www.answers.com with Windows Phone 8.1
Windows Phone 8.1

Here you can see the site drawn correctly in IE11 with the update and on an iPhone:

Screenshot of www.answers.com with Windows Phone 8.1 Update
Windows Phone 8.1 Update
Screenshot of www.answers.com with iPhone
iPhone with iOS7

Adding support for non-standard proprietary features

We found a small number of non-standard features popularised by Apple on the iPhone in widespread use. These features are not currently on a standards track but browsers that don't support them can't provide a good experience for top sites on the mobile web. One example is -webkit-appearance, which allows a page to modify the styling of an element to match native applications. As Mozilla points out, "not only is it non-standard, but its behavior changes from one browser to another." Unfortunately, without some level of support for these non-standard proprietary features, web sites are more difficult to use.

New features supported in IE

There are several standards-based features that IE11 didn't support that are used infrequently on desktop sites, but are in common use in the mobile web. Once we made IE11 receive more mobile content we determined that we would need to add these features. For example, window.locationbar is defined in HTML5 but rarely used on desktop sites. We prioritised implementing several new features based on the mobile sites they enabled.

One of the larger API-related issues affecting compatibility with mobile sites is support for touch. In IE10, we shipped support for Pointer Events, which is now a Candidate Recommendation at W3C, and we updated the implementation in IE11 to incorporate changes in the spec. Using Pointer Events provides many performance and functional advantages to sites that wish to use either mouse, touch, pen or other pointer inputs and we continue to recommend this as the best API for sites that work for users across all of their devices.

On the mobile web, most sites have been coded to use the older Touch Events model and users expect those sites to just work. In the IE11 update, we added support for touch events so that these sites would work correctly. Our research has shown that on the desktop web, enabling touch events on a device that also supports a mouse (like Windows tablets and 2 in 1 devices) causes more problems—for example, we found that mouse and trackpad support is broken on about 10% of top sites when Touch Events are enabled. Many sites don't expect to be able to receive touch events and mouse events and only support one or the other. We have joined other browser vendors in the W3C Touch Events Community Group to work through these issues for the web at large. We'll talk more about pointer and touch events in a future post.

Fixing the most impactful interop issues

As we continued to investigate the mark-up in sites that were not working correctly in Internet Explorer, we found some peculiar interoperability issues. For example, <button> and <label> elements inside <a> links are independently clickable in other browsers although this behaviour isn't clearly documented anywhere. Another example is <meta> refresh support. The HTML5 spec expects the string "URL=" to be part of the element's content in order to redirect to a different URL. Other browsers don't require this and, when used incorrectly in this way, pages in IE would appear to refresh constantly.

Finally, we also identified several bugs in the Trident engine that particularly impacted top mobile sites and we included fixes for these issues in this update. For example, we fixed some navigation issues with location.hash and some CSS layout problems that were affecting popular mobile sites.

What can you do?

Many of the changes we've made are specifically targeted at consuming legacy or vendor prefixed content published on these sites. It is not our goal to support all the -webkit- vendor prefixed APIs. While we will continue our outreach efforts to encourage these sites to adopt standards-based mark-up, the support we've added is necessary today for the mobile web to just work. You can help here too if you see sites using non-standard code: we are collaborating with Mozilla at webcompat.com to record broken sites. These sites often cause issues across multiple browsers including Firefox and IE and it is easy for you to report problematic sites.

If you are a web developer, run your site through the scanner tool on http://modern.ie. This tool will identify common coding problems including issues with vendor prefixes and help you fix your code.

When taken all together, the changes we have made to IE in Windows Phone 8.1 Update dramatically improve compatibility with the most popular mobile web sites. The update is rolling out to those of you already on the Windows Phone 8.1 Preview for Developers and will roll out to consumers with devices running Windows Phone 8.1 in the coming months. We have also published a comprehensive list of all the changes in the IE Developer Guide on MSDN.

If you have questions, you can connect with us on Twitter @IEDevChat. The next #AskIE tweet chat is today (July 31) from 10AM-Noon PDT. Make sure you include #AskIE in your questions.

Adrian Bateman
Program Manager, Internet Explorer

Frank Olivier
Program Manager, Internet Explorer

Responsive Images: Use Cases and Documented Code Snippets to Get You Started

Source: Dev.OperaAndreas Bovens • 21 July 2014 10:00 PM

.feature { display:inline-block; padding:1px 10px; } .feature--false { background:#EEE; } .feature--true { background:#00A700; color:#FFF; }

Introduction

Finally, true responsive images are becoming a reality on the web — in pure HTML, without convoluted hacks. The <picture> element and a couple of new attributes for the <img> element are behind a flag in Chromium 37 and shipping in Chromium 38 (so coming soon in Opera), in Firefox Nightly and are being implemented in WebKit (although it remains to be seen if Apple will ship it in the next version of Safari).

The new <picture> element can be verbose and confusing, because it solves a range of use cases. To help you match your requirements to the responsive image syntax, we’ve prepared this article full of examples.

Four questions

Before you start using responsive images in your design, you always have to answer the following four questions:

In the examples below, we’re referring to these questions with the keywords sizes, dpi, mime and art, respectively, and then for each combination of answers, we show a snippet of example code with a short explanation. When creating these examples, I had this night shot of the Oslo Opera house in my head — it might be useful for your reference.

The Opera House in Oslo at night The Opera House in Oslo at night

Things to keep in mind

Before you start looking at the different examples though, here are a couple of things to keep in mind:

Art direction use case

sizes dpi mime art

<picture>
        <source
                media="(min-width: 1024px)"
                srcset="opera-fullshot.jpg">
        <img
                src="opera-closeup.jpg" alt="The Oslo Opera House">
</picture>

For browser windows with a width of 1024 CSS pixels and wider, a full-shot photo is used; smaller browser windows get a close-up photo.

Different image types use case

sizes dpi mime art

<picture>
        <source
                srcset="opera.webp"
                type="image/webp">
        <img
                src="opera.jpg" alt="The Oslo Opera House">
</picture>

Browsers that support WebP get a WebP image; other browsers get JPG.

Different image types & art direction use case

sizes dpi mime art

<picture>
        <source
                media="(min-width: 1024px)"
                srcset="opera-fullshot.webp"
                type="image/webp">
        <source
                media="(min-width: 1024px)"
                srcset="opera-fullshot.jpg">
        <source
                srcset="opera-closeup.webp"
                type="image/webp">
        <img
                src="opera-closeup.jpg" alt="The Oslo Opera House">
</picture>

For browser windows with a width of 1024 CSS pixels and wider, a full-shot photo is used; smaller browser windows get a close-up photo. This photo is served as WebP to browsers that support it; other browsers get JPG.

High-DPI images use case

sizes dpi mime art

<img
        src="opera-1x.jpg" alt="The Oslo Opera House"
        srcset="opera-2x.jpg 2x, opera-3x.jpg 3x">

Browsers on devices with high-DPI screens get a high resolution image; other browsers get a normal image.

High-DPI images & art direction use case

sizes dpi mime art

<picture>
        <source
                media="(min-width: 1024px)"
                srcset="opera-fullshot-1x.jpg 1x,
                                opera-fullshot-2x.jpg 2x,
                                opera-fullshot-3x.jpg 3x">
        <img
                src="opera-closeup-1x.jpg" alt="The Oslo Opera House"
                srcset="opera-closeup-2x.jpg 2x,
                                opera-closeup-3x.jpg 3x">
</picture>

For browser windows with a width of 1024 CSS pixels and wider, a full-shot photo is used; smaller browser windows get a close-up photo. In addition, these photos are served as high-resolution images to browsers on devices with high-DPI screens; other browsers get a normal image.

High-DPI images & different image types use case

sizes dpi mime art

<picture>
        <source
                srcset="opera-1x.webp 1x,
                                opera-2x.webp 2x,
                                opera-3x.webp 3x"
                type="image/webp">
        <img
                src="opera-1x.jpg" alt="The Oslo Opera House"
                srcset="opera-2x.jpg 2x,
                                opera-3x.jpg 3x">
</picture>

Browsers on devices with high-DPI screens get an image with twice or even three times the amount of pixels; other browsers get a normal image. These photos are served as WebP to browsers that support it; other browsers get JPG.

High-DPI images, different image types & art direction use case

sizes dpi mime art

<picture>
        <source
                media="(min-width: 1024px)"
                srcset="opera-fullshot-1x.webp 1x,
                                opera-fullshot-2x.webp 2x,
                                opera-fullshot-3x.webp 3x"
                type="image/webp">
        <source
                media="(min-width: 1024px)"
                srcset="opera-fullshot-1x.jpg 1x,
                                opera-fullshot-2x.jpg 2x,
                                opera-fullshot-3x.jpg 3x">
        <source
                srcset="opera-closeup-1x.webp 1x,
                                opera-closeup-2x.webp 2x,
                                opera-closeup-3x.webp 3x"
                type="image/webp">
        <img
                src="opera-closeup-1x.jpg" alt="The Oslo Opera House"
                srcset="opera-closeup-2x.jpg 2x,
                                opera-closeup-3x.jpg 3x">
</picture>

For browser windows with a width of 1024 CSS pixels and wider, a full-shot photo is used; smaller browser windows get a close-up photo. In addition, these photos are served as high-resolution images to browsers on devices with high-DPI screens; other browsers get a normal image. They are also served as WebP to browsers that support it; other browsers get JPG.

Changing image sizes use case

sizes dpi mime art

<img
        src="opera-400.jpg" alt="The Oslo Opera House"
        sizes="(min-width: 640px) 60vw, 100vw"
        srcset="opera-200.jpg 200w,
                        opera-400.jpg 400w,
                        opera-800.jpg 800w,
                        opera-1200.jpg 1200w">

For browser windows with a width of 640 CSS pixels and wider, a photo with a width of 60% of the viewport width is used; for less wide browser windows, a photo with a width that is equal to the full viewport width is used. The browser picks the optional image from a selection of images with widths of 200px, 400px, 800px and 1200px, keeping in mind image width and screen DPI.

Changing image sizes & art direction use case

sizes dpi mime art

<picture>
        <source
                media="(min-width: 1280px)"
                sizes="50vw"
                srcset="opera-fullshot-200.jpg 200w,
                                opera-fullshot-400.jpg 400w,
                                opera-fullshot-800.jpg 800w,
                                opera-fullshot-1200.jpg 1200w">
        <img
                src="opera-closeup-400.jpg" alt="The Oslo Opera House"
                sizes="(min-width: 640px) 60vw, 100vw"
                srcset="opera-closeup-200.jpg 200w,
                                opera-closeup-400.jpg 400w,
                                opera-closeup-800.jpg 800w,
                                opera-closeup-1200.jpg 1200w">
</picture>

For browser windows with a width of 1280 CSS pixels and wider, a full-shot photo with a width of 50% of the viewport width is used; for browser windows with a width of 640-1279 CSS pixels, a photo with a width of 60% of the viewport width is used; for less wide browser windows, a photo with a width that is equal to the full viewport width is used. In each case, the browser picks the optional image from a selection of images with widths of 200px, 400px, 800px and 1200px, keeping in mind image width and screen DPI.

Changing image sizes & different image types use case

sizes dpi mime art

<picture>
        <source
                sizes="(min-width: 640px) 60vw, 100vw"
                srcset="opera-200.webp 200w,
                                opera-400.webp 400w,
                                opera-800.webp 800w,
                                opera-1200.webp 1200w"
                type="image/webp">
        <img
                src="opera-400.jpg" alt="The Oslo Opera House"
                sizes="(min-width: 640px) 60vw, 100vw"
                srcset="opera-200.jpg 200w,
                                opera-400.jpg 400w,
                                opera-800.jpg 800w,
                                opera-1200.jpg 1200w">
</picture>

For browser windows with a width of 640 CSS pixels and wider, a photo with a width of 60% of the viewport width is used; for less wide browser windows, a photo with a width that is equal to the full viewport width is used. The browser picks the optional image from a selection of images with widths of 200px, 400px, 800px and 1200px, keeping in mind image width and screen DPI. These photos are served as WebP to browsers that support it; other browsers get JPG.

Changing image sizes, different image types & art direction use case

sizes dpi mime art

<picture>
        <source
                media="(min-width: 1280px)"
                sizes="50vw"
                srcset="opera-fullshot-200.webp 200w,
                                opera-fullshot-400.webp 400w,
                                opera-fullshot-800.webp 800w,
                                opera-fullshot-1200.webp 1200w"
                type="image/webp">
        <source
                sizes="(min-width: 640px) 60vw, 100vw"
                srcset="opera-closeup-200.webp 200w,
                                opera-closeup-400.webp 400w,
                                opera-closeup-800.webp 800w,
                                opera-closeup-1200.webp 1200w"
                type="image/webp">
        <source
                media="(min-width: 1280px)"
                sizes="50vw"
                srcset="opera-fullshot-200.jpg 200w,
                                opera-fullshot-400.jpg 400w,
                                opera-fullshot-800.jpg 800w,
                                opera-fullshot-1200.jpg 1200w">
        <img
                src="opera-closeup-400.jpg" alt="The Oslo Opera House"
                sizes="(min-width: 640px) 60vw, 100vw"
                srcset="opera-closeup-200.jpg 200w,
                                opera-closeup-400.jpg 400w,
                                opera-closeup-800.jpg 800w,
                                opera-closeup-1200.jpg 1200w">
</picture>

For browser windows with a width of 1280 CSS pixels and wider, a full-shot photo with a width of 50% of the viewport width is used; for browser windows with a width of 640-1279 CSS pixels, a photo with a width of 60% of the viewport width is used; for less wide browser windows, a photo with a width that is equal to the full viewport width is used. In each case, the browser picks the optional image from a selection of images with widths of 200px, 400px, 800px and 1200px, keeping in mind image width and screen DPI. These photos are served as WebP to browsers that support it; other browsers get JPG.

Changing image sizes & high-DPI images use case

sizes dpi mime art

<img
        src="opera-400.jpg" alt="The Oslo Opera House"
        sizes="(min-width: 640px) 60vw, 100vw"
        srcset="opera-200.jpg 200w,
                        opera-400.jpg 400w,
                        opera-800.jpg 800w,
                        opera-1200.jpg 1200w,
                        opera-1600.jpg 1600w,
                        opera-2000.jpg 2000w">

For browser windows with a width of 640 CSS pixels and wider, a photo with a width of 60% of the viewport width is used; for less wide browser windows, a photo with a width that is equal to the full viewport width is used. The browser picks the optional image from a selection of images with widths of 200px, 400px, 800px, 1200px, 1600px and 2000px, keeping in mind image width and screen DPI.

Changing image sizes, high-DPI images & art direction use case

sizes dpi mime art

<picture>
        <source
                media="(min-width: 1280px)"
                sizes="50vw"
                srcset="opera-fullshot-200.jpg 200w,
                                opera-fullshot-400.jpg 400w,
                                opera-fullshot-800.jpg 800w,
                                opera-fullshot-1200.jpg 1200w,
                                opera-fullshot-1600.jpg 1600w,
                                opera-fullshot-2000.jpg 2000w">
        <img
                src="opera-closeup-400.jpg" alt="The Oslo Opera House"
                sizes="(min-width: 640px) 60vw, 100vw"
                srcset="opera-closeup-200.jpg 200w,
                                opera-closeup-400.jpg 400w,
                                opera-closeup-800.jpg 800w,
                                opera-closeup-1200.jpg 1200w,
                                opera-closeup-1600.jpg 1600w,
                                opera-closeup-2000.jpg 2000w">
</picture>

For browser windows with a width of 1280 CSS pixels and wider, a full-shot photo with a width of 50% of the viewport width is used; for browser windows with a width of 640-1279 CSS pixels, a photo with a width of 60% of the viewport width is used; for less wide browser windows, a photo with a width that is equal to the full viewport width is used. In each case, the browser picks the optional image from a selection of images with widths of 200px, 400px, 800px, 1200px, 1600px and 2000px, keeping in mind image width and screen DPI.

Changing image sizes, high-DPI images & different image types use case

sizes dpi mime art

<picture>
        <source
                sizes="(min-width: 640px) 60vw, 100vw"
                srcset="opera-200.webp 200w,
                                opera-400.webp 400w,
                                opera-800.webp 800w,
                                opera-1200.webp 1200w,
                                opera-1600.webp 1600w,
                                opera-2000.webp 2000w"
                type="image/webp">
        <img
                src="opera-400.jpg" alt="The Oslo Opera House"
                sizes="(min-width: 640px) 60vw, 100vw"
                srcset="opera-200.jpg 200w,
                                opera-400.jpg 400w,
                                opera-800.jpg 800w,
                                opera-1200.jpg 1200w,
                                opera-1600.jpg 1600w,
                                opera-2000.jpg 2000w">
</picture>

For browser windows with a width of 640 CSS pixels and wider, a photo with a width of 60% of the viewport width is used; for less wide browser windows, a photo with a width that is equal to the full viewport width is used. The browser picks the optional image from a selection of images with widths of 200px, 400px, 800px, 1200px, 1600px and 2000px, keeping in mind image width and screen DPI. These photos are served as WebP to browsers that support it; other browsers get JPG.

Changing image sizes, high-DPI images, different image types & art direction use case

sizes dpi mime art

<picture>
        <source
                media="(min-width: 1280px)"
                sizes="50vw"
                srcset="opera-fullshot-200.webp 200w,
                                opera-fullshot-400.webp 400w,
                                opera-fullshot-800.webp 800w,
                                opera-fullshot-1200.webp 1200w,
                                opera-fullshot-1600.webp 1600w,
                                opera-fullshot-2000.webp 2000w"
                type="image/webp">
        <source
                sizes="(min-width: 640px) 60vw, 100vw"
                srcset="opera-closeup-200.webp 200w,
                                opera-closeup-400.webp 400w,
                                opera-closeup-800.webp 800w,
                                opera-closeup-1200.webp 1200w,
                                opera-closeup-1600.webp 1600w,
                                opera-closeup-2000.webp 2000w"
                type="image/webp">
        <source
                media="(min-width: 1280px)"
                sizes="50vw"
                srcset="opera-fullshot-200.jpg 200w,
                                opera-fullshot-400.jpg 400w,
                                opera-fullshot-800.jpg 800w,
                                opera-fullshot-1200.jpg 1200w,
                                opera-fullshot-1600.jpg 1800w,
                                opera-fullshot-2000.jpg 2000w">
        <img
                src="opera-closeup-400.jpg" alt="The Oslo Opera House"
                sizes="(min-width: 640px) 60vw, 100vw"
                srcset="opera-closeup-200.jpg 200w,
                                opera-closeup-400.jpg 400w,
                                opera-closeup-800.jpg 800w,
                                opera-closeup-1200.jpg 1200w,
                                opera-closeup-1600.jpg 1600w,
                                opera-closeup-2000.jpg 2000w">
</picture>

For browser windows with a width of 1280 CSS pixels and wider, a full-shot photo with a width of 50% of the viewport width is used; for browser windows with a width of 640-1279 CSS pixels, a photo with a width of 60% of the viewport width is used; for less wide browser windows, a photo with a width that is equal to the full viewport width is used. In each case, the browser picks the optional image from a selection of images with widths of 200px, 400px, 800px, 1200px, 1600px and 2000px, keeping in mind image width and screen DPI. These photos are served as WebP to browsers that support it; other browsers get JPG.

There is more!

Don’t worry if you haven’t understood this fully! Soon, we’ll publish an in-depth tutorial article on <picture> and responsive images. In the meantime, enjoy preparing to save your boss’ and customers’ bandwidth, and making your site even more performant.

Update: we’ve published a Native responsive images article, so be sure to check it out!

Opera 23 released

Source: Dev.OperaMathias Bynens • 21 July 2014 10:00 PM

Opera 23 (based on Chromium 36) for Mac and Windows is out! To find out what’s new for consumers, see our Desktop Team blog. Here’s what it means for web developers.

WOFF2 web fonts

Contrary to other web font formats, the new WOFF 2.0 Web Font compression format is optimized for file size, memory usage, and decompression speed.

To start enjoying these performance benefits, convert your existing web font to WOFF2, make sure your server is configured correctly, and add a single line to the @font-face declaration rule set, like so:

@font-face {
        font-family: MyAwesomeFont;
        src: url('MyAwesomeFont.eot');
        src: url('MyAwesomeFont.eot?#iefix') format('embedded-opentype'),
             /* Ready? Here comes the new part: */
             url('MyAwesomeFont.woff2') format('woff2'),
             /* That’s it! */
             url('MyAwesomeFont.woff') format('woff'),
             url('MyAwesomeFont.ttf') format('truetype'),
             url('MyAwesomeFont.svg#myawesomefont') format('svg');
        font-weight: normal;
        font-style: normal;
}

CSS touch-action

The touch-action CSS property is part of the Pointer Events specification. Its value determines whether touch input may trigger default browser behavior such as zooming or panning. For example, to disable all default touch behaviors on a particular element, you can now use:

.foo {
        touch-action: none;
}

CSS will-change

The will-change CSS property can be used to signal that a particular CSS property’s value, or an element’s content, is likely to change, so that the browser can optimize for these changes ahead of time. See Sara Soueidan’s article on will-change for more information.

Unprefixed CSS Transforms

Opera previously supported the -webkit-prefixed versions of the transform, transform-style, perspective, perspective-origin, and backface-visibility CSS properties. We now support the standardized and unprefixed names for these.

element.animate()

The Web Animations specification introduces a model that explains the execution of CSS Animations, CSS Transitions, and SVG Animations, and exposes a JavaScript API to give scripts similar capabilities. Opera and Chrome now support the element.animate() method as defined by this standard. Here’s a simple example:

// Animate the background of the <body> element
// from white to black in 2 seconds.
document.body.animate(
        [
                { 'background': 'white' },
                { 'background': 'black' }
        ],
        2000
);

For more, check out the element.animate() demo and its source code.

Support for the rest of the Web Animations API will be added in future releases.

Observing JavaScript objects with Object.observe()

Object.observe() makes it possible to easily observe changes to a given JavaScript object. Here’s a basic example:

var object = {};
// Start observing changes to the object.
Object.observe(object, function(changes) {
        changes.forEach(function(change, index) {
                console.log(change.name, change.type, change.object[change.name]);
        });
});
// Make some changes to the object.
object.first = 'John';
object.last = 'Smith';
delete object.first;

This functionality enables performant data binding implementations, which is good news for MVC libraries.

To cancel observation, Object.unobserve(object, callback) can be used. When dealing with arrays instead of objects, it’s easier to stick to Array.observe(array, callback) and Array.unobserve(array, callback). There’s Object.deliverChangeRecords(callback) and Object.getNotifier(object), too. See the Object.observe tutorial on HTML5 Rocks for more info.

ES6 WeakMap

WeakMaps are collections of key/value pairs in which the keys are objects and the values can be arbitrary values (as opposed to regular objects, where keys can only be string values). Here’s a simple example:

var map = new WeakMap();
var person = { 'name': 'John Smith' };
// Store a value in the WeakMap that is tied to this `person` object.
map.set(person, 'foo');
// Later, we can check if the WeakMap contains a matching value:
map.has(person); // true
// That value can be retrieved based on the `person` object:
map.get(person); // 'foo'

ES6 WeakSet

The new global WeakSet object lets you store weakly held objects (and only objects) in a collection. Here’s an example:

var map = new WeakSet();
var person1 = { 'name': 'John Smith' };
var person2 = { 'name': 'Pocahontas' };
// Add the `person1` object to the WeakSet.
map.add(person1);
// Later, we can check if the WeakSet contains any object:
map.has(person1); // true
map.has(person2); // false
// To remove an object from the set:
map.delete(person1);
map.has(person1); // false
// To remove all objects from the set:
map.clear();

HTML Imports

HTML Imports are a way to include and reuse HTML documents in other HTML documents. This feature falls under the Web Components umbrella. To learn more about HTML Imports, check out the tutorial on HTML5 Rocks.

What’s next?

If you’re interested in experimenting with features that are in the pipeline for future versions of Opera, we recommend following our Opera Developer stream.

Minutes Telecon 2014-07-16

Source: CSS WG BlogDael Jackson • 16 July 2014 09:51 PM

Full Minutes

Typography questions for HTML & CSS: Korean justification

Source: ishida blog » cssr12a • 10 July 2014 04:35 PM

Korean justification

The editors of the CSS3 Text module specification are currently trying to get more information about how to handle Korean justification, particularly when hanja (chinese ideographic characters) are mixed with Korean hangul.

Should the hanja be stretched with inter-character spacing at the same time as the Korean inter-word spaces are stretched? What if only a single word fits on a line, should it be stretched using inter-character spacing? Are there more sophisticated rules involving choices of justification location, as there are in Japanese where you adjust punctuation first and do inter-character spacing later? What if the whole text is hanja, such as for an ancient document?

If you are able to provide information, take a look at what’s in the CSS3 Text module and follow the thread on public-i18n-cjk@w3.org (subscribe).

Minutes Telecon 2014-07-09

Source: CSS WG BlogDael Jackson • 10 July 2014 03:35 PM

Full Minutes

This week: input APIs collaborations, W3C TAG by-election, etc.

Source: W3C Blog Coralie Mercier • 04 July 2014 05:59 PM

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

W3C and HTML5 related Twitter trends

[What was tweeted frequently, or caught my attention. Most recent first (popularity is flagged with a figure —number of times the same URIs or tweet was quoted/RTed.)]

And, on the lighter side

Open Web & net neutrality

W3C in the Press (or blogs)

6 articles since the 27-Jun Digest; a selection follows. You may read all articles in our Press Clippings page.

Minutes Telecon 2014-07-02

Source: CSS WG BlogDael Jackson • 03 July 2014 03:54 PM

Full Minutes

This week: #663399, W3C comma tools, Firefox WebIDE, etc.

Source: W3C Blog Coralie Mercier • 27 June 2014 04:27 PM

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

W3C and HTML5 related Twitter trends

[What was tweeted frequently, or caught my attention. Most recent first (popularity is flagged with a figure —number of times the same URIs or tweet was quoted/RTed.)]

Open Web & net neutrality

W3C in the Press (or blogs)

8 articles since the 20-Jun Digest; a selection follows. You may read all articles in our Press Clippings page.

Resolutions from Mailing List, 2014-06-21 to 2014-06-23

Source: CSS WG Blog Dael Jackson • 26 June 2014 03:47 PM

Two items were resolved on the mailing list. They are as follows:

Minutes Telecon 2014-06-25

Source: CSS WG BlogDael Jackson • 26 June 2014 03:37 PM

Full Minutes

Web Directions 2014

Source: Web Directions BlogJohn • 26 June 2014 01:06 AM

Late last week we took the wraps off our 10th Anniversary conference, Web Directions South, taking place October 30 and 31, at the brand new location of the Seymour Centre, located in the heart of one of Sydney’s most vibrant, creative, and definitely up and coming areas, Chippendale (only a kilometre from the CBD for folks from outside Sydney).

The feedback we’ve got has been extremely enthusiastic, and we’ve never seen such an uptake of tickets, so we really recommend you don’t put off registering only to be disappointed. Our new venue means this will almost certainly sell out. And to make it easier, you can register right now at the lowest price, and pay us later.

In 2004 we put on one of the very first conferences anywhere in the world specifically for the Web industry, and, if we’re being a little self-congratulatory, created the template for so many events that have followed. For 10 years we’ve worked incredibly hard to stay that one step ahead, unearthing speakers who’ve gone on to speak all over the world, including Nicole Sullivan (OOCSS debuted at Web Directions North 2009), Lea Verou, Rachel Andrew, Pasquale DeSilva, and Australia’s own Dmitry Baranovskyi among many. And of course, we’ve brought extraordinary speakers here to Australia for the first and often only chance to have seen them.

Along the way, our program has constantly changed with the needs of our industry, and we’ve partnered with W3C Australia, and international research conferences like the International Semantic Web Conference last year to bring a diversity and depth of content you’d have to go a long way to find anywhere else.

But this year to start our second decade we really challenged ourselves to do something special. With a brand new venue, we have wiped the slate clean, and asked ourselves “what does our industry in Australia look like, and why does it need to be thinking deeply about?” Our thinking coalesced around two main areas of focus, Engineering, and Product. And so we set out to put together the best program, not just in Australia, but the world for those designing, managing and building digital experiences (with of course as always a strong Web focus).

Whether we’ve succeeded in such a lofty ambition is ultimately for you to judge, but we don’t think we could have done much better. Some of the particular highlights for us include:

But in truth, there are 24 extraordinary, world-leading speakers, working in the near future, each one of whom we’re extremely proud and excited to bring to you. All you have to do is clear two days of your time in late October.

This year too, we’ve experimented a little with pricing. We’re still offering the same amazing two days of speakers, fully catered, with world class coffee, and parties, for the same price it’s been for years. But we’re offering some additional benefits for those with a little more budget to spend. It’s all explained at the conference site, but do drop us a line if you have any questions at all.

If you’ve been to a Web Directions event before, you know we’re passionate, independent supporters of the Web and all it can do. We promise you all this and more.
If you’ve not been to one of our events before, leave your pre-conception as to what a conference is like, and what it can do for you, at the door. We promise something special, that might even transform your life.

Check out all the details, at our rather spiffing conference site, and see you in October!

The post Web Directions 2014 appeared first on Web Directions.

Opera Mini 8 for iOS released

Source: Dev.OperaBruce Lawson • 25 June 2014 10:00 PM

Opera Mini for iOS

Today, we released Opera Mini 8 for iOS. It’s a completely redesigned product that, for the first time, offers three different browser modes, two of which save time and money for the consumer — or get them connected on slow networks that other browsers can’t handle. More details for consumers are available on mobile team blog.

If you’ve upgraded from the previous version, it will start in Mini mode. New installs will open in Turbo mode. The browser mode can be switched using the “O” button on the right of the toolbar.

Let’s look at those three modes in more detail:

Mini mode

This mode is how Opera Mini’s 244 million users experience your site. You must enable this mode to test your site through the Opera Mini servers.

This mode routes all traffic through our Opera Mini servers, which render pages then compress them by up to 90% before sending them to the client devices.

This means pages download much faster and — if you pay by the megabyte or are roaming — saves you a lot of money. The price to pay is that animations, gradients, rounded corners and other CSS extras are dropped. SVG images are supported, but animated images only render the first frame. Web fonts are not supported due to the download overhead (use SVG icons rather than icon fonts). JavaScript may not work as you would expect. Developers should read JavaScript and Opera Mini for a full description.

The rendering engine used is Opera Presto. The user agent string is Opera/9.80 (iPhone; Opera Mini/8.0.0/34.2336; U; en) Presto/2.8.119 Version/11.10. We are currently working on upgrading Opera Mini to use a newer version of Opera Presto, so CSS rem units and Flexbox are supported. As this upgrade is performed on our servers, all Opera Mini users will immediately benefit. There is no publicly-announced timescale for this upgrade.

If you rely on some sort of Geo IP tool for detecting a visitor’s location, note that the IP address you find in the headers when Mini mode is turned on is the one of our compression proxy. The user’s original IP address is passed on via the X-Forwarded-For header.

Turbo mode

Browser modes switcher with advanced compression settings

Opera Turbo mode is very different from Opera Mini mode. In this mode, rendering is done on the iPhone/ iPad, but some images and media are compressed through our servers. CSS and JavaScript behave as normal. HTTPS pages are not sent through our Turbo servers, even if Turbo mode is enabled.

Because this mode doesn’t send pages through the Opera Mini servers, it has a different User Agent string: Mozilla/5.0 (iPhone; CPU iPhone OS 7_1_1 like Mac OS X) AppleWebKit/537.51.2 (KHTML, like Gecko) OPiOS/8.0.0.78129 Mobile/11D201 Safari/9537.53.

Because of clause 2.17 in Apple’s App Store approval guideline, we can’t use Blink or V8; the rendering is done by the iOS WebKit framework and WebKit Javascript.

Opera Turbo mode is the preferred mode for speed and savings. You can control the quality of images using the slider in Advanced Settings after choosing this mode in the O Menu.

Note that if Turbo mode is on, the IP address is also modified, just as is the case with Mini (see above). You find the originating IP address under the X-Forwarded-For header.

Uncompressed mode

This mode does no compression at all; everything happens on the client device. This mode is useful when you’re connected to fast, stable wifi and you need highest quality images. The User Agent string and rendering engine is the same as for Opera Turbo mode.

QR Codes!

QR Codematic extension for Opera

Opera Mini 8 for iOS includes a QR code reader to save you from having to type an address. Check it out by tapping the address bar: above the keyboard a QR code icon is shown, which spawns a full QR code reader.

For easy sharing of a web address with a nearby friend, you can generate a QR code using O > Share > QR code. Your friends then can use a QR code reader to quickly load the page on their device.

We thought it would be nice to bring this QR Code based sharing mechanism also to desktop, and hence, we’ve implemented similar functionality in an extension. With QR Codematic you can generate QR codes from web pages and selected text, and even read QR codes using getUserMedia. Be sure to give it a try!

Power user tips

Address bar navigation toggle

Not strictly for web developers, but some useful power-user tips to speed up your testing in Opera Mini 8 for iOS:

That wraps up the developer-focussed information on Opera Mini 8 for iOS. But, of course, developers use the web a lot, and like to save time and money, so why not give it a try yourself?

This week: Picture Element, #HTML5 Last Call, #W3C20 Symposium, Tim Berners-Lee celebrated #web25 at #FENS2014, #663399becca, etc.

Source: W3C Blog Coralie Mercier • 20 June 2014 03:04 PM

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

W3C and HTML5 related Twitter trends

[What was tweeted frequently, or caught my attention. Most recent first (popularity is flagged with a figure —number of times the same URIs or tweet was quoted/RTed.)]

Open Web & net neutrality

W3C in the Press (or blogs)

22 articles since the 2-Jun Digest; a selection follows. You may read all articles in our Press Clippings page.

Minutes Seoul F2F Part VI: 2014-05-21 PM – CSS 3 Text, web-platform-tests and csswg-test github, annotate url(), Grid/Subgrid, position: sticky, Acknowledgements

Source: CSS WG BlogDael Jackson • 17 June 2014 10:45 PM

CSS 3 Text

Full Minutes || Spec Referenced

web-platform-tests and csswg-test github

Full Minutes

annotate url() with “crossorigin” “integrty” etc.

Full Minutes || Spec Referenced

Grid/Subgrid

Full Minutes || Spec Referenced

position: sticky

Full Minutes || Spec Referenced

Acknowledgements

Full Minutes

Feeds

The Future of Style features:

If you have a post you want to add to this feed, post a link (or the whole thing) on the CSS3 Soapbox. If you own a blog with frequent posts about the future of CSS, and want to be added to this aggregator, please get in touch with fantasai.

fantasai

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