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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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 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
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.
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
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
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
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
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
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
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
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?
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
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
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
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
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
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
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
32 matches
Mail list logo
