[whatwg] img srcset for responsive bitmapped content images
Hi, When authors adapt their sites for high-resolution displays such as the iPhone's Retina display, they often need to be able to use different assets representing the same image. Doing this for content images in HTML is currently much more of a pain than it is in CSS (and it can be a pain in CSS). I think we can best address this problem for bitmap[1] content image by the addition of a srcset= attribute to the existing img element. The srcset= attribute takes as its argument a simplified variant of the image-set() microsyntax[2]. It would look something like this: img src=foo-lores.jpg srcset=foo-hires.jpg 2x, foo-superduperhires.jpg 6.5x alt=decent alt text for foo. img srcset takes one or more comma separated image specifiers. An image specifier consists of a URL to an image asset and an associated scale factor, expressed as a number followed by the literal character 'x'. (The value of img src is treated as if it had a 1x scale specified, so you can avoid duplicate references to the base asset.) User Agents may make their asset selection before fetching any of the assets, thus avoiding multiple asset loads the associated performance problems in constrained bandwidth environments. The intrinsic size of the img can be computed by dividing the intrinsic size of the actual image asset chosen with that asset's associated scale factor. Suppose that foo-lowres.jpg is 100x100 and foo-highres.jpg is 200x200 in the above example. If the UA chooses foo-lowres.jpg, it computes the intrisnic size as (100/1)x(100/1) = 100x100. If the UA chooses foo-highres.jpg, it computes the intrisnic size as (200/2)x(200/2) = 100x100. A nice thing about this proposal is its backwards compatibility story. Browsers which don't yet support img srcset will simply use the asset referenced by img src. A polyfill could easily be written to check for img srcset swap out a different asset into img src, much like existing libraries which check for data-fullsrc= or the like. Why provide a scale factor and not a media query? Well, media queries are claims about UA state, whereas here we're asserting something about the relationship between the image assets. Also, User Agents should be free to use whichever asset they deem best suited to their current situation, taking into account not just media-queriable things like device resolution but also any scaling applied to the img with CSS, its width= and height= attributes, or even things like the current page zoom level. Of course there are other things like bandwidth availability, data plan usage, etc. that web developers might want to take into account when choosing which image assets to load. This is definitely something worth exploring. In the future we could extend the asset descriptors to cover such cases. Something like this, maybe: img srcset=foo-lowres.jpg 1x low-bandwidth, foo-highres.jpg 2x high-bandwidth I'm purposefully not making a proposal for how to describe bandwidth, data plan usage, or such things here. Ultimately I don't think addressing the multiple-resolution case needs to wait for a solution to these other cases. We don't need to SOLVE ALL THE PROBLEMS! right now. One downside to this proposal is that the srcset= attribute takes a microsyntax, and as a rule we try to avoid novel microsyntaxes in attribute values. I think this particular microsyntax is pretty straightforward and shouldn't cause all that much confusion for authors. I think this is preferable to adding a suite of attributes with complex inter-relationships, such as in Anselm Hannemann's proposal from last August[3]. In such a proposal, we would either need to have a pre- approved list of image scales (like Anselm's xs, s, m, l, xl), which over-constrains designers' ability to create, or we would be introducing user data into attribute names which—with the one exception of the data-*= attributes—is something I really don't think we should do. Some have argued that we should just use conneg to serve the best image. This isn't an acceptable solution for at least three reasons: * The server doesn't have all of the relevant information needed to pick the best image, and sending that information with every image asset request is bandwidth-intensive and enables increased user fingerprinting. * HTML is used in a lot of contexts, such as in EPUB, in which there's no server to negotiate with in the first place.[4] * The UA should be able to swap out one asset for another transparently after the page has loaded. For instance, the UA might want to swap things out when the user zooms in. I also think this approach is better than minting a new image element, but I'll make that argument in another email. Ted 1. What responsive image problem? Just use SVG! :) 2. I've proposed image-set() for CSS4 Images. Here's the relevant post to www-style: http://lists.w3.org/Archives/Public/www-style/2012Feb/1103.html An implementation of image-set() has recently
Re: [whatwg] img srcset for responsive bitmapped content images
On Thu, May 10, 2012 at 10:58 AM, Edward O'Connor eocon...@apple.com wrote: The srcset= attribute takes as its argument a simplified variant of the image-set() microsyntax[2]. It would look something like this: img src=foo-lores.jpg srcset=foo-hires.jpg 2x, foo-superduperhires.jpg 6.5x alt=decent alt text for foo. img srcset takes one or more comma separated image specifiers. An image specifier consists of a URL to an image asset and an associated scale factor, expressed as a number followed by the literal character 'x'. (The value of img src is treated as if it had a 1x scale specified, so you can avoid duplicate references to the base asset.) User Agents may make their asset selection before fetching any of the assets, thus avoiding multiple asset loads the associated performance problems in constrained bandwidth environments. I'd like to throw in another use-case that might be addressable by the same feature: allowing Save As... to save a different version of the image (e.g., higher-res) than is actually displayed. Wikipedia, for instance, often has very high-res images that get scaled down for article viewing to save bandwidth and avoid possibly-ugly rescaling. (At least historically, some browsers used very bad rescaling algorithms.) It would be nice if when users saved the image, they saved the full-res version. Perhaps browsers could save the highest-res image available, rather than the one that happens to be used for display right now. Another obvious use-case I'd like to point out is print. It's not quite as trendy as the iPhone Retina display -- in fact maybe it's getting passé :) -- but print is generally higher-res than display, and it's common for images to appear pixelated when printing. This use-case might have the same requirements as the iPhone Retina display, but it should be kept in mind in case it doesn't. A fourth use-case I'd like to suggest is vector images. Last I checked, many authors don't want to serve SVG directly because too many browsers don't support it in img (or at all). Perhaps it should be possible to specify vector or something in place of a scale factor, to indicate that the image should be suitable for all resolutions. (A possible problem with this: very detailed SVGs can be much larger than the equivalent bitmaps, so the bandwidth tradeoff might not always be good. But authors can worry about that themselves, I guess, and not specify such vector images as possible sources.) It's possible that the best solution won't accommodate all of these use-cases, but I'm just throwing them out here so that they can be taken into account.
Re: [whatwg] img srcset for responsive bitmapped content images
Aryeh wrote: I'd like to throw in another use-case that might be addressable by the same feature: allowing Save As... to save a different version of the image (e.g., higher-res) than is actually displayed. […] Another obvious use-case I'd like to point out is print. Yes, these are both excellent reasons for us to adopt such a feature, and the img srcset proposal can handle both cases. A fourth use-case I'd like to suggest is vector images. Last I checked, many authors don't want to serve SVG directly because too many browsers don't support it in img (or at all). I'm not sure about this one. If a browser doesn't support SVG, I want to be able to provide a bitmap fallback regardless of how I included the SVG—in both the img src or inline svg element cases. img srcset isn't about providing fallback, so this might best be addressed with a different feature. It's possible that the best solution won't accommodate all of these use-cases, but I'm just throwing them out here so that they can be taken into account. *nod* Thanks, Ted
Re: [whatwg] img srcset for responsive bitmapped content images
On Thu, May 10, 2012 at 2:44 PM, Edward O'Connor eocon...@apple.com wrote: I'm not sure about this one. If a browser doesn't support SVG, I want to be able to provide a bitmap fallback regardless of how I included the SVG—in both the img src or inline svg element cases. img srcset isn't about providing fallback, so this might best be addressed with a different feature. There's already an easy script-free way to support fallback in inline svg -- add an img inside some element that SVG ignores. (I can't remember which one is recommended, but IIRC there is one that's suitable.) A browser that doesn't support svg will ignore all the SVG tags as unrecognized wrappers, and just display the img. A browser that supports svg will ignore the img. There's no good existing fallback for img that I know of. In practice, any browser that supports srcset will support SVG-in-img, and in principle vector images can be thought of as infinite-res, so it seems like it might be a useful feature to tack on. But this is the weakest use-case given, I agree, and it might be best not to solve it.
Re: [whatwg] img srcset for responsive bitmapped content images
You should look into the previous discussions at http://www.w3.org/community/respimg/ There's also a prototype using media queries at https://github.com/scottjehl/picturefill. I realize you specifically said you think media queries don't solve all of the problems, but it seems worth looking at. On Thu, May 10, 2012 at 3:58 AM, Edward O'Connor eocon...@apple.com wrote: Hi, When authors adapt their sites for high-resolution displays such as the iPhone's Retina display, they often need to be able to use different assets representing the same image. Doing this for content images in HTML is currently much more of a pain than it is in CSS (and it can be a pain in CSS). I think we can best address this problem for bitmap[1] content image by the addition of a srcset= attribute to the existing img element. The srcset= attribute takes as its argument a simplified variant of the image-set() microsyntax[2]. It would look something like this: img src=foo-lores.jpg srcset=foo-hires.jpg 2x, foo-superduperhires.jpg 6.5x alt=decent alt text for foo. img srcset takes one or more comma separated image specifiers. An image specifier consists of a URL to an image asset and an associated scale factor, expressed as a number followed by the literal character 'x'. (The value of img src is treated as if it had a 1x scale specified, so you can avoid duplicate references to the base asset.) User Agents may make their asset selection before fetching any of the assets, thus avoiding multiple asset loads the associated performance problems in constrained bandwidth environments. The intrinsic size of the img can be computed by dividing the intrinsic size of the actual image asset chosen with that asset's associated scale factor. Suppose that foo-lowres.jpg is 100x100 and foo-highres.jpg is 200x200 in the above example. If the UA chooses foo-lowres.jpg, it computes the intrisnic size as (100/1)x(100/1) = 100x100. If the UA chooses foo-highres.jpg, it computes the intrisnic size as (200/2)x(200/2) = 100x100. A nice thing about this proposal is its backwards compatibility story. Browsers which don't yet support img srcset will simply use the asset referenced by img src. A polyfill could easily be written to check for img srcset swap out a different asset into img src, much like existing libraries which check for data-fullsrc= or the like. Why provide a scale factor and not a media query? Well, media queries are claims about UA state, whereas here we're asserting something about the relationship between the image assets. Also, User Agents should be free to use whichever asset they deem best suited to their current situation, taking into account not just media-queriable things like device resolution but also any scaling applied to the img with CSS, its width= and height= attributes, or even things like the current page zoom level. Of course there are other things like bandwidth availability, data plan usage, etc. that web developers might want to take into account when choosing which image assets to load. This is definitely something worth exploring. In the future we could extend the asset descriptors to cover such cases. Something like this, maybe: img srcset=foo-lowres.jpg 1x low-bandwidth, foo-highres.jpg 2x high-bandwidth I'm purposefully not making a proposal for how to describe bandwidth, data plan usage, or such things here. Ultimately I don't think addressing the multiple-resolution case needs to wait for a solution to these other cases. We don't need to SOLVE ALL THE PROBLEMS! right now. One downside to this proposal is that the srcset= attribute takes a microsyntax, and as a rule we try to avoid novel microsyntaxes in attribute values. I think this particular microsyntax is pretty straightforward and shouldn't cause all that much confusion for authors. I think this is preferable to adding a suite of attributes with complex inter-relationships, such as in Anselm Hannemann's proposal from last August[3]. In such a proposal, we would either need to have a pre- approved list of image scales (like Anselm's xs, s, m, l, xl), which over-constrains designers' ability to create, or we would be introducing user data into attribute names which—with the one exception of the data-*= attributes—is something I really don't think we should do. Some have argued that we should just use conneg to serve the best image. This isn't an acceptable solution for at least three reasons: * The server doesn't have all of the relevant information needed to pick the best image, and sending that information with every image asset request is bandwidth-intensive and enables increased user fingerprinting. * HTML is used in a lot of contexts, such as in EPUB, in which there's no server to negotiate with in the first place.[4] * The UA should be able to swap out one asset for another transparently after the page has loaded. For instance, the UA
Re: [whatwg] img srcset for responsive bitmapped content images
This proposal has a similar issue to image-set() - if the 2x means
twice the resolution (which it should), this will *not work by
default*. If you make a 5 inch wide image and save it as 200dpi, when
you send it to the browser its automatic size will be 10 inches wide.
Browsers are constrained by back-compat to always display images at
96dpi. You can get around this by explicitly setting img width, but
we shouldn't require that if we can avoid it.
This isn't hard to fix, of course; the fix just isn't included right now.
CSS3 Images has the image-resolution property, which lets you tell the
browser what resolution to display the image at (that is, how it
should determine the automatic size). You can say image-resolution:
from-image; to get it to use the image's native resolution, whatever
it is. So, we need to add a rule to the UA stylesheet that says
img[srcset] { image-resolution: from-image; }.
In the closely-related case of using image-set() in CSS, we can just
have the winning image set the default resolution. An earlier
version of the image() function let you set an image's resolution
immediately, but we punted it for simplicity at level 3. This would
do the same thing.
That all said, I don't like the 2x notation. It's declaring this
image's resolution is twice that of a normal image. This has two
problems. For one, we already have a unit that means that - the dppx
unit. Using 2dppx is identical to the meaning of 2x. Since
image-set() is newer than the dppx unit, we should change it to use
resolution instead.
For two, I'm not sure that it's particularly obvious that when you say
2x, you should make sure your image was saved as 196dpi. You have
to already know what the default resolution is. As well, I think that
values like 300dpi are pretty common, and they don't map to integral
'x' values. If people say screw it and use 3x, this'll be
slightly wrong and I think will cause ugly blurring. If we make this
take resolution, people can just use the dpi unit.
I agree overall that this is the right approach - declaring relevant
information to the browser and letting it decide what to do is better
than trying to set up constraints by yourself. For example, using MQ
could result in the silly situation of downloading a high-res image at
first because you're on 4G, then throwing them away and downloading
low-res images when you drop to 2G. Using image-set() or @srcset
would let the browser keep the images it had already downloaded.
~TJ
~TJ
Re: [whatwg] img srcset for responsive bitmapped content images
On Thu, 10 May 2012 15:24:28 +0200, Tab Atkins Jr. jackalm...@gmail.com
wrote:
This proposal has a similar issue to image-set() - if the 2x means
twice the resolution (which it should), this will *not work by
default*. If you make a 5 inch wide image and save it as 200dpi, when
you send it to the browser its automatic size will be 10 inches wide.
Browsers are constrained by back-compat to always display images at
96dpi. You can get around this by explicitly setting img width, but
we shouldn't require that if we can avoid it.
This isn't hard to fix, of course; the fix just isn't included right now.
We should indeed fix it.
CSS3 Images has the image-resolution property, which lets you tell the
browser what resolution to display the image at (that is, how it
should determine the automatic size). You can say image-resolution:
from-image; to get it to use the image's native resolution, whatever
it is. So, we need to add a rule to the UA stylesheet that says
img[srcset] { image-resolution: from-image; }.
Do we want from-image here? Or do authors prefer to serve 96dpi images
that are bigger, and specify the intended dpi in the markup?
In the closely-related case of using image-set() in CSS, we can just
have the winning image set the default resolution. An earlier
version of the image() function let you set an image's resolution
immediately, but we punted it for simplicity at level 3. This would
do the same thing.
That all said, I don't like the 2x notation. It's declaring this
image's resolution is twice that of a normal image. This has two
problems. For one, we already have a unit that means that - the dppx
unit. Using 2dppx is identical to the meaning of 2x. Since
image-set() is newer than the dppx unit, we should change it to use
resolution instead.
For two, I'm not sure that it's particularly obvious that when you say
2x, you should make sure your image was saved as 196dpi. You have
to already know what the default resolution is. As well, I think that
values like 300dpi are pretty common, and they don't map to integral
'x' values. If people say screw it and use 3x, this'll be
slightly wrong and I think will cause ugly blurring. If we make this
take resolution, people can just use the dpi unit.
Can we just use CSS's 'dpi' instead?
img src=default.jpg srcset=highres.jpg 300dpi
I agree overall that this is the right approach - declaring relevant
information to the browser and letting it decide what to do is better
than trying to set up constraints by yourself. For example, using MQ
could result in the silly situation of downloading a high-res image at
first because you're on 4G, then throwing them away and downloading
low-res images when you drop to 2G. Using image-set() or @srcset
would let the browser keep the images it had already downloaded.
Indeed.
--
Simon Pieters
Opera Software
Re: [whatwg] img srcset for responsive bitmapped content images
Hi, This proposal has a similar issue to image-set() - if the 2x means twice the resolution (which it should), this will *not work by default*. Just a quick update for the list—Tab and I chatted about this F2F just now and we agree that there isn't really a problem here, so long as the spec text is sufficiently detailed. Ted
Re: [whatwg] img srcset for responsive bitmapped content images
On Thu, May 10, 2012 at 3:47 PM, Simon Pieters sim...@opera.com wrote:
On Thu, 10 May 2012 15:24:28 +0200, Tab Atkins Jr. jackalm...@gmail.com
wrote:
CSS3 Images has the image-resolution property, which lets you tell the
browser what resolution to display the image at (that is, how it
should determine the automatic size). You can say image-resolution:
from-image; to get it to use the image's native resolution, whatever
it is. So, we need to add a rule to the UA stylesheet that says
img[srcset] { image-resolution: from-image; }.
Do we want from-image here? Or do authors prefer to serve 96dpi images that
are bigger, and specify the intended dpi in the markup?
Can you clarify what you mean by this? Do you mean serving a 10inch
wide image at 96dpi rather than a 5inch wide image at 192dpi, and then
telling the browser to scale it by the x factor?
The two are identical in the image's data (they're all 960 pixels
wide), only the metadata differs.
I suspect both:
1. A lot of authors would find it very confusing if they couldn't save
an image at 300dpi and have it just work, and
2. A lot of authors will be confused to discover that that they have
to save their image as 300dpi to get it to work.
For two, I'm not sure that it's particularly obvious that when you say
2x, you should make sure your image was saved as 196dpi. You have
to already know what the default resolution is. As well, I think that
values like 300dpi are pretty common, and they don't map to integral
'x' values. If people say screw it and use 3x, this'll be
slightly wrong and I think will cause ugly blurring. If we make this
take resolution, people can just use the dpi unit.
Can we just use CSS's 'dpi' instead?
img src=default.jpg srcset=highres.jpg 300dpi
If you take dpi, you might as well take all of the resolution units.
There's only 3 so far - dpi, dpcm, and dppx. There's no good reason
to limit to only one of them, since they're all constant multiples of
each other.
~TJ
Re: [whatwg] img srcset for responsive bitmapped content images
On May 10, 2012, at 9:47 AM, Simon Pieters wrote:
On Thu, 10 May 2012 15:24:28 +0200, Tab Atkins Jr. jackalm...@gmail.com
wrote:
This proposal has a similar issue to image-set() - if the 2x means
twice the resolution (which it should), this will *not work by
default*. If you make a 5 inch wide image and save it as 200dpi, when
you send it to the browser its automatic size will be 10 inches wide.
Browsers are constrained by back-compat to always display images at
96dpi. You can get around this by explicitly setting img width, but
we shouldn't require that if we can avoid it.
This isn't hard to fix, of course; the fix just isn't included right now.
We should indeed fix it.
CSS3 Images has the image-resolution property, which lets you tell the
browser what resolution to display the image at (that is, how it
should determine the automatic size). You can say image-resolution:
from-image; to get it to use the image's native resolution, whatever
it is. So, we need to add a rule to the UA stylesheet that says
img[srcset] { image-resolution: from-image; }.
Do we want from-image here? Or do authors prefer to serve 96dpi images that
are bigger, and specify the intended dpi in the markup?
In the closely-related case of using image-set() in CSS, we can just
have the winning image set the default resolution. An earlier
version of the image() function let you set an image's resolution
immediately, but we punted it for simplicity at level 3. This would
do the same thing.
That all said, I don't like the 2x notation. It's declaring this
image's resolution is twice that of a normal image. This has two
problems. For one, we already have a unit that means that - the dppx
unit. Using 2dppx is identical to the meaning of 2x. Since
image-set() is newer than the dppx unit, we should change it to use
resolution instead.
For two, I'm not sure that it's particularly obvious that when you say
2x, you should make sure your image was saved as 196dpi. You have
to already know what the default resolution is. As well, I think that
values like 300dpi are pretty common, and they don't map to integral
'x' values. If people say screw it and use 3x, this'll be
slightly wrong and I think will cause ugly blurring. If we make this
take resolution, people can just use the dpi unit.
Can we just use CSS's 'dpi' instead?
img src=default.jpg srcset=highres.jpg 300dpi
Hey guys. Don’t know if it’s too early to chime in with this, but we were told
by some members of the Chrome team that any browser that supports DNS
prefetching — including assets — wouldn’t consider “looking-ahead” on the img
tag as an option. The original src would be fetched in any case, saddling users
with a redundant download.
I’ve been living and breathing this topic in the Responsive Images Community
Group for months now, so I’m psyched to see the problem getting some attention!
I agree overall that this is the right approach - declaring relevant
information to the browser and letting it decide what to do is better
than trying to set up constraints by yourself. For example, using MQ
could result in the silly situation of downloading a high-res image at
first because you're on 4G, then throwing them away and downloading
low-res images when you drop to 2G. Using image-set() or @srcset
would let the browser keep the images it had already downloaded.
Indeed.
--
Simon Pieters
Opera Software
Re: [whatwg] img srcset for responsive bitmapped content images
On 5/10/12 10:19 AM, Mathew Marquis wrote: Hey guys. Don’t know if it’s too early to chime in with this, but we were told by some members of the Chrome team that any browser that supports DNS prefetching — including assets — wouldn’t consider “looking-ahead” on the img tag as an option. Why not? In any case, _DNS_ prefetching would be the same for both the low-res and high-res image, I would think. The original src would be fetched in any case, saddling users with a redundant download. That sounds like image prefetching, not DNS prefetching. I see no obvious reason it couldn't look at multiple attributes. -Boris
Re: [whatwg] img srcset for responsive bitmapped content images
On Thu, 10 May 2012 16:19:13 +0200, Tab Atkins Jr. jackalm...@gmail.com
wrote:
On Thu, May 10, 2012 at 3:47 PM, Simon Pieters sim...@opera.com wrote:
On Thu, 10 May 2012 15:24:28 +0200, Tab Atkins Jr.
jackalm...@gmail.com
wrote:
CSS3 Images has the image-resolution property, which lets you tell the
browser what resolution to display the image at (that is, how it
should determine the automatic size). You can say image-resolution:
from-image; to get it to use the image's native resolution, whatever
it is. So, we need to add a rule to the UA stylesheet that says
img[srcset] { image-resolution: from-image; }.
Do we want from-image here? Or do authors prefer to serve 96dpi images
that
are bigger, and specify the intended dpi in the markup?
Can you clarify what you mean by this? Do you mean serving a 10inch
wide image at 96dpi rather than a 5inch wide image at 192dpi, and then
telling the browser to scale it by the x factor?
Yeah.
The two are identical in the image's data (they're all 960 pixels
wide), only the metadata differs.
Right. I gathered that from-image would use the metadata.
I suspect both:
1. A lot of authors would find it very confusing if they couldn't save
an image at 300dpi and have it just work, and
This is the situation today for img src, and I guess we can't change it
now. We can provide an opt-in, though, that could also work for img src
(like CSS image-resolution).
2. A lot of authors will be confused to discover that that they have
to save their image as 300dpi to get it to work.
Yeah. Since the author needs to specify the resolution in the markup to
inform the browser which image to download, we might as well use that
information since it's more likely to be the intended dpi.
Can we just use CSS's 'dpi' instead?
img src=default.jpg srcset=highres.jpg 300dpi
If you take dpi, you might as well take all of the resolution units.
There's only 3 so far - dpi, dpcm, and dppx. There's no good reason
to limit to only one of them, since they're all constant multiples of
each other.
WFM.
--
Simon Pieters
Opera Software
Re: [whatwg] img srcset for responsive bitmapped content images
On May 10, 2012, at 8:36 AM, Scott González wrote: You should look into the previous discussions at http://www.w3.org/community/respimg/ There's also a prototype using media queries at https://github.com/scottjehl/picturefill. I realize you specifically said you think media queries don't solve all of the problems, but it seems worth looking at. I can’t second Scott’s suggestion enough. There is a ton of history and valuable conversation around this topic already in the Community Group, and we’ve been working with a couple of browser reps trying to get this thing solved. We’ve even gone so far as to put the solution that seems to have the most legs together as a sort-of spec, so all the details are in one easily-parsed place: https://github.com/Wilto/respimg On Thu, May 10, 2012 at 3:58 AM, Edward O'Connor eocon...@apple.com wrote: Hi, When authors adapt their sites for high-resolution displays such as the iPhone's Retina display, they often need to be able to use different assets representing the same image. Doing this for content images in HTML is currently much more of a pain than it is in CSS (and it can be a pain in CSS). I think we can best address this problem for bitmap[1] content image by the addition of a srcset= attribute to the existing img element. The srcset= attribute takes as its argument a simplified variant of the image-set() microsyntax[2]. It would look something like this: img src=foo-lores.jpg srcset=foo-hires.jpg 2x, foo-superduperhires.jpg 6.5x alt=decent alt text for foo. img srcset takes one or more comma separated image specifiers. An image specifier consists of a URL to an image asset and an associated scale factor, expressed as a number followed by the literal character 'x'. (The value of img src is treated as if it had a 1x scale specified, so you can avoid duplicate references to the base asset.) User Agents may make their asset selection before fetching any of the assets, thus avoiding multiple asset loads the associated performance problems in constrained bandwidth environments. The intrinsic size of the img can be computed by dividing the intrinsic size of the actual image asset chosen with that asset's associated scale factor. Suppose that foo-lowres.jpg is 100x100 and foo-highres.jpg is 200x200 in the above example. If the UA chooses foo-lowres.jpg, it computes the intrisnic size as (100/1)x(100/1) = 100x100. If the UA chooses foo-highres.jpg, it computes the intrisnic size as (200/2)x(200/2) = 100x100. A nice thing about this proposal is its backwards compatibility story. Browsers which don't yet support img srcset will simply use the asset referenced by img src. A polyfill could easily be written to check for img srcset swap out a different asset into img src, much like existing libraries which check for data-fullsrc= or the like. Why provide a scale factor and not a media query? Well, media queries are claims about UA state, whereas here we're asserting something about the relationship between the image assets. Also, User Agents should be free to use whichever asset they deem best suited to their current situation, taking into account not just media-queriable things like device resolution but also any scaling applied to the img with CSS, its width= and height= attributes, or even things like the current page zoom level. Of course there are other things like bandwidth availability, data plan usage, etc. that web developers might want to take into account when choosing which image assets to load. This is definitely something worth exploring. In the future we could extend the asset descriptors to cover such cases. Something like this, maybe: img srcset=foo-lowres.jpg 1x low-bandwidth, foo-highres.jpg 2x high-bandwidth I'm purposefully not making a proposal for how to describe bandwidth, data plan usage, or such things here. Ultimately I don't think addressing the multiple-resolution case needs to wait for a solution to these other cases. We don't need to SOLVE ALL THE PROBLEMS! right now. One downside to this proposal is that the srcset= attribute takes a microsyntax, and as a rule we try to avoid novel microsyntaxes in attribute values. I think this particular microsyntax is pretty straightforward and shouldn't cause all that much confusion for authors. I think this is preferable to adding a suite of attributes with complex inter-relationships, such as in Anselm Hannemann's proposal from last August[3]. In such a proposal, we would either need to have a pre- approved list of image scales (like Anselm's xs, s, m, l, xl), which over-constrains designers' ability to create, or we would be introducing user data into attribute names which—with the one exception of the data-*= attributes—is something I really don't think we should do. Some have argued that we should just use conneg to serve the best image. This isn't an acceptable solution
Re: [whatwg] img srcset for responsive bitmapped content images
On Thu, May 10, 2012 at 4:45 PM, Mathew Marquis m...@matmarquis.com wrote: On May 10, 2012, at 8:36 AM, Scott González wrote: You should look into the previous discussions at http://www.w3.org/community/respimg/ There's also a prototype using media queries at https://github.com/scottjehl/picturefill. I realize you specifically said you think media queries don't solve all of the problems, but it seems worth looking at. I can’t second Scott’s suggestion enough. There is a ton of history and valuable conversation around this topic already in the Community Group, and we’ve been working with a couple of browser reps trying to get this thing solved. We’ve even gone so far as to put the solution that seems to have the most legs together as a sort-of spec, so all the details are in one easily-parsed place: https://github.com/Wilto/respimg The Responsive Images work is intended to solve a different issue than the send high-res versions if you have the screen and bandwidth to do so. It's for serving different images based on various MQ conditions, just baked into HTML markup rather than hacking it in via backgrounds. MQs, though, are a fundamentally unsound method for doing bandwidth-responsive image serving. I gave the basic example of why it fails in an earlier message in this thread. ~TJ
Re: [whatwg] Proposal in supporting the writing of Arabizi
On Tue, May 8, 2012 at 2:38 PM, Ian Hickson i...@hixie.ch wrote: On Thu, 1 Dec 2011, Sami Eljabali wrote: There's a need for phonetic based keyboard support for Arabic speaking users on today's internet. There are two primary reasons for this: 1) Many Arabic speaking users don't surf in Arabic. A good portion of them are in non-arabic speaking countries, hence more often than not have non-arabic keyboards therefore finding it difficult to write Arabic on the internet. There are on the contrary, virtual Arabic keyboards on the OS level, as well as on sites like Google http://www.google.ae/ addressing this, however phonetically spelling out a word, and seeing a list of words containing the one you were trying to spell out is dramatically more effective than the counterpart. 2) It vastly aids those with lacking a thorough Arabic education to properly to spell out what they phonetically know, hence allows a greater audience including non-natives to write in Arabic. *Proposal:* Have the interpreter described above be embedded within browsers and enabled when users click and focus on text fields defined as: input type=text lang=arabizi to interpret Arabizihttp://en.wikipedia.org/wiki/Arabic_chat_alphabetas Arabic. Should a browser not support it, then the input type=text would be the fallback attribute leaving users writing in a plain text field. As far as I can tell, nothing stops a Web browser or operating system from implementing this kind of thing today. No need for the specification to say anything special. On Thu, 1 Dec 2011, Tab Atkins Jr. wrote: We are looking into something like this for many languages. I've attempted to record this as a use-case on http://wiki.whatwg.org/wiki/Text_input_keyboard_mode_control, but I can't figure out how to upload images yet. Once I do, I'll add screenshots, an explanation, and a link to this thread. Supporting this kind of thing is definitely on the table, but as you hint above, it needs more research first. On Sun, 4 Dec 2011, Sami Eljabali wrote: I feel more thought could be put in swaying IME's off OSs, as it is limiting in availability for all. I don't understand. Everybody has an operating system. Why would putting things in the operating system limit availability? Operating systems and their GUIs are responsible for almost everything that a browser does, at one level or another. Good luck pushing Apple Microsoft in implementing this. If we create this as a tag then we'd push every OS vendor to support it. On Sun, 4 Dec 2011, Sami Eljabali wrote: By not moving IME's off OSes, you're asking every OS connecting to the internet to support this feature. Netbooks for example, may just have a native web browser on it. Would its OS then need to implement its own IME for a few languages for their entry? Instead its web browser could just support the input field, given they can render them. On Sun, 4 Dec 2011, Ryosuke Niwa wrote: Why would implementing IME for such an OS be harder than implementing one for the web browser? Indeed. From the spec's point of view, they're more or less equivalent. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal: Add window.getLastError (or modify invocation arguments of window.onerror)
In my opinion, adding the stack trace to the existing message would be
messy, breaks existing developer expectations, and possibly even breaks
backward compatibility of specific libraries/functions/monitoring/etc. in
some more extreme situations. If we can't just have the Error object
itself passed in, I'd much prefer stack as a fifth parameter versus
unexpected modification of an existing parameter.
We can also keep adding parameters to the window.onerror invocation till
we're blue in the face... but, in reality, don't we just want all of the
properties of the relevant Error object? I'd really love to *just* have
the Error object passed (e.g. window.onerror(function(e) { ... })) but
I know that would break backward compatibility, so I didn't propose it.
It seems to me like columnNumber should be added to the Error object as
a standard (speaking of which: https://github.com/JSFixed/JSFixed/issues/51)
*instead of* adding it as yet another parameter to the already ugly
window.onerror, and then just pass the Error object so devs can get
whatever information they want from it. But, if it's a security thing, I
guess I'm willing to accept that
Sincerely,
James Greene
On Wed, May 9, 2012 at 4:12 AM, Simon Pieters sim...@opera.com wrote:
On Wed, 09 May 2012 03:56:29 +0200, James Greene james.m.gre...@gmail.com
wrote:
Full proposal details:
https://gist.github.com/**3ded0f6e7f0a658b9394https://gist.github.com/3ded0f6e7f0a658b9394
quoting the above (revision https://gist.github.com/**
3ded0f6e7f0a658b9394/**51e980f0474c255738a3b6ecf003bb**6cb30db49chttps://gist.github.com/3ded0f6e7f0a658b9394/51e980f0474c255738a3b6ecf003bb6cb30db49c):
# Proposal: Add `window.getLastError` (or modify `window.onerror`)
## Error handling in an isolated scope
In our applications, most of us hopefully follow the UX best practice of
catching unexpected and/or unpreventable errors and logging them back to
the server-side for monitoring.
In isolated scopes, this can be achieved by setting up a try-catch block,
which also allows you to inspect the pertinent [`Error`][1] object itself:
```
try {
throw new Error(WTF);
} catch (e) {
alert(Isolated error! Details: + e);
}
```
This is very useful, especially in browsers that support the [`stack`][2]
property of the `Error` object to improve debugability. This property's
availability is also of great benefit to @eriwen's [StackTrace.js][3],
which I find to be handy (though I'm not a big fan of the StrackTrace.js
API, as @eriwen and I have discussed previously).
## Error handling at the global scope
Setting up layers of try-catch blocks quickly becomes unreasonable in
large applications. As an alternative, we can attach a listener to the
[`window`][4] object's [`error`][5] event, which is invoked whenever an
error bubbles up without being handled elsewhere:
(It's not actually a real event.)
```
var oldOnError = window.onerror;
window.onerror = function myErrorHandler(errorMsg, url, lineNumber) {
if (oldOnError) {
return oldOnError(errorMsg, url, lineNumber);
}
alert(Globally unhandled error! Details: + errorMsg);
return false;
}
```
## The problem with `window.onerror`
The problem is that this mechanism does not allow us to inspect the
pertinent `Error` object at all: it only provides us with three arguments
at invocation time: message (string), fileName (string), and lineNumber
(number). These are rarely useful in practice.
The spec now has a fourth argument for the column number (which is more
useful than line number for minimized scripts). Maybe column could be made
available on exceptions as well, though that's up to TC39, I think.
('stack' isn't specified currently, IIRC.)
## My proposal(s) to fix it
As such, I propose the following two options as fixes:
1. Add a function like `getLastError` to the global `window` object that
would fetch the actual `Error` object associated with the most recent
unhandled error. I would foresee common usage looking something like the
following:
```
var oldOnError = window.onerror;
window.onerror = function myErrorHandler(errorMsg, url, lineNumber) {
if (oldOnError) {
return oldOnError(errorMsg, url, lineNumber);
}
var e = window.getLastError();
alert(Globally unhandled error! But we now can discover its
origin. Details: + e);
return false;
}
```
2. Alternatively (though less preferably), we could also update the
invocation arguments of `window.onerror` callbacks to include a new fourth
argument that would be the relevant `Error` object itself:
```
var oldOnError = window.onerror;
window.onerror = function myErrorHandler(errorMsg, url, lineNumber, e)
{
if (oldOnError) {
return oldOnError(errorMsg, url, lineNumber, e);
}
alert(Globally unhandled error! But we now can discover its
origin. Details: + e);
return false;
}
Re: [whatwg] Proposal in supporting the writing of Arabizi
On Thu, 10 May 2012, Sami Eljabali wrote: I don't understand. Everybody has an operating system. Why would putting things in the operating system limit availability? Operating systems and their GUIs are responsible for almost everything that a browser does, at one level or another. Good luck pushing Apple Microsoft in implementing this. If we create this as a tag then we'd push every OS vendor to support it. Why would Apple and Microsoft be any more likely to think it worth implementing in their browser than in their operating system? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] img srcset for responsive bitmapped content images
On May 10, 2012, at 6:24 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: That all said, I don't like the 2x notation. It's declaring this image's resolution is twice that of a normal image. This has two problems. For one, we already have a unit that means that - the dppx unit. Using 2dppx is identical to the meaning of 2x. Since image-set() is newer than the dppx unit, we should change it to use resolution instead. dppx has the downside that not even CSS Working Group members can consistently spell it correctly. Regards, Maciej
Re: [whatwg] img srcset for responsive bitmapped content images
On May 10, 2012, at 6:47 AM, Simon Pieters sim...@opera.com wrote: On Thu, 10 May 2012 15:24:28 +0200, Tab Atkins Jr. jackalm...@gmail.com wrote: For two, I'm not sure that it's particularly obvious that when you say 2x, you should make sure your image was saved as 196dpi. You have to already know what the default resolution is. As well, I think that values like 300dpi are pretty common, and they don't map to integral 'x' values. If people say screw it and use 3x, this'll be slightly wrong and I think will cause ugly blurring. If we make this take resolution, people can just use the dpi unit. Can we just use CSS's 'dpi' instead? img src=default.jpg srcset=highres.jpg 300dpi CSS's 'dpi' is confusing, because it actually defines the ratio of device pixels to CSS inches, not device pixels to physical inches, as most users would expect 'dpi' to mean in the context of a graphics program. So 300dpi would mean the same thing as 3.125x, and would likely itself result in ugly blurring, since scaling by a fractional scale factor rarely looks crisp. Regards, Maciej
Re: [whatwg] img srcset for responsive bitmapped content images
On May 10, 2012, at 7:26 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 5/10/12 10:19 AM, Mathew Marquis wrote: Hey guys. Don’t know if it’s too early to chime in with this, but we were told by some members of the Chrome team that any browser that supports DNS prefetching — including assets — wouldn’t consider “looking-ahead” on the img tag as an option. Why not? In any case, _DNS_ prefetching would be the same for both the low-res and high-res image, I would think. The original src would be fetched in any case, saddling users with a redundant download. That sounds like image prefetching, not DNS prefetching. I see no obvious reason it couldn't look at multiple attributes. Indeed. I'm reasonably familiar with WebKit's preloading code and I see no reason it couldn't look at the srcset attribute. This would work fine for scale factor selection. Unfortunately, it would not work for the suggestion to have srcset pick images to fit available space based on width and height. Available space is not known until layout time, which happens too late for preloading decisions. So width/height fitting would defeat prefetch, regardless of specific syntax used. Perhaps this is what the Chrome engineers were thinking of; hard to say without more detail. Regards, Maciej
Re: [whatwg] Proposal in supporting the writing of Arabizi
Because then they wouldn't be HMTL5 compliant vs not having a nifty feature. How would you push this forward being adopted? I'm mostly likely not thinking creatively enough. On Thu, May 10, 2012 at 12:38 PM, Ian Hickson i...@hixie.ch wrote: On Thu, 10 May 2012, Sami Eljabali wrote: I don't understand. Everybody has an operating system. Why would putting things in the operating system limit availability? Operating systems and their GUIs are responsible for almost everything that a browser does, at one level or another. Good luck pushing Apple Microsoft in implementing this. If we create this as a tag then we'd push every OS vendor to support it. Why would Apple and Microsoft be any more likely to think it worth implementing in their browser than in their operating system? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal in supporting the writing of Arabizi
On Thu, May 10, 2012 at 1:28 PM, Sami Eljabali seljab...@gmail.com wrote: Because then they wouldn't be HMTL5 compliant vs not having a nifty feature. How would you push this forward being adopted? I'm mostly likely not thinking creatively enough. Why would it be a part of HTML5 if vendors don't want to implement it? Just because something has been proposed to be added to HTML5 doesn't mean it will be supported by all browsers. In fact, if some vendors strongly oppose, then we're going to remove it from the spec. What you need to do first is to convince Microsoft and Apple that this is a valuable feature they want to have instead of trying to circumvent the process. Quite frankly, I would be opposed to adding this feature to WebKit / Chromium as well although I can't speak for my employer or the boarder WebKit or Chromium open source communities. - Ryosuke
Re: [whatwg] Proposal in supporting the writing of Arabizi
On May 10, 2012, at 12:00 PM, Sami Eljabali seljab...@gmail.com wrote: Good luck pushing Apple Microsoft in implementing this. If we create this as a tag then we'd push every OS vendor to support it. Mac OS X supports Arabic, Arabic - PC and Arabic - QWERTY input methods. If none of these provide the functionality of Arabizi then please file a bug at http://bugreport.apple.com/ and we can consider adding it for the whole OS. Mac OS X also supports third-party downloadable input methods. We are unlikely to support a browser-specific form of input methods. Regards, Maciej
Re: [whatwg] Proposal in supporting the writing of Arabizi
Will do! Thanks for the feedback, -Sami On Thu, May 10, 2012 at 1:41 PM, Maciej Stachowiak m...@apple.com wrote: On May 10, 2012, at 12:00 PM, Sami Eljabali seljab...@gmail.com wrote: Good luck pushing Apple Microsoft in implementing this. If we create this as a tag then we'd push every OS vendor to support it. Mac OS X supports Arabic, Arabic - PC and Arabic - QWERTY input methods. If none of these provide the functionality of Arabizi then please file a bug at http://bugreport.apple.com/ and we can consider adding it for the whole OS. Mac OS X also supports third-party downloadable input methods. We are unlikely to support a browser-specific form of input methods. Regards, Maciej
Re: [whatwg] Proposal in supporting the writing of Arabizi
On Thu, 10 May 2012, Sami Eljabali wrote: On Thu, May 10, 2012 at 12:38 PM, Ian Hickson i...@hixie.ch wrote: On Thu, 10 May 2012, Sami Eljabali wrote: I don't understand. Everybody has an operating system. Why would putting things in the operating system limit availability? Operating systems and their GUIs are responsible for almost everything that a browser does, at one level or another. Good luck pushing Apple Microsoft in implementing this. If we create this as a tag then we'd push every OS vendor to support it. Why would Apple and Microsoft be any more likely to think it worth implementing in their browser than in their operating system? Because then they wouldn't be HMTL5 compliant vs not having a nifty feature. How would you push this forward being adopted? I'm mostly likely not thinking creatively enough. Ah, I see the source of confusion. We have no ability in this work to force browser vendors to implement something they don't want to support. So adding it to the spec does nothing if they don't want to implement it. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] source media attribute behavior, static or dynamic ?
Currently implementing the media attribute of the source element in Gecko, we are unsure about what the specification requires us to do there. Considering this example : video source src=lowres.webm media=max-width:500px source src=highres.webm /video what is the expected behavior of a page containing such code being loaded, in a page that is 1000px width, and then being resized to be under 500px? Should the media currently playing change? Is the media attributes and the multiple source attribute only taken into account when the page is loaded? The spec [1] says : Dynamically modifying a source element and its attribute when the element is already inserted in a video or audio element will have no effect. To change what is playing, just use the src attribute on the media element directly, possibly making use of the canPlayType() method to pick from amongst available resources. Generally, manipulating source elements manually after the document has been parsed is an unncessarily complicated approach. which seems to indicate that the source element are only used at load time. Since |canPlayType()| is mentioned, |matchMedia()| is possibly the right approach here, but it is unclear to us what the spec exactly requires. We think the spec needs clarification here. Thanks, Paul.
Re: [whatwg] source media attribute behavior, static or dynamic ?
On Thu, 10 May 2012, Paul Adenot wrote: The spec [1] says : Dynamically modifying a source element and its attribute when the element is already inserted in a video or audio element will have no effect. To change what is playing, just use the src attribute on the media element directly, possibly making use of the canPlayType() method to pick from amongst available resources. Generally, manipulating source elements manually after the document has been parsed is an unncessarily complicated approach. which seems to indicate that the source element are only used at load time. Since |canPlayType()| is mentioned, |matchMedia()| is possibly the right approach here, but it is unclear to us what the spec exactly requires. We think the spec needs clarification here. As far as I can tell, the behaviour here is strictly and unambiguously defined, leaving only one possible interpretation, so it's not clear to me how to make it less ambiguous. Could you elaborate on what interpretations of the spec you think are possible? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] img srcset for responsive bitmapped content images
On Thu, 10 May 2012 16:02:22 +0100, Tab Atkins Jr. jackalm...@gmail.com wrote: I can’t second Scott’s suggestion enough. There is a ton of history and valuable conversation around this topic already in the Community Group, and we’ve been working with a couple of browser reps trying to get this thing solved. We’ve even gone so far as to put the solution that seems to have the most legs together as a sort-of spec, so all the details are in one easily-parsed place: https://github.com/Wilto/respimg The Responsive Images work is intended to solve a different issue than the send high-res versions if you have the screen and bandwidth to do so. It's for serving different images based on various MQ conditions, just baked into HTML markup rather than hacking it in via backgrounds. MQs, though, are a fundamentally unsound method for doing bandwidth-responsive image serving. I gave the basic example of why it fails in an earlier message in this thread. Indeed. I think there's a confusion around this in general, and responsive images mean different things to different people. While the solution that Responsive Images group leans towards is appropriate for solving layout problems, the description of group's goals sounds more like solving optimisation/dpi problems. I think these are orthogonal issues and both of them may be worth solving. I've tried to sort problems/use-cases here: http://www.w3.org/community/respimg/2012/04/16/summary-of-use-cases-and-requirements/ -- regards, Kornel Lesiński
Re: [whatwg] img srcset for responsive bitmapped content images
On Thu, 10 May 2012 21:18:41 +0100, Maciej Stachowiak m...@apple.com wrote: For two, I'm not sure that it's particularly obvious that when you say 2x, you should make sure your image was saved as 196dpi. You have to already know what the default resolution is. As well, I think that values like 300dpi are pretty common, and they don't map to integral 'x' values. If people say screw it and use 3x, this'll be slightly wrong and I think will cause ugly blurring. If we make this take resolution, people can just use the dpi unit. Can we just use CSS's 'dpi' instead? img src=default.jpg srcset=highres.jpg 300dpi CSS's 'dpi' is confusing, because it actually defines the ratio of device pixels to CSS inches, not device pixels to physical inches, as most users would expect 'dpi' to mean in the context of a graphics program. So 300dpi would mean the same thing as 3.125x, and would likely itself result in ugly blurring, since scaling by a fractional scale factor rarely looks crisp. I doubt whether support for non-integer scale factors/arbitrary DPI is going to be useful in practice. While it's relatively easy to resize photos for any DPI, it's not desirable from caching/processing perspective (hosting and serving as many different variants of a file as there are screen densities). A pragmatic solution is to have few sizes and serve a good enough size, which may as well be integer multiplies of a CSS pixel. And when it's important to serve pixel-perfect images for arbitrary DPI, then probably it's equally important to have pixel-perfect CSS as well. Unfortunately, it's very hard to write device-pixel-perfect CSS for non-integer multiplies of a CSS pixel. I don't expect many (if any) authors to actually write `border: 0.6024096386px solid` to achieve this. Most artists won't spend time to prepare dozens of pixel-perfect manually resized versions of icons for varying screen densities, so most of the time assets for resolutions between 1x and maximum will be automatically resized one way or another. Therefore, I expect browsers/systems to continue using fake 96dpi/192dpi snapped to device pixels, and artists to focus only on those ratios. It's simplest for everybody and gives device-pixel-perfect rendering on varying screen densities. -- regards, Kornel Lesiński
Re: [whatwg] source media attribute behavior, static or dynamic ?
As far as I can tell, the behaviour here is strictly and unambiguously defined, leaving only one possible interpretation, so it's not clear to me how to make it less ambiguous. Could you elaborate on what interpretations of the spec you think are possible? We have two possible interpretations, here : 1. If the environment of the user changes, then the source of the video has to change according to the different child source element and their respective media queries. 2. Once a source is loaded, the other source element are never used again, despite the environment changing. If the author wants the source to change, he has to use matchMedia() or canPlayType(), and query the DOM for other available source elements. Support for the first interpretation : Dynamically modifying a source element and its attribute when the element is already inserted in a video or audio element will have no effect. We are never modifying the source elements, we are only relying on the media attribute of those elements. We therefore can't conclude that by having a read-only behavior, the media that is currently playing will not change. Generally, manipulating source elements manually after the document has been parsed is an unncessarily complicated approach. Here, using the media attribute, if we implement the first interpretation, we are not manipulating source elements manually, We are automatically loading a new resource. The main concern here is the fact that the author can think that the media attribute of the source element works in the same way than @media in CSS : it dynamically changes the source automatically according to the user environment. Support for the second interpretation : To change what is playing, just use the src attribute on the media element directly, possibly making use of the canPlayType() method to pick from amongst available resources. The just word here seems to imply modifying the src attribute of the audio or video parent is the only way to change the media that is playing. By deduction, media attributes of children source elements cannot change a the source that is currently playing. Thanks, Paul.
Re: [whatwg] source media attribute behavior, static or dynamic ?
On Thu, 10 May 2012, Paul Adenot wrote: As far as I can tell, the behaviour here is strictly and unambiguously defined, leaving only one possible interpretation, so it's not clear to me how to make it less ambiguous. Could you elaborate on what interpretations of the spec you think are possible? We have two possible interpretations, here : 1. If the environment of the user changes, then the source of the video has to change according to the different child source element and their respective media queries. [...] Support for the first interpretation : Dynamically modifying a source element and its attribute when the element is already inserted in a video or audio element will have no effect. We are never modifying the source elements, we are only relying on the media attribute of those elements. We therefore can't conclude that by having a read-only behavior, the media that is currently playing will not change. The spec says _exactly_ what it means. You do not need to ever read between the lines. Here, the paragraph only says that modifying the attribute has no effect. It doesn't say anything else. It doesn't say that if the environment changes, anything happens. It doesn't say that if the phase of the moon is full, that the video should play backwards. Presumably you haven't interpreted it to suggest that you should play backwards in a full moon. :-) The same applies to anything else. Furthermore, the paragraph you quote above is non-normative. The paragraph doesn't say anything with a must, it doesn't define any terms. It therefore can not in any way affect what an implementation does. Support for the second interpretation : To change what is playing, just use the src attribute on the media element directly, possibly making use of the canPlayType() method to pick from amongst available resources. This paragraph is not normative either. Again, it has no conformance criteria (must) and doesn't define anything. Please, as an implementor, ignore everything that isn't a conformance criteria. The just word here seems to imply modifying the src attribute of the audio or video parent is the only way to change the media that is playing. By deduction, media attributes of children source elements cannot change a the source that is currently playing. If at any time you are finding yourself worrying about what hte spec implies, or deducing anything about what the spec means, stop, you don't ever have to do that. :-) The only place in the spec that is in any way affected by the media attribute on the source element (other than the .media IDL attribute) is step 6, substep 6, of the resource selection algorithm. The only time, therefore, that you should ever be affected by the media= attribute, is when you reach that step in your implementation. There is nothing that causes that to happen when the environment changes. HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal: Add window.getLastError (or modify invocation arguments of window.onerror)
On Thu, 10 May 2012 21:14:23 +0200, James Greene
james.m.gre...@gmail.com wrote:
In my opinion, adding the stack trace to the existing message would be
messy, breaks existing developer expectations, and possibly even breaks
backward compatibility of specific libraries/functions/monitoring/etc. in
some more extreme situations. If we can't just have the Error object
itself passed in, I'd much prefer stack as a fifth parameter versus
unexpected modification of an existing parameter.
Right, stack as a fifth parameter was what I suggested.
We can also keep adding parameters to the window.onerror invocation
till
we're blue in the face...
Or only add parameters that solve use cases being presented...
but, in reality, don't we just want all of the
properties of the relevant Error object?
I don't know, that why I asked what you want.
I'd really love to *just* have
the Error object passed (e.g. window.onerror(function(e) { ... }))
but
I know that would break backward compatibility, so I didn't propose it.
What do you want for compile errors, which don't have an Error object at
all?
It seems to me like columnNumber should be added to the Error object
as
a standard (speaking of which:
https://github.com/JSFixed/JSFixed/issues/51)
*instead of* adding it as yet another parameter to the already ugly
window.onerror, and then just pass the Error object so devs can get
whatever information they want from it.
What about compile error?
But, if it's a security thing, I
guess I'm willing to accept that
The security thing is solvable either way.
--
Simon Pieters
Opera Software
