n.
cheers
Fred
> Date: Thu, 18 Oct 2012 08:31:57 +0200
> From: i...@anselm-hannemann.com
> To: freda...@live.com
> CC: whatwg@lists.whatwg.org; odi...@opera.com
> Subject: Re: [whatwg] Features for responsive Web design
>
> Am Donnerstag, 18. Oktober 2012 um 04:05 schrieb
; > Date: Mon, 15 Oct 2012 18:40:21 +0200
> > From: odi...@opera.com (mailto:odi...@opera.com)
> > Subject: Re: [whatwg] Features for responsive Web design
> >
> > On Thu, 11 Oct 2012 20:07:04 +0200, Markus Ernst > (mailto:derer...@gmx.ch)> wrote:
> >
>
ize is far more important than image quality a single
image
would suffice anyway.
cheers
Fred
> To: whatwg@lists.whatwg.org
> Date: Mon, 15 Oct 2012 18:40:21 +0200
> From: odi...@opera.com
> Subject: Re: [whatwg] Features for responsive Web design
>
> On Thu, 11 Oct 2012 20:07:0
On Thu, 11 Oct 2012 20:07:04 +0200, Markus Ernst wrote:
This is why I'd humbly suggest to put information on the image in
@srcset rather than info on the device and media. Such as:
srcset="low.jpg 200w, hi.jpg 400w, huge.jpg 800w"
What about an image gallery, when you have 25 thumbnails on
On Sat, 2012-10-13 at 06:04 +, Fred Andrews wrote:
>
> > From: m...@apple.com
> ...
> > > My point is, that any device-specific notation, such as "2x", forces the
> > > author to make decisions that the browser should actually make. The
> > > author does not know if in a few years the image
> From: m...@apple.com
...
> > My point is, that any device-specific notation, such as "2x", forces the
> > author to make decisions that the browser should actually make. The author
> > does not know if in a few years the image will be viewed with 1.5x or 3x or
> > 7x or whatever devices.
> >
On Oct 11, 2012, at 11:07 AM, Markus Ernst wrote:
> Am 11.10.2012 18:36 schrieb Ian Hickson:
>> On Thu, 11 Oct 2012, Markus Ernst wrote:
>>>
>>> IMHO as an author, the "bandwidth" use case is not solved in a future
>>> proof manner
>>
>> It's not solved at all. I didn't attempt to solve it. Be
Am 11.10.2012 18:36 schrieb Ian Hickson:
On Thu, 11 Oct 2012, Markus Ernst wrote:
IMHO as an author, the "bandwidth" use case is not solved in a future
proof manner
It's not solved at all. I didn't attempt to solve it. Before we can solve
it, we need to figure out how to do so, as discussed h
On Oct 11, 2012, at 1:10 PM, Ian Hickson wrote:
> On Thu, 11 Oct 2012, Mathew Marquis wrote:
>> On Oct 11, 2012, at 12:36 PM, Ian Hickson wrote:
>>> On Thu, 11 Oct 2012, Markus Ernst wrote:
IMHO as an author, the "bandwidth" use case is not solved in a future
proof manner
>>>
>
On Thu, 11 Oct 2012, Mathew Marquis wrote:
> On Oct 11, 2012, at 12:36 PM, Ian Hickson wrote:
> > On Thu, 11 Oct 2012, Markus Ernst wrote:
> >>
> >> IMHO as an author, the "bandwidth" use case is not solved in a future
> >> proof manner
> >
> > It's not solved at all. I didn't attempt to solve
On Oct 11, 2012, at 12:36 PM, Ian Hickson wrote:
> On Thu, 11 Oct 2012, Markus Ernst wrote:
>>
>> IMHO as an author, the "bandwidth" use case is not solved in a future
>> proof manner
>
> It's not solved at all. I didn't attempt to solve it. Before we can solve
> it, we need to figure out how
On Thu, 11 Oct 2012, Markus Ernst wrote:
>
> IMHO as an author, the "bandwidth" use case is not solved in a future
> proof manner
It's not solved at all. I didn't attempt to solve it. Before we can solve
it, we need to figure out how to do so, as discussed here (search for
"bandwidth one"):
On Thu, 11 Oct 2012, Mark Callow wrote:
> On 2012/10/10 12:29, Ian Hickson wrote:
> > On Wed, 10 Oct 2012, Mark Callow wrote:
> >> I don't know what the browser on the SH-10D is doing, (It's running
> >> Android 4.0) but, given the physical size (4.5"), if they were making
> >> the css pixels sma
Am 10.10.2012 20:36 schrieb Ian Hickson:
On Wed, 10 Oct 2012, Tim Kadlec wrote:
That's actually exactly why it's better _not_ to plan for it. We can't
design features for problems we don't understand. It's better to wait
until we have real problems before fixing them.
You may not be able to p
On 2012/10/10 12:29, Ian Hickson wrote:
> On Wed, 10 Oct 2012, Mark Callow wrote:
>> I don't know what the browser on the SH-10D is doing, (It's running
>> Android 4.0) but, given the physical size (4.5"), if they were making
>> the css pixels smaller, the content would be unreadable. I expect th
On Oct 10, 2012, at 1:14 AM, Maciej Stachowiak wrote:
>
> On Oct 9, 2012, at 2:49 PM, Tab Atkins Jr. wrote:
>
>> On Tue, Oct 9, 2012 at 11:48 AM, Ian Hickson wrote:
>>> On Tue, 9 Oct 2012, Mark Callow wrote:
On 2012/10/06 7:09, Ian Hickson wrote:
> I agree, when there's 3x displays,
On Wed, 10 Oct 2012, Tim Kadlec wrote:
> >
> > That's actually exactly why it's better _not_ to plan for it. We can't
> > design features for problems we don't understand. It's better to wait
> > until we have real problems before fixing them.
>
> You may not be able to predict every future prob
> That's actually exactly why it's better _not_ to plan for it. We can't
> design features for problems we don't understand. It's better to wait
> until we have real problems before fixing them.
You may not be able to predict every future problem, but surely you need to
keep it in mind as you crea
On Wed, 10 Oct 2012, Mathew Marquis wrote:
>
> In fairness, no, we can’t predict the future one way or the other.
> That’s exactly why it’s better to plan for it than not.
That's actually exactly why it's better _not_ to plan for it. We can't
design features for problems we don't understand. It
On Oct 10, 2012, at 4:14 AM, Maciej Stachowiak wrote:
>
> On Oct 9, 2012, at 2:49 PM, Tab Atkins Jr. wrote:
>
>> On Tue, Oct 9, 2012 at 11:48 AM, Ian Hickson wrote:
>>> On Tue, 9 Oct 2012, Mark Callow wrote:
On 2012/10/06 7:09, Ian Hickson wrote:
> I agree, when there's 3x displays,
On Oct 9, 2012, at 2:49 PM, Tab Atkins Jr. wrote:
> On Tue, Oct 9, 2012 at 11:48 AM, Ian Hickson wrote:
>> On Tue, 9 Oct 2012, Mark Callow wrote:
>>> On 2012/10/06 7:09, Ian Hickson wrote:
I agree, when there's 3x displays, this could get to the point where we
need to solve it. :-)
>>
On Wed, 10 Oct 2012, Mark Callow wrote:
>
> I don't know what the browser on the SH-10D is doing, (It's running
> Android 4.0) but, given the physical size (4.5"), if they were making
> the css pixels smaller, the content would be unreadable. I expect they
> are actually using 3x.
Can you obtai
On 2012/10/10 6:49, Tab Atkins Jr. wrote:
> On Tue, Oct 9, 2012 at 11:48 AM, Ian Hickson wrote:
>> On Tue, 9 Oct 2012, Mark Callow wrote:
>>> On 2012/10/06 7:09, Ian Hickson wrote:
I agree, when there's 3x displays, this could get to the point where we
need to solve it. :-)
>>> With the
On Tue, Oct 9, 2012 at 11:48 AM, Ian Hickson wrote:
> On Tue, 9 Oct 2012, Mark Callow wrote:
>> On 2012/10/06 7:09, Ian Hickson wrote:
>> > I agree, when there's 3x displays, this could get to the point where we
>> > need to solve it. :-)
>>
>> With the current displays, it's just not that big a d
On Tue, 9 Oct 2012, Mark Callow wrote:
> On 2012/10/06 7:09, Ian Hickson wrote:
> > I agree, when there's 3x displays, this could get to the point where we
> > need to solve it. :-)
>
> With the current displays, it's just not that big a deal, IMHO. If by 3x
> you mean displays whose dpi is 3x th
On 2012/10/06 7:09, Ian Hickson wrote:
> I agree, when there's 3x displays, this could get to the point where we
> need to solve it. :-)
>
> With the current displays, it's just not that big a deal, IMHO.
If by 3x you mean displays whose dpi is 3x that of CSS pixels (96dpi),
they already exist in
On Oct 5, 2012, at 6:09 PM, Ian Hickson wrote:
>
> Some of the e-mails on this thread were cross-posted to multiple mailing
> lists. Please remember not to cross-post when posting to this list.
>
> On Wed, 5 Sep 2012, Fred Andrews wrote:
I have always been comfortable with the 'x' p
Some of the e-mails on this thread were cross-posted to multiple mailing
lists. Please remember not to cross-post when posting to this list.
On Wed, 5 Sep 2012, Fred Andrews wrote:
> > >
> > > I have always been comfortable with the 'x' part of srcset, but the
> > > w and h part felt somewhat
On Thu, Sep 6, 2012 at 3:45 AM, David Singer wrote:
>
> On Sep 4, 2012, at 12:47 , Ian Hickson wrote:
>
>> On Thu, 7 Jun 2012, Mark Callow wrote:
>>>
>>> IIRC Kodak's PhotoCD image format had this characteristic. The first
>>> part is a low res. image, the second is the differences between the lo
> From: smyl...@stripey.com
...
> > > > > > > set="image-320x200.jpg 320 200 10k, image-640x400.jpg 640 400 40k,
> > > > image-1280x800.jpg 1280 800 150k">
> > >
> > > The layout size of that element is not computable until all
> > > external stylesheets have loaded, as you have written
Fred Andrews writes:
> From: m...@apple.com
>
> > > > > set="image-320x200.jpg 320 200 10k, image-640x400.jpg 640 400 40k,
> > > image-1280x800.jpg 1280 800 150k">
> >
> > The layout size of that element is not computable until all
> > external stylesheets have loaded, as you have written it.
> From: m...@apple.com
...
> >>> I have always been comfortable with the 'x' part of srcset, but the w
> >>> and h part felt somewhat wrong to me. What you'd really want to consider
> >>> when deciding which image to pick isn't the size of the viewport itself,
> >>> but the size available for th
On Sep 5, 2012, at 12:07 AM, Fred Andrews wrote:
> ...
>
>>> I have always been comfortable with the 'x' part of srcset, but the w
>>> and h part felt somewhat wrong to me. What you'd really want to consider
>>> when deciding which image to pick isn't the size of the viewport itself,
>>> but
On Sep 6, 2012, at 7:26 AM, Simon Pieters wrote:
> On Wed, 05 Sep 2012 19:45:41 +0200, Mathew Marquis
> wrote:
>
>> I can say for my own part: manipulating strings is far more difficult than
>> manipulating the value of individual attributes. It’s hard to imagine a
>> situation where I’d pre
On Wed, 05 Sep 2012 19:45:41 +0200, Mathew Marquis
wrote:
I can say for my own part: manipulating strings is far more difficult
than manipulating the value of individual attributes. It’s hard to
imagine a situation where I’d prefer to muck through a space/comma
separated string rather th
On Wed, Sep 5, 2012 at 7:49 PM, Nils Dagsson Moskopp <
n...@dieweltistgarnichtso.net> wrote:
> Often, solutions that can be considered “simple” for emitters of data
> externalize costs, burdening consumers – especially when “simple”
> prevents using off-the-shelf components like XML parsers (if a
Glenn Maynard schrieb am Wed, 5 Sep 2012 19:01:19
-0500:
> […]
>
> On Wed, Sep 5, 2012 at 6:01 PM, Nils Dagsson Moskopp <
> n...@dieweltistgarnichtso.net> wrote:
>
> > Still, this would mean that existing DOM-like node-based data
> > structures could not be used easily – even if filled through
On Sep 4, 2012, at 12:47 , Ian Hickson wrote:
> On Thu, 7 Jun 2012, Mark Callow wrote:
>>
>> IIRC Kodak's PhotoCD image format had this characteristic. The first
>> part is a low res. image, the second is the differences between the low
>> res. image zoomed to the high res. size and the actua
On Wed, Sep 5, 2012 at 12:45 PM, Mathew Marquis wrote:
> I’m not sure how exactly to prove to you that developers find the extended
> syntax unintuitive apart from continuing to point out the things that
> developers themselves have said on the topic, and I’m still not certain how
> the way it “f
On Wed, Sep 5, 2012 at 7:01 PM, Nils Dagsson Moskopp
wrote:
> Aaron Gustafson schrieb am Wed, 5 Sep 2012
> 18:42:37 -0400:
>
>> […]
>>
>> Might I propose an option 3 (which is in no way a vote of support for
>> Hixies suggested srcset, I like the proposed video-like syntax far
>> more):
>>
>> [{
Aaron Gustafson schrieb am Wed, 5 Sep 2012
18:42:37 -0400:
> […]
>
> Might I propose an option 3 (which is in no way a vote of support for
> Hixies suggested srcset, I like the proposed video-like syntax far
> more):
>
> [{ image: 'img2.jpg', density: '2x', query: '300w' }, { image:
> 'img3.jpg'
Mathew Marquis schrieb am Wed, 5 Sep 2012 13:45:41
-0400:
> […]
> I’m not sure how exactly to prove to you that developers find the
> extended syntax unintuitive apart from continuing to point out the
> things that developers themselves have said on the topic, and I’m
> still not certain how the
On Wed, Sep 5, 2012 at 1:45 PM, Mathew Marquis wrote:
> I can say for my own part: manipulating strings is far more difficult than
> manipulating the value of individual attributes. It’s hard to imagine a
> situation where I’d prefer to muck through a space/comma separated string
> rather than a
On Mon, 27 Aug 2012 12:05:00 +0100, Chaals McCathieNevile
wrote:
While it's unlikely that screen resolution will go above 2x in the near
future, should we be taking into account the zooming of specific
elements that might result in the need for larger artwork? (take icons,
that can scale
>> Whether it's easier for script is hard for me to say, because I don't
>> really understand what scripts are going to be doing here. Can you
>> elaborate? What will scripts need to do here?
>>
>> Manipulating from script would be a huge pain -- you'd have to
>> be manipulating lots of eleme
On Sep 4, 2012, at 3:47 PM, Ian Hickson wrote:
>>
>> [...]
>>
>>> On Thu, 24 May 2012, Florian Rivoal wrote:
>>>
>>> I don't understand why this is better than:
>>>
>>>>> alt="...">
>>>
>>> ...which as far as I can tell does exactly th
Ian Hickson schrieb am Tue, 4 Sep 2012 19:47:38 +
(UTC):
(regarding )
> I don't understand why it's more intuitive and easier. It seems way
> more unwieldly.
Personally, I consider with to be very similar to
using ATOM s in podcasting. The relation – there are several
sub-resources that r
...
> > I have always been comfortable with the 'x' part of srcset, but the w
> > and h part felt somewhat wrong to me. What you'd really want to consider
> > when deciding which image to pick isn't the size of the viewport itself,
> > but the size available for the image once the rest of the l
On Thu, 7 Jun 2012, Mark Callow wrote:
> On 06/06/2012 21:36, Henri Sivonen wrote:
> > More to the point, the important characteristic is being able to stop
> > downloading *quarter* way through the file and get results that are as
> > good as if the full-size file had been down sampled with both
On Tue, 21 Aug 2012 22:36:15 +0200, Steve Dennis wrote:
While it's unlikely that screen resolution will go above 2x in the near
future, should we be taking into account the zooming of specific
elements that might result in the need for larger artwork? (take icons,
that can scale all the wa
While it's unlikely that screen resolution will go above 2x in the near future,
should we be taking into account the zooming of specific elements that might
result in the need for larger artwork? (take icons, that can scale all the way
up to 512px or above)
On 13/08/2012, at 5:39 PM, Henri Sivo
On Aug 7, 2012, at 3:09 PM, Ian Hickson wrote:
> On Tue, 15 May 2012, Matthew Wilcox wrote:
>>
>> I do not see much potential for srcset. The result of asking the author
>> community was overwhelmingly negative, indirection or no indirection.
>
> I'm happy to consider specific feedback, but at
On Mon, Aug 13, 2012 at 6:39 PM, Henri Sivonen wrote:
> If it indeed is the case that there are really only two realistic
> bitmaps samplings for catering to differences in weeding device pixel
> density (ignoring art direction), it would make sense to have simply
> instead of an in-attribute mic
Am 13.08.2012 18:39 schrieb Henri Sivonen:
Ignoring implementation issues for a moment, I think it would be
conceptually easier it to disentangle these axes like this:
Non-art directed:
Art directed:
I like this hisrc approach for its simplicity; it depends on the
question whether a li
On Fri, Aug 10, 2012 at 11:54 AM, Florian Rivoal wrote:
> I wasn't debating whether or not shipping a device with a 1.5 pixel
> ratio is the best decision, but answering: "Is there a good reason
> to believe that will be something other than a power of two?"
>
> The fact that it has happened seems
Am 10.08.2012 12:06 schrieb Odin Hørthe Omdal:
On Thu, 09 Aug 2012 18:54:10 +0200, Kornel Lesiński
wrote:
One stylesheet can be easily reused for pixel-perfect 1x/2x layout,
but pixel-perfect 1.5x requires its own sizes incompatible with 1x/2x.
Apart from it possibly being a self-fulfillin
On 9 August 2012 17:01, Tab Atkins Jr. wrote:
> On Thu, Aug 9, 2012 at 1:16 AM, Andy Davies wrote:
>> Would also like to see if there's a way of using srcset to hint to the UA
>> that it can skip the image under low throughput conditions e.g. GPRS.
>> Same would apply to image-set in CSS
>
> The
On Thu, 09 Aug 2012 18:54:10 +0200, Kornel Lesiński
wrote:
One stylesheet can be easily reused for pixel-perfect 1x/2x layout,
but pixel-perfect 1.5x requires its own sizes incompatible with 1x/2x.
Apart from it possibly being a self-fulfilling prophecy – isn't this
too much premature “
On 10 Aug 2012, at 09:54, Florian Rivoal wrote:
> On Thu, 09 Aug 2012 11:29:17 +0200, Kornel Lesiński
> wrote:
>> On 8 sie 2012, at 12:57, "Florian Rivoal" wrote:
> Is there a good reason to believe that * will be something other than a
> power of two?
>
> I wasn't debating whether
On Thu, 09 Aug 2012 11:29:17 +0200, Kornel Lesiński
wrote:
On 8 sie 2012, at 12:57, "Florian Rivoal" wrote:
Is there a good reason to believe that * will be something other than
a
power of two?
That is, could we just optimize the *x syntax away and specify that
the
first option is 1x
On 9 sie 2012, at 11:06, Nils Dagsson Moskopp
wrote:
>> I don't think anybody will take advantage of that. IMHO non-integer
>> ratios are a mistake that can/will be corrected.
>
> Limiting to powers of two because it can/will be “simpler” in this case
> not only makes the attribute harder to r
On Thu, Aug 9, 2012 at 1:16 AM, Andy Davies wrote:
> Would also like to see if there's a way of using srcset to hint to the UA
> that it can skip the image under low throughput conditions e.g. GPRS.
> Same would apply to image-set in CSS
The image-set() function already includes this functionalit
Kornel Lesi__ski schrieb am Thu, 9 Aug 2012
10:29:17 +0100:
> On 8 sie 2012, at 12:57, "Florian Rivoal" wrote:
>
> > […]
> >
> > If you look at mobile phones, there are a bunch of existing devices
> > with 1.5 device pixel per css pixel, and also some with 2.25, so I
> > don't think we can assu
On 8 sie 2012, at 12:57, "Florian Rivoal" wrote:
>>> Is there a good reason to believe that * will be something other than a
>>> power of two?
>>>
>>> That is, could we just optimize the *x syntax away and specify that the
>>> first option is 1x, the second is 2x, the third is 4x, etc.?
>
> If
On 8 August 2012 17:44, Edward O'Connor wrote:
> Hi Markus,
>
> You wrote:
>
>> Anyway, with your proposal, would this be valid, to address the
>> bandwidth-only use case?:
>>
>>
>
> You don't need the ", normal.jpg 1x" because src="" has an implied 1x.
> The above could simply be done like so:
>
Hi Markus,
You wrote:
> Anyway, with your proposal, would this be valid, to address the
> bandwidth-only use case?:
>
>
You don't need the ", normal.jpg 1x" because src="" has an implied 1x.
The above could simply be done like so:
Ted
On Wed, 6 Jun 2012, Henri Sivonen wrote:
Is there a good reason to believe that * will be something other than a
power of two?
That is, could we just optimize the *x syntax away and specify that the
first option is 1x, the second is 2x, the third is 4x, etc.?
If you look at mobile phones, the
On 08/08/2012 12:27 PM, Markus Ernst wrote:
It is better because art direction and bandwidth use cases can be solved
differently in an appropriate manner:
- For the bandwidth use case, no MQ is needed, but only some information
on the sources available to let the UA decide which source to load.
Am 07.08.2012 21:09 schrieb Ian Hickson:
On Tue, 22 May 2012, Markus Ernst wrote:
Am 18.05.2012 23:19 schrieb Kornel Lesiński:
If you'd like to see proposal succeed, then please help
fixing its drawbacks. Make selection and embedding of 2x images
easier. Give UA freedom to use cached higher-q
Sorry, I forgot to clarify this ― I had in mind adding width/height on each
element, not on .
--
regards, Kornel
On 22 maj 2012, at 16:01, Maciej Stachowiak wrote:
>
> On May 21, 2012, at 9:37 PM, Kornel Lesi��ski wrote:
>
>>
>>
>>> There’s no prior precedent this sort of thing―there’s
On May 21, 2012, at 9:37 PM, Kornel Lesiński wrote:
>
>
>> There’s no prior precedent this sort of thing—there’s no reason we can’t
>> find a way to preserve an image’s intrinsic width using `picture`. I wonder
>> if simply adding `width` and `height` attributes on the element (similar to
>
Am 18.05.2012 23:19 schrieb Kornel Lesiński:
If you'd like to see proposal succeed, then please help fixing
its drawbacks. Make selection and embedding of 2x images easier. Give UA
freedom to use cached higher-quality images when it can. Give UA freedom
to choose images to minimize bandwidth or
On Mon, 21 May 2012 19:36:22 -0500, Mathew Marquis
wrote:
in its current form is unable to support bandwidth-based
negotiation well (and that's not simply a matter of adding bandwidth
media query) and has no mechanism to specify scaling factor for
intrinsic sizes of images.
Is there c
On May 18, 2012, at 5:19 PM, Kornel Lesiński wrote:
> On Fri, 18 May 2012 20:24:00 +0100, André Luís wrote:
>
>>> Make no mistake; this is not a pride or attachment thing, this is a
>>> knowing the reasons thing. I personally don't think answers
>>> things well enough, nor do I think srcset do
On Sat, May 19, 2012 at 2:46 AM, Matthew Wilcox wrote:
> On 19 May 2012 00:37, Kornel Lesiński wrote:
>> On Fri, 18 May 2012 23:11:45 +0100, Matthew Wilcox
>> wrote:
in its current form is unable to support bandwidth-based
negotiation well
>>>
>>> By all accounts no solution proposed
On 18 May 2012 22:19, Kornel Lesiński wrote:
> On Fri, 18 May 2012 20:24:00 +0100, André Luís
> wrote:
>
> If you'd like to see proposal succeed, then please help fixing its
> drawbacks. Make selection and embedding of 2x images easier. Give UA freedom
> to use cached higher-quality images when
On 19 maj 2012, at 10:46, Matthew Wilcox wrote:
> On 19 May 2012 00:37, Kornel Lesi��ski wrote:
>> On Fri, 18 May 2012 23:11:45 +0100, Matthew Wilcox
>> wrote:
>>
in its current form is unable to support bandwidth-based
negotiation well
>>>
>>>
>>> By all accounts no solution prop
On 19 May 2012 00:37, Kornel Lesiński wrote:
> On Fri, 18 May 2012 23:11:45 +0100, Matthew Wilcox
> wrote:
>
>>> in its current form is unable to support bandwidth-based
>>> negotiation well
>>
>>
>> By all accounts no solution proposed can do this. This is not a
>> only problem.
>
> srcset all
On Fri, 18 May 2012 23:11:45 +0100, Matthew Wilcox
wrote:
in its current form is unable to support bandwidth-based
negotiation well
By all accounts no solution proposed can do this. This is not a
only problem.
srcset allows UA to pick any image density regardless of actual screen
dens
>>> Make no mistake; this is not a pride or attachment thing, this is a
>>> knowing the reasons thing. I personally don't think answers
>>> things well enough, nor do I think srcset does. Not for general use
>>> cases - but for specific one-off use cases, each has benefits.
>>
>>
>> Absolutely. An
On Fri, 18 May 2012 20:24:00 +0100, André Luís
wrote:
Make no mistake; this is not a pride or attachment thing, this is a
knowing the reasons thing. I personally don't think answers
things well enough, nor do I think srcset does. Not for general use
cases - but for specific one-off use cases
On 18 May 2012 17:29, Matthew Wilcox wrote:
> You have to understand that the idea was not the result of
> idle thought. We went through a *lot* of thinking to reach that point,
> and so it's not actually an attachement to that idea so much as *we
> know* that idea inside out, what it does, what
On Fri, May 18, 2012 at 1:54 PM, Benjamin Hawkes-Lewis <
bhawkesle...@googlemail.com> wrote:
> On Fri, May 18, 2012 at 2:53 PM, Boris Zbarsky wrote:
> > On 5/18/12 3:16 AM, Markus Ernst wrote:
> >>
> >> 1. Are there other cases in HTML where an attribute value contains more
> >> than one URI?
> >
On Fri, May 18, 2012 at 2:53 PM, Boris Zbarsky wrote:
> On 5/18/12 3:16 AM, Markus Ernst wrote:
>>
>> 1. Are there other cases in HTML where an attribute value contains more
>> than one URI?
>
>
> * The "archive" attribute of (comma-separated list of URIs)
>
> * The "ping" attribute of (space-se
You have to understand that the idea was not the result of
idle thought. We went through a *lot* of thinking to reach that point,
and so it's not actually an attachement to that idea so much as *we
know* that idea inside out, what it does, what it doesn't, and why
it's like that. We had thought ab
On 18 May 2012 15:28, Glenn Maynard wrote:
>
> Only if there are actual problems solved by doing so, which there don't
> seem to be. Instead, people seem to be hunting for excuses to use parts of
> the other proposal just for the sake of using them, not to solve any actual
> problem. ("That's no
On Fri, May 18, 2012 at 5:51 AM, Julian Reschke wrote:
> ...which of course means that it stops being "simpler".
>
No, it means nothing of the sort. An API to access this would introduce
none of the problems with the multi-element approach; it would be simple
and straightforward to do.
I think
On 5/18/12 3:16 AM, Markus Ernst wrote:
1. Are there other cases in HTML where an attribute value contains more
than one URI?
* The "archive" attribute of (comma-separated list of URIs)
* The "ping" attribute of (space-separated list of URIs)
* The "style" attribute (which can, e.g., set bo
Am 18.05.2012 13:09 schrieb James Graham:
On 05/18/2012 12:16 PM, Markus Ernst wrote:
2. Have there been thoughts on the scriptability of @srcset? While
sources can be added to resp. removed from easily with
standard DOM methods, it looks to me like this would require complex
string operations
On 05/18/2012 12:16 PM, Markus Ernst wrote:
2. Have there been thoughts on the scriptability of @srcset? While
sources can be added to resp. removed from easily with
standard DOM methods, it looks to me like this would require complex
string operations for @srcset.
Are there any use cases tha
On 2012-05-18 12:30, Maciej Stachowiak wrote:
On May 18, 2012, at 3:16 AM, Markus Ernst wrote:
Am 15.05.2012 09:28 schrieb Ian Hickson:
Re-reading most parts of the last day's discussions, 2 questions come to my
mind that I have the impression have not been pointed out very clearly s
On May 18, 2012, at 3:16 AM, Markus Ernst wrote:
> Am 15.05.2012 09:28 schrieb Ian Hickson:
>>> srcset="face-600-...@1.jpeg 600w 200h 1x,
>> face-600-...@2.jpeg 600w 200h 2x,
>> face-icon.png 200w 200h">
>
> Re-reading most parts of the last day
Am 15.05.2012 09:28 schrieb Ian Hickson:
Re-reading most parts of the last day's discussions, 2 questions come to
my mind that I have the impression have not been pointed out very
clearly so far:
1. Are there other cases in HTML where an attribute value contains more
than one URI?
2
On Thu, May 17, 2012 at 7:54 PM, Kornel Lesiński wrote:
> On Thu, 17 May 2012 02:29:11 +0100, Jacob Mather
> wrote:
>
>> As I said, I understand that it is a hard problem, but the question
>> is, is it the correct problem.
>>
>> There are plenty of reasons not to do it, but is there any actual
>>
On Thu, May 17, 2012 at 3:26 PM, Maciej Stachowiak wrote:
>
> On May 16, 2012, at 9:39 PM, Silvia Pfeiffer
> wrote:
>
>> On Wed, May 16, 2012 at 10:55 PM, Matthew Wilcox
>> wrote:
>>> Chalk me up as another making that mistake. Properties on elements
>>> usually describe a property of the elem
On Thu, 17 May 2012 02:29:11 +0100, Jacob Mather
wrote:
As I said, I understand that it is a hard problem, but the question
is, is it the correct problem.
There are plenty of reasons not to do it, but is there any actual
reason that the approach is less correct than the current proposals?
On May 16, 2012, at 9:39 PM, Silvia Pfeiffer wrote:
> On Wed, May 16, 2012 at 10:55 PM, Matthew Wilcox
> wrote:
>> Chalk me up as another making that mistake. Properties on elements
>> usually describe a property of the element. Not a property of
>> something else (like the viewport).
>
> If
On Wed, May 16, 2012 at 10:55 PM, Matthew Wilcox wrote:
> Chalk me up as another making that mistake. Properties on elements
> usually describe a property of the element. Not a property of
> something else (like the viewport).
If it does indeed rely on a rendering issue (like the size of the
view
On Wed, May 16, 2012 at 5:22 PM, Kornel Lesiński wrote:
> On Wed, 16 May 2012 20:12:19 +0100, Jacob Mather
> wrote:
>
>> Maybe this is the better question:
>>
>> Why does the pre-loader matter so much?
>>
>> Basing the selected image off of browser width is inherently
>> backwards. The content sh
On Wed, 16 May 2012 20:12:19 +0100, Jacob Mather
wrote:
Maybe this is the better question:
Why does the pre-loader matter so much?
Basing the selected image off of browser width is inherently
backwards. The content should be informed by the layout, not by the
browser.
Browsers want to dow
1 - 100 of 145 matches
Mail list logo
