date:20120517

On Thu, May 17, 2012 at 12:12 PM, Maciej Stachowiak  wrote:
> CGs actually have very little patent obligation compared to W3C Working 
> Groups, so Apple has lighter weight approval for those than for WGs. Perhaps 
> Google could consider the same thing. I believe the CG rules would not allow 
> an employee of a W3C Member company to be a "free agent" though.

I can't speak for our lawyers, but I do plan to complain about the
situation internally.  It adds a pretty tremendous mental transaction
cost to me joining a CG, and that's unfortunate.

~TJ

Re: [whatwg] Problems with width/height descriptors in srcset

On Thu, May 17, 2012 at 11:42 AM, Kornel Lesiński  wrote:
> On Thu, 17 May 2012 19:15:36 +0100, Matthew Wilcox 
> wrote:
>
>> I also agree with Tab and Jeremy on this one - that makes a lot more
>> sense to me and removes any ambiguity without being overly verbose.
>
>
> I like the less-compressed, more CSSy syntax as well.
>
> I have two concerns though:
>
> Is any media query allowed?
> If so, then use of "min-device-pixel-ratio:2x" would give inferior results
> to using the "2x" multiplier, because 2x allows UA to choose when the 2x
> image is selected (taking into account bandwidth, zoom, user preference,
> etc.), but min-device-pixel-ratio is supposed to query a fact about the
> device, not a preference. Should that be discouraged, or maybe even
> special-cased as an alias of "2x" descriptor?

These aren't *really* media queries, they just act a whole lot like
them.  (They can be ignored if needed.)

So no, we should just have a specific set of things that are allowed.

> How do scaling factors and size queries interact?
>
> When only scaling factors are specified then selection is easy, and images
> could be described in any order:
>
> 
> 
>
>
> If "first one that matches" rule was applied to density descriptors, then
> this would surprisingly fail:
> 
>
> because a 2x screen can display 1x image (or the opposite case would fail
> depending how you define matching of density).

The spec makes this clear - after filtering the list based on
width/height descriptors, the UA can choose whatever density it wants,
based on whatever algorithm it wants.  Ordering makes no difference.

(Ordering makes no difference in width/height either, for that matter.)

> As soon as sizes are specified, taking into account order of the rules
> becomes unavoidable:
>
> 
>
> on a screen that is larger than 100x100 both would match, so there needs to
> be some definition which one wins, e.g. the first one that matches.

The spec has such a definition.  I can't recall what it is off the top
of my head.

~TJ

[whatwg] Data store readability in drag/dragend

2012-05-17 Thread Daniel Cheng

Can we make the drag data store available in read only mode in drag or
dragend? Presumably they are getting fired at the source element that
originally set the data in dragstart, so it's not a security issue.
http://www.onemanmmo.com/index.php?cmd=newsitem&comment=news.1.83.0 is one
person's attempt to work around the current limitations of the system.

Daniel

Re: [whatwg] Defaulting new image solution to 192dpi

2012-05-17 Thread Maciej Stachowiak


On May 17, 2012, at 12:20 PM, Kornel Lesiński  wrote:

> On Thu, 17 May 2012 19:32:51 +0100, Jeremy Keith  wrote:
> 
>> Kornel wrote:
>>> Note that the scale multiplier can be omitted already when only the size is 
>>> specified
>> 
>> I'm confused by what you mean by scale multiplier. The x value describes the 
>> pixel density of the device/screen, not the image, right?
> 
> I think it only makes sense if it describes the image, so that:
> 
> 
> 
> would display at 50x50px (CSS px).

That is indeed how it works.

Cheers,
Maciej

Re: [whatwg] Defaulting new image solution to 192dpi

On Thu, May 17, 2012 at 11:32 AM, Jeremy Keith  wrote:
> Kornel wrote:
>> Note that the scale multiplier can be omitted already when only the size is 
>> specified
>
> I'm confused by what you mean by scale multiplier. The x value describes the 
> pixel density of the device/screen, not the image, right?

You can think of it either way in this case.  Devices with a pixel
density less than the Nx descriptor of an image won't download that
image if they have a choice (unless you're zooming or something, where
the effective pixel density is higher).

However, the Nx descriptor does have an effect on the image, by
adjusting the intrinsic size of the image.  If the image is 600 pixels
(image pixels) wide and sent with a 2x descriptor, its intrinsic size
will be 300px (CSS px).  You'll only notice this if you're using
auto-sizing, though.

~TJ

Re: [whatwg] Defaulting new image solution to 192dpi

On Thu, 17 May 2012 19:32:51 +0100, Jeremy Keith   
wrote:



Kornel wrote:
Note that the scale multiplier can be omitted already when only the  
size is specified


I'm confused by what you mean by scale multiplier. The x value describes  
the pixel density of the device/screen, not the image, right?


I think it only makes sense if it describes the image, so that:



would display at 50x50px (CSS px).

Of course the UA is likely to match 2x with double-density displays, so it  
acts as both description of the image and a "hint" media query.



If it were purely a media query unrelated to the image, then this:



would only select between pixelated large image and pixelated small image,  
never making use of a high DPI display.



The goal is to avoid having to specify explicit . Not  
only it's tedious and annoying, it also makes it impossible to adapt  
images to viewport and screen density at the same time:



desktop-1000imgpx.jpg 2x, desktop-500imgpx.jpg 1x">


In the case above I'd want to have phone* images on <=320px viewport,  
matching display density, and desktop* images on larger viewports, taking  
full advantage of display density as well (i.e. "desktop-1000imgpx.jpg 2x"  
displayed at 500px).


There is no value of  that can work for that case  
without ruining the adaptation  would work for desktop, but  
ruin phone versions.


So the only way to use srcset in that case would require additional media  
queries that react to same breakpoints as srcset and set explicit pixel  
sizes of this image for each breakpoint. Awful.


So for me the only logical conclusion is that images with "2x" descriptor  
must have their intrinsic size halved (2 img pixels to 1 css pixel).  
That's what iOS does when you use @2x images in Cocoa.


--
regards, Kornel Lesiński

Re: [whatwg] Correcting some misconceptions about Responsive Images

2012-05-17 Thread Maciej Stachowiak


On May 17, 2012, at 11:20 AM, Matthew Wilcox  wrote:

> On 17 May 2012 19:15, Tab Atkins Jr.  wrote:
>> On Thu, May 17, 2012 at 11:12 AM, Matthew Wilcox  
>> wrote:
 A few humble thoughts
 
 -Have the CG recruit an experienced implementor or editor to
 participate more or less from the beginning. This may short-circuit
 time spent on solutions that won't work for esoteric reasons, and
 there will be at least one person with one foot in both worlds.
>>> 
>>> This would be awesome.
>> 
>> FWIW, I wanted to do this, but Google's policy of having us talk to
>> the patents guys before joining CGs turned me off from actually
>> joining.  So, I just followed from the side and couldn't interact
>> enough. :/
> 
> Is this something that Google might be willing to bend somewhat? I.e.,
> when you're on the CG you're a free-agent and not representing Google?
> Or, for the sake of politics, could it be worked around in that
> instead of joining the CG you keep track of things via the RSS feed
> (it is after all public) and post to the WHATWG mailing list with
> "observations" every once in a while - as long as core CG members know
> to keep an eye out that's not necessarily a huge problem.
> 
> I dunno, politics complicates stuff. And patenting open-web stuff to
> me seems wrong on any number of levels.

CGs actually have very little patent obligation compared to W3C Working Groups, 
so Apple has lighter weight approval for those than for WGs. Perhaps Google 
could consider the same thing. I believe the CG rules would not allow an 
employee of a W3C Member company to be a "free agent" though.

 - Maciej

Re: [whatwg] Defaulting new image solution to 192dpi

On Thu, 17 May 2012 19:33:07 +0100, Tab Atkins Jr.   
wrote:



I think that 2x only looks like a good default now. I would bet that
in less than 10 years 3x or higher will look like a good default.


So why is 1x the default when it's obvious that it is not going to be a  
good

default?


Because it's simple (1 image pixel = 1 CSS pixel), and it was the
historical default.


But it's going to become completely useless and nobody is going to use it.  
2x default at least has a chance of not being useless.


--
regards, Kornel Lesiński

Re: [whatwg] Problems with width/height descriptors in srcset

On Thu, 17 May 2012 19:15:36 +0100, Matthew Wilcox  
 wrote:



I also agree with Tab and Jeremy on this one - that makes a lot more
sense to me and removes any ambiguity without being overly verbose.


I like the less-compressed, more CSSy syntax as well.

I have two concerns though:

Is any media query allowed?
If so, then use of "min-device-pixel-ratio:2x" would give inferior results  
to using the "2x" multiplier, because 2x allows UA to choose when the 2x  
image is selected (taking into account bandwidth, zoom, user preference,  
etc.), but min-device-pixel-ratio is supposed to query a fact about the  
device, not a preference. Should that be discouraged, or maybe even  
special-cased as an alias of "2x" descriptor?



How do scaling factors and size queries interact?

When only scaling factors are specified then selection is easy, and images  
could be described in any order:






If "first one that matches" rule was applied to density descriptors, then  
this would surprisingly fail:



because a 2x screen can display 1x image (or the opposite case would fail  
depending how you define matching of density).



As soon as sizes are specified, taking into account order of the rules  
becomes unavoidable:




on a screen that is larger than 100x100 both would match, so there needs  
to be some definition which one wins, e.g. the first one that matches.




but can UA choose the second image in this case when it prefers 2x density?


i.e. is the rule going to be "first which matches at any density" or  
"first which matches at desired density, and failing that the first which  
matches at any other density"?


--
regards, Kornel Lesiński

Re: [whatwg] Defaulting new image solution to 192dpi

On Thu, May 17, 2012 at 11:23 AM, Kornel Lesiński  wrote:
> On Thu, 17 May 2012 16:05:13 +0100, Tab Atkins Jr. 
> wrote:
>>> Necessity to specify 2x scaling all the time will become a bad default
>>> and a historical quirk (like the DOCTYPE), and a source of annoyance where
>>> accidentally omitted "2x" syntax makes images large and pixelated.
>>
>> I think that 2x only looks like a good default now. I would bet that
>> in less than 10 years 3x or higher will look like a good default.
>
> So why is 1x the default when it's obvious that it is not going to be a good
> default?

Because it's simple (1 image pixel = 1 CSS pixel), and it was the
historical default.

~TJ

Re: [whatwg] Defaulting new image solution to 192dpi

2012-05-17 Thread Jeremy Keith

Kornel wrote:
> Note that the scale multiplier can be omitted already when only the size is 
> specified

I'm confused by what you mean by scale multiplier. The x value describes the 
pixel density of the device/screen, not the image, right?

Jeremy

-- 
Jeremy Keith

a d a c t i o

http://adactio.com/

Re: [whatwg] Correcting some misconceptions about Responsive Images

2012-05-17 Thread Rafael Weinstein

On Thu, May 17, 2012 at 11:12 AM, Matthew Wilcox  wrote:
> On 17 May 2012 18:49, Rafael Weinstein  wrote:
>> It's easy to see how the experience you describe below would be
>> frustrating. FWIW, I routinely feel frustration at seemingly wasted
>> time.
>>
>> Unfortunately, it's inescapable that reaching consensus can be
>> exhausting, especially via email -- and doing so always requires
>> re-explaining the same thing multiple times in multiple ways. This is
>> true for everyone.
>
> Agreed, there will always be an element of this - although in the case
> of the CG this got to the point that we addressed it with a FAQ page.
> That helped us and people visiting. It didn't seem to help the WG, for
> whatever reason?
>
>> In fairness to Hixie -- being an editor is fairly thankless and he
>> does a remarkable job of keeping up even just with whatwg, webapps and
>> a few others (I gave up long ago). If you need someone to understand
>> something, it's best to directly bring it to their attention. The
>> internet is a big place =-).
>
> I can see both sides of this. When you're busy, you're busy, and Hixie
> is busy. On the other hand, this was a long drawn out multi-month
> problem that was talked about quite literally everywhere. It's the
> fact that the scope of awareness everywhere else was so large that
> makes it so surprising it was missed in the one group that it ought to
> have been forefront of that subject.
>
>> I agree with both Jonas and Maciej's points above about lessons for the 
>> future.
>>
>> It seems like the basic problem is that a feature which needs lots of
>> work collecting use cases and developer feedback requires a setting
>> which isn't intimidating for developers -- but ultimately, if it wants
>> to land in a spec, it needs the perspective and experience of
>> implementors and editors.
>
> I think we all agree on that :)
>
>> A few humble thoughts
>>
>> -Have the CG recruit an experienced implementor or editor to
>> participate more or less from the beginning. This may short-circuit
>> time spent on solutions that won't work for esoteric reasons, and
>> there will be at least one person with one foot in both worlds.
>
> This would be awesome.
>
>> -Cross-post significant outputs & decisions to whatwg, public-webapps,
>> etc... E.g. collected use cases, strawman proposals, recommendations,
>> etc... Even with the help of an implementors/editor, the ideas that
>> survive are those that withstand the scrutiny of the entire community
>> and getting that scrutiny early is nearly always better.
>
> Cross posting is always risky. If the items under discussion are still
> maliable then what happens is two discussions break out between two
> lots of un-related groups and things get messy.
>
> I'd be up for this route only if it was very clear of the role of each
> party, and lines could be drawn that properly segment the discussions.
> i.e.,
>
> 1) CG: "We have collected enough use cases from a wide spread of
> authors; we are now presenting this back to the WHATWG - if you wish
> to follow along with possible solutions, please take part there"
> 2) WG: discusses possible solutions and *whenever* there is doubt
> about what an author would prefer to do or what they will understand,
> it gets bounced back to the CG
> 3) CG: present the WG's dilema in a succinct way that presumes no
> prior knowledge, and solicit feedback from authors outside of the WG
> list, which is then fed back to the WG.
> 4) WG: makes decisions based on that feedback.
>
> That to me would work best for both communities.

I think the sentiment behind these to good, but I'd caution against
relying on process and specified roles.

The goal here shouldn't be to slice up areas of responsibility -- that
seems likely to contribute to -- not mitigate -- people digging in
their heels. It's a good feature that anyone can wear whatever hat
they like.

My observation is that when good stuff happens, it's because a set of
people dedicate themselves dispassionately to doing whatever required
to pursue a good outcome -- not because of any formal process which is
ultimately unenforceable.

Re: [whatwg] Defaulting new image solution to 192dpi

On Thu, 17 May 2012 16:05:13 +0100, Tab Atkins Jr.
wrote:

Necessity to specify 2x scaling all the time will become a bad default
and a historical quirk (like the DOCTYPE), and a source of annoyance
where

accidentally omitted "2x" syntax makes images large and pixelated.

I think that 2x only looks like a good default now. I would bet that
in less than 10 years 3x or higher will look like a good default.

So why is 1x the default when it's obvious that it is not going to be a
good default?

"If density is still absent, set it to 1.0."
http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#image-candidate-string

Note that the scale multiplier can be omitted already when only the size
is specified:

This is currently a legal syntax for a 1x image, and this is going to be
an awful mistake regardless whether we'll have 2x or 3x displays in the
future.

I'd rather not bake in a confusing change that doesn't actually
future-proof anything.

I think it's a safe bet that 3x won't ever be a good default.

Authors will need to translate between CSS and image pixel sizes, and it's
much easier to multiply and divide by 2 than 3.

Keep in mind that scaling factor is not tied too much to actual display
DPI/perceived pixel size. When new denser displays come along, we won't
jump from 2x to 3x, rather the 2x will change its meaning.

This is exactly what happened with pixel size at 1x — it has shrunk over
the years from 72dpi (SVGA 14") to 108dpi (iMac 27") and 130dpi on
laptops. Assuming same viewing distances, that's a hefty 1.5-1.8x increase
in resolution!

When resolution of current desktops doubles we'll start at around 200dpi,
and the pixel size will likely continue to shrink gradually over time as
displays get less-than-full-multiplier increases in density.

If such 1.5-1.8 increase happens again, the meaning of "2x" will end up
being in the 300-360dpi range for desktop viewing distances. That will be
much better than 264dpi on the "Retina" iPad today (even better
considering iPad's smaller viewing distance).

Those pixels will be much smaller than average human can see — I think
that's perfectly adequate for a default!

Further improvements over this would have diminishing results — once
pixels are indistinguishable it won't make sense to make them more
indistinguishable, so there will be very little reason to use 3x, 4x
factors.

But let's say I'm wrong and 3x will end up being the ultimate scaling
factor:

- when authors specify the 3x scaling factor explicitly, it'll all work
fine regardless of the default.

- if the we don't change the default, then failing to specify the 3x scale
factor will give very wrong result — a 1x image.

- if we change the default to 2x, then failing to specify the 3x scale
factor will give less wrong result — a 2x image.

Only if we change the default to 3x now, before srcset ships we will avoid
the problem entirely. But as I've explained above, it's an inconvenient
scaling factor and is likely to overshoot required quality, so 2x is a
safer bet.

But why oh why should we keep 1x as the default if it's going to be the
worst default in any case?

--
regards, Kornel Lesiński

Re: [whatwg] Correcting some misconceptions about Responsive Images

On 17 May 2012 19:15, Tab Atkins Jr.  wrote:
> On Thu, May 17, 2012 at 11:12 AM, Matthew Wilcox  
> wrote:
>>> A few humble thoughts
>>>
>>> -Have the CG recruit an experienced implementor or editor to
>>> participate more or less from the beginning. This may short-circuit
>>> time spent on solutions that won't work for esoteric reasons, and
>>> there will be at least one person with one foot in both worlds.
>>
>> This would be awesome.
>
> FWIW, I wanted to do this, but Google's policy of having us talk to
> the patents guys before joining CGs turned me off from actually
> joining.  So, I just followed from the side and couldn't interact
> enough. :/

Is this something that Google might be willing to bend somewhat? I.e.,
when you're on the CG you're a free-agent and not representing Google?
Or, for the sake of politics, could it be worked around in that
instead of joining the CG you keep track of things via the RSS feed
(it is after all public) and post to the WHATWG mailing list with
"observations" every once in a while - as long as core CG members know
to keep an eye out that's not necessarily a huge problem.

I dunno, politics complicates stuff. And patenting open-web stuff to
me seems wrong on any number of levels.

Re: [whatwg] Correcting some misconceptions about Responsive Images

On Thu, May 17, 2012 at 11:12 AM, Matthew Wilcox  wrote:
>> A few humble thoughts
>>
>> -Have the CG recruit an experienced implementor or editor to
>> participate more or less from the beginning. This may short-circuit
>> time spent on solutions that won't work for esoteric reasons, and
>> there will be at least one person with one foot in both worlds.
>
> This would be awesome.

FWIW, I wanted to do this, but Google's policy of having us talk to
the patents guys before joining CGs turned me off from actually
joining.  So, I just followed from the side and couldn't interact
enough. :/

~TJ

Re: [whatwg] Problems with width/height descriptors in srcset

I also agree with Tab and Jeremy on this one - that makes a lot more
sense to me and removes any ambiguity without being overly verbose.

> I asked:
>> Related question: do we still want to keep this unit-less i.e. ditch the 
>> "px" from the examples above? Or, if we're going to use this CSS-like syntax 
>> anyway, allow other units of measurement (e.g. ems).
>
> And Tab replied:
>> No, if we're aping the CSS syntax more closely, we should just use CSS units.
>
> I agree. Seems like the sensible approach. It also allows authors who are 
> using ems for their media queries in CSS to also use ems for their srcset 
> declarations.
>
> Jeremy

Re: [whatwg] Correcting some misconceptions about Responsive Images

On 17 May 2012 18:49, Rafael Weinstein  wrote:
> It's easy to see how the experience you describe below would be
> frustrating. FWIW, I routinely feel frustration at seemingly wasted
> time.
>
> Unfortunately, it's inescapable that reaching consensus can be
> exhausting, especially via email -- and doing so always requires
> re-explaining the same thing multiple times in multiple ways. This is
> true for everyone.

Agreed, there will always be an element of this - although in the case
of the CG this got to the point that we addressed it with a FAQ page.
That helped us and people visiting. It didn't seem to help the WG, for
whatever reason?

> In fairness to Hixie -- being an editor is fairly thankless and he
> does a remarkable job of keeping up even just with whatwg, webapps and
> a few others (I gave up long ago). If you need someone to understand
> something, it's best to directly bring it to their attention. The
> internet is a big place =-).

I can see both sides of this. When you're busy, you're busy, and Hixie
is busy. On the other hand, this was a long drawn out multi-month
problem that was talked about quite literally everywhere. It's the
fact that the scope of awareness everywhere else was so large that
makes it so surprising it was missed in the one group that it ought to
have been forefront of that subject.

> I agree with both Jonas and Maciej's points above about lessons for the 
> future.
>
> It seems like the basic problem is that a feature which needs lots of
> work collecting use cases and developer feedback requires a setting
> which isn't intimidating for developers -- but ultimately, if it wants
> to land in a spec, it needs the perspective and experience of
> implementors and editors.

I think we all agree on that :)

> A few humble thoughts
>
> -Have the CG recruit an experienced implementor or editor to
> participate more or less from the beginning. This may short-circuit
> time spent on solutions that won't work for esoteric reasons, and
> there will be at least one person with one foot in both worlds.

This would be awesome.

> -Cross-post significant outputs & decisions to whatwg, public-webapps,
> etc... E.g. collected use cases, strawman proposals, recommendations,
> etc... Even with the help of an implementors/editor, the ideas that
> survive are those that withstand the scrutiny of the entire community
> and getting that scrutiny early is nearly always better.

Cross posting is always risky. If the items under discussion are still
maliable then what happens is two discussions break out between two
lots of un-related groups and things get messy.

I'd be up for this route only if it was very clear of the role of each
party, and lines could be drawn that properly segment the discussions.
i.e.,

1) CG: "We have collected enough use cases from a wide spread of
authors; we are now presenting this back to the WHATWG - if you wish
to follow along with possible solutions, please take part there"
2) WG: discusses possible solutions and *whenever* there is doubt
about what an author would prefer to do or what they will understand,
it gets bounced back to the CG
3) CG: present the WG's dilema in a succinct way that presumes no
prior knowledge, and solicit feedback from authors outside of the WG
list, which is then fed back to the WG.
4) WG: makes decisions based on that feedback.

That to me would work best for both communities.

Re: [whatwg] Problems with width/height descriptors in srcset

2012-05-17 Thread Jeremy Keith

I wrote:
> Well, right now the spec text says:
> 
> "omitted width descriptors and height descriptors are considered to have the 
> value "Infinity""
> 
> Does that mean I could ditch the 92000w and just leave it blank?
> 
> 

But I know realise that, according to the spec, I *must* specify at least one 
value. So actually I'd have to write:

...which seems to muddy the waters a bit. I actually don't care about the 
pixel-density of the device in this case, but I need to write 1x because I have 
to include at least one value.

I much prefer Tab's suggestion:

> I think we should just go with a "min-width:100px" approach, which is much 
> clearer.
> It also lets us add "max-width"

I asked:
> Related question: do we still want to keep this unit-less i.e. ditch the "px" 
> from the examples above? Or, if we're going to use this CSS-like syntax 
> anyway, allow other units of measurement (e.g. ems).

And Tab replied:
> No, if we're aping the CSS syntax more closely, we should just use CSS units.

I agree. Seems like the sensible approach. It also allows authors who are using 
ems for their media queries in CSS to also use ems for their srcset 
declarations.

Jeremy

-- 
Jeremy Keith

a d a c t i o

http://adactio.com/

Re: [whatwg] Problems with width/height descriptors in srcset

On Thu, May 17, 2012 at 10:27 AM, Jeremy Keith  wrote:
> Tab wrote:
>> Absolutely agreed.  Like several others have suggested, I think we
>> should just go with a "min-width:100px" approach, which is much
>> clearer.  It also lets us add "max-width", though that may complicate
>> the resource choosing algorithm a bit.
>
> Just to be clear, do you mean changing the syntax so that Nw is replaced with 
> min-width:N?
>
> e.g.
>
> 
>
> or
>
> 

Yes, you got it.

> Those two examples would then be functionally equivalent (give or take a 
> single pixel) but allow developers to take a "Mobile First" or "Desktop 
> First" approach according to their preference.
>
> Related question: do we still want to keep this unit-less i.e. ditch the "px" 
> from the examples above? Or, if we're going to use this CSS-like syntax 
> anyway, allow other units of measurement (e.g. ems).

No, if we're aping the CSS syntax more closely, we should just use CSS units.

~TJ

Re: [whatwg] Correcting some misconceptions about Responsive Images

2012-05-17 Thread Rafael Weinstein

It's easy to see how the experience you describe below would be
frustrating. FWIW, I routinely feel frustration at seemingly wasted
time.

Unfortunately, it's inescapable that reaching consensus can be
exhausting, especially via email -- and doing so always requires
re-explaining the same thing multiple times in multiple ways. This is
true for everyone.

In fairness to Hixie -- being an editor is fairly thankless and he
does a remarkable job of keeping up even just with whatwg, webapps and
a few others (I gave up long ago). If you need someone to understand
something, it's best to directly bring it to their attention. The
internet is a big place =-).

I agree with both Jonas and Maciej's points above about lessons for the future.

It seems like the basic problem is that a feature which needs lots of
work collecting use cases and developer feedback requires a setting
which isn't intimidating for developers -- but ultimately, if it wants
to land in a spec, it needs the perspective and experience of
implementors and editors.

A few humble thoughts

-Have the CG recruit an experienced implementor or editor to
participate more or less from the beginning. This may short-circuit
time spent on solutions that won't work for esoteric reasons, and
there will be at least one person with one foot in both worlds.

-Cross-post significant outputs & decisions to whatwg, public-webapps,
etc... E.g. collected use cases, strawman proposals, recommendations,
etc... Even with the help of an implementors/editor, the ideas that
survive are those that withstand the scrutiny of the entire community
and getting that scrutiny early is nearly always better.

On Thu, May 17, 2012 at 9:18 AM, Matthew Wilcox  wrote:
> On 17 May 2012 17:00, Rafael Weinstein  wrote:
>> As a UA "implementor", this seem to me to be purely a success story
>> for the single reason that it drew so much developer participation.
>>
>> Regardless of what makes it into the spec, the worst possible outcome
>> would be if the developer community learned the lesson that UA
>> implementors are hostile to/dismissive of their problems, ideas and
>> solutions.
>>
>> It seems to me like there's a problem of "walking a mile in someone
>> else's shoes" in both directions, but ultimately developers are our
>> customers -- not vice versa.
>>
>> If it's required for either "camp" to go the extra mile to accomodate
>> the other -- it seems to me that it ought to be us.
>
> It's been a series of unfortunate things to be honest.
>
> 1) First off many members of the CG have been working on the adaptive
> images problem for close to a year at this point.
> 2) When a few went to the mailing lists some months ago, we were met
> with the realisation that Hixie was not even aware there was a problem
> (at this point it had already had months of outspoken and loud
> attention in the wider community, including a few publications in
> major web sites and magazines). That the 'lead' of the WG was ignorant
> of the issue left a few of us incredulous.
> 3) Then because the mail lists are not friendly to newcomers members
> of the group were mis-directed to form a spin off group.
> 4) Then the more recent communication fiasco with regard to srcset and 
> 
>
> The problem of miscommunication and poorly documented
> newcomer-unfriendly channels is not new. The rub on this one is *just
> how much work* has been put into the subject - as I say, close to a
> year - and then the realisation of so much seemingly being a waste. Or
> at least not seen to be valued, used, or openly discussed by the
> WHATWG, before some other (apparently random, to us) idea got pushed
> forward. As I say, the CG have discussed all of this openly, published
> in prominant magazines, done our due diligence research into any
> number of existing solutions etc.
>
> To see srcset appear from the shrouded mists of the WG mailing list was a 
> shock.

[whatwg] Fw: for responsive bitmapped content images

2012-05-17 Thread Ungureanu Dumitru




- Forwarded Message -
From: Ungureanu Dumitru 
To: Julian Reschke  
Sent: Thursday, 17 May 2012, 18:52
Subject: Re: [whatwg]  for responsive bitmapped content images
 

Having multiple src's for an image is similar to AJAX for content. Why 
is it a good idea to have a default AJAX for images but not for content, beats 
me.



 From: Julian Reschke 
To: Edward O'Connor  
Cc: wha...@whatwg.org 
Sent: Wednesday, 16 May 2012, 12:22
Subject: Re: [whatwg]  for responsive bitmapped content images
 
On 2012-05-10 09:58, Edward O'Connor 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
>   element.
> 
> The srcset="" attribute takes as its argument a simplified variant of
> the image-set() microsyntax[2]. It would look something like this:
> 
>        srcset="foo-hires.jpg 2x, foo-superduperhires.jpg 6.5x"
>       alt="decent alt text for foo.">
> ...

Inventing a new microsyntax is tricky.

- "comma separated" implies you'll need to escape a comma when it appears in a 
URI; this may be a problem when the URI scheme assigns a special meaning to the 
comma (so it
 doesn't affect HTTP but still...)

- separating URIs from parameters with whitespace implies that the URIs are 
valid (in that they do not contain whitespace themselves); I personally have no 
problem with that, but it should be kept in mind

Best regards, Julian

Re: [whatwg] Problems with width/height descriptors in srcset

2012-05-17 Thread Jeremy Keith

Odin wrote:
>  
> 
> I really admit that the 92000w looks really ugly. And if you have a
> viewport that is wider than 92,000 px it will choose the small.png.
> 
> Maybe it should have a Infinite marker for that case. Can't think of a
> beautiful solution there.

Well, right now the spec text says:

"omitted width descriptors and height descriptors are considered to have the 
value "Infinity""

Does that mean I could ditch the 92000w and just leave it blank?

Would that result in this behaviour?:

"Use small.png unless the viewport is less than infinite pixels wide, in which 
case use large.png, unless the viewport is less than 800 pixels wide, in which 
case use medium.png, unless the viewport is less than 600 pixels wide, in which 
case use small.png after all."

I still *must* declare small.png twice (once in src and once again in srcset) 
but at least I don't have to write an arbitrarily large number for Nw).

This still favours a "Desktop First" approach (where no duplication of image 
URLs is necessary) but at least a "Mobile First" approach is possible.

Tab wrote:
> Absolutely agreed.  Like several others have suggested, I think we
> should just go with a "min-width:100px" approach, which is much
> clearer.  It also lets us add "max-width", though that may complicate
> the resource choosing algorithm a bit.

Just to be clear, do you mean changing the syntax so that Nw is replaced with 
min-width:N?

e.g.

or

Those two examples would then be functionally equivalent (give or take a single 
pixel) but allow developers to take a "Mobile First" or "Desktop First" 
approach according to their preference.

Related question: do we still want to keep this unit-less i.e. ditch the "px" 
from the examples above? Or, if we're going to use this CSS-like syntax anyway, 
allow other units of measurement (e.g. ems).

Jeremy

-- 
Jeremy Keith

a d a c t i o

http://adactio.com/

Re: [whatwg] / not needed

On Thu, May 17, 2012 at 9:45 AM, Aldrik Dunbar  wrote:
> In that case it sounds like we need somthing like the -ms-high-contrast
> [1] media feature needs to become a standard.
>
>
> [1] http://msdn.microsoft.com/en-us/library/ie/hh771830(v=vs.85).aspx

It's already on the list of things that'll go into Media Queries 4.
The editor just wants to talk to the a11y people  first to see exactly
what the meaning of it should be.

~TJ

Re: [whatwg] / not needed

2012-05-17 Thread Kevin Marks

Jpeg 2000 has wavelet coding and progressive loading so you can stop at the
desired resolution (if you decode on the read thread). Presumably it will
be patent free by 2020...
On May 16, 2012 3:57 PM, "Glenn Maynard"  wrote:

> On Wed, May 16, 2012 at 5:44 PM, Aldrik Dunbar  wrote:
>
> > Of course if someone comes up with a progressively loaded image format
> > this could be handled much more elegantly.
> >
>
> Both PNG and JPEG have had this forever.  (PNG's approach is crude, but
> JPEG's is reasonable.)  However, there's no way to control it client-side;
> without somehow knowing how many bytes to load for a certain amount of
> detail, all you can do is load the whole thing (or make multiple requests,
> which is obviously worse).   I've thought about this in the past, but it's
> a hard thing to make practical use of.
>
> --
> Glenn Maynard
>

Re: [whatwg] / not needed

2012-05-17 Thread Scott González

On Thu, May 17, 2012 at 12:45 PM, Aldrik Dunbar  wrote:

> In that case it sounds like we need somthing like the -ms-high-contrast
> [1] media feature needs to become a standard.
>
> [1] http://msdn.microsoft.com/en-us/library/ie/hh771830(v=vs.85).aspx
>

I hadn't seen that before, I was actually going to propose this at some
point in the future (whenever we get around to high contrast support in
jQuery UI). I think standardizing this would be really useful, I'll start a
separate thread for this; hopefully we can get some input from Apple.

Re: [whatwg] / not needed

2012-05-17 Thread Aldrik Dunbar

> Assistive technology can't magically detect that your image has low
> contrast and provide a better image. I don't think that AT even comes
> into play as high contrast mode is handled by the OS. High contrast
> mode is not the same as choosing a monochrome display. On Windows, the
> default high contrast display is mostly white on black, but there are
> still colors, and text is larger. On OS X, high contrast mode is just
> extremely contrasty with lots of detail getting washed out; you can
> separately choose to use grayscale and/or invert colors.
>
> Authors may want to provide images with lots of detail, but fall back
> to images with less detail and/or larger objects/text in the case of
> high contrast mode.

In that case it sounds like we need somthing like the -ms-high-contrast 
[1] media feature needs to become a standard.


[1] http://msdn.microsoft.com/en-us/library/ie/hh771830(v=vs.85).aspx

Re: [whatwg] Correcting some misconceptions about Responsive Images

On 17 May 2012 17:00, Rafael Weinstein  wrote:
> As a UA "implementor", this seem to me to be purely a success story
> for the single reason that it drew so much developer participation.
>
> Regardless of what makes it into the spec, the worst possible outcome
> would be if the developer community learned the lesson that UA
> implementors are hostile to/dismissive of their problems, ideas and
> solutions.
>
> It seems to me like there's a problem of "walking a mile in someone
> else's shoes" in both directions, but ultimately developers are our
> customers -- not vice versa.
>
> If it's required for either "camp" to go the extra mile to accomodate
> the other -- it seems to me that it ought to be us.

It's been a series of unfortunate things to be honest.

1) First off many members of the CG have been working on the adaptive
images problem for close to a year at this point.
2) When a few went to the mailing lists some months ago, we were met
with the realisation that Hixie was not even aware there was a problem
(at this point it had already had months of outspoken and loud
attention in the wider community, including a few publications in
major web sites and magazines). That the 'lead' of the WG was ignorant
of the issue left a few of us incredulous.
3) Then because the mail lists are not friendly to newcomers members
of the group were mis-directed to form a spin off group.
4) Then the more recent communication fiasco with regard to srcset and 

The problem of miscommunication and poorly documented
newcomer-unfriendly channels is not new. The rub on this one is *just
how much work* has been put into the subject - as I say, close to a
year - and then the realisation of so much seemingly being a waste. Or
at least not seen to be valued, used, or openly discussed by the
WHATWG, before some other (apparently random, to us) idea got pushed
forward. As I say, the CG have discussed all of this openly, published
in prominant magazines, done our due diligence research into any
number of existing solutions etc.

To see srcset appear from the shrouded mists of the WG mailing list was a shock.

Re: [whatwg] Correcting some misconceptions about Responsive Images

2012-05-17 Thread Rafael Weinstein

As a UA "implementor", this seem to me to be purely a success story
for the single reason that it drew so much developer participation.

Regardless of what makes it into the spec, the worst possible outcome
would be if the developer community learned the lesson that UA
implementors are hostile to/dismissive of their problems, ideas and
solutions.

It seems to me like there's a problem of "walking a mile in someone
else's shoes" in both directions, but ultimately developers are our
customers -- not vice versa.

If it's required for either "camp" to go the extra mile to accomodate
the other -- it seems to me that it ought to be us.

On Thu, May 17, 2012 at 8:07 AM, Tab Atkins Jr.  wrote:
> On Thu, May 17, 2012 at 2:18 AM, James Graham  wrote:
>> FWIW I think that forming community groups that are limited in scope to
>> gathering and distilling the relevant use cases could be a functional way of
>> working. For example if, in this case, people had said "we will form a group
>> that will spend 4 weeks documenting and prioritising all the use cases that
>> a responsive images feature needs to cover" and then the results of that
>> work had been taken to a forum where browser implementors are engaged (e.g.
>> WHATWG), I think we would have had a relatively smooth ride toward a
>> universially acceptable solution.
>
> Yup.  This is basically what the CG *did*, in practice, and it was
> very useful.  There was an unfortunate expectation that their goal was
> to write spec text that would be simply adopted into the spec, though.
>  Making sure the expectations are clearer in the future would be a
> good move.
>
> ~TJ

Re: [whatwg] Correcting some misconceptions about Responsive Images

On 17 May 2012 16:07, Tab Atkins Jr.  wrote:
> On Thu, May 17, 2012 at 2:18 AM, James Graham  wrote:
>> FWIW I think that forming community groups that are limited in scope to
>> gathering and distilling the relevant use cases could be a functional way of
>> working. For example if, in this case, people had said "we will form a group
>> that will spend 4 weeks documenting and prioritising all the use cases that
>> a responsive images feature needs to cover" and then the results of that
>> work had been taken to a forum where browser implementors are engaged (e.g.
>> WHATWG), I think we would have had a relatively smooth ride toward a
>> universially acceptable solution.

While this is true in some form, in order to be useful we had to
consider different approaches and get the feedback about those
approaches. It wasn't just "get use cases" so much as "get use cases,
decide whether a pattern we are suggesting answers them, and then
canvas authors to see if they actually understand it and react well to
it?".

If the WHATWG are not willing to join CG's in order to give their
input then the route would effectively end up being:

1) Spin off a CG to gather use cases
2) grab info and apply back to WHATWG mail list
3) WHATWG mail list decides on possible approaches
4) Spin the approaches off to CG and gather wider feedback
5) goto 2

I don't mind that approach, but the problem is once you involve a
wider community you *will* get that community discussing technical
stuff there - divorced from the WHATWG members.

The fact of the matter is that the wider public find a website in the
format of the CG far easier to access and engage than mail lists.
That's neither a good or bad thing, it just is. How it should be
managed is where it gets difficult.

> Yup.  This is basically what the CG *did*, in practice, and it was
> very useful.  There was an unfortunate expectation that their goal was
> to write spec text that would be simply adopted into the spec, though.
>  Making sure the expectations are clearer in the future would be a
> good move.

That would have been a hugely beneficial thing.

> ~TJ

Re: [whatwg] Correcting some misconceptions about Responsive Images

On Thu, May 17, 2012 at 2:18 AM, James Graham  wrote:
> FWIW I think that forming community groups that are limited in scope to
> gathering and distilling the relevant use cases could be a functional way of
> working. For example if, in this case, people had said "we will form a group
> that will spend 4 weeks documenting and prioritising all the use cases that
> a responsive images feature needs to cover" and then the results of that
> work had been taken to a forum where browser implementors are engaged (e.g.
> WHATWG), I think we would have had a relatively smooth ride toward a
> universially acceptable solution.

Yup.  This is basically what the CG *did*, in practice, and it was
very useful.  There was an unfortunate expectation that their goal was
to write spec text that would be simply adopted into the spec, though.
 Making sure the expectations are clearer in the future would be a
good move.

~TJ

Re: [whatwg] Defaulting new image solution to 192dpi

On Thu, May 17, 2012 at 4:30 AM, Kornel Lesiński  wrote:
> My suggestion is that the srcset (or ) should assume that images
> are "2x" scale by default.
>
> My reasoning behind is:
>
> - we have  for easy embedding of 1x images today, but we don't have 2x
>  for the future. Having to specify width/height in  all the time
> is annoying.
>
> - highdpi displays will become dominant at some point, it's only a matter of
> time (they pretty much are already in high-end smartphones, and are going to
> appear in laptops next). Bandwidth is also going to be less of a concern, so
> it'll be rational and desirable to serve images for the 2x resolution only
> (and just rely on 96dpi displays scaling them down).

I think this will be a confusing change that will hurt more than it
helps.  URLs in @srcset should act exactly like URLs in @src, except
where modified by the descriptors.

> Necessity to specify 2x scaling all the time will become a bad default and a
> historical quirk (like the DOCTYPE), and a source of annoyance where
> accidentally omitted "2x" syntax makes images large and pixelated.

I think that 2x only looks like a good default now. I would bet that
in less than 10 years 3x or higher will look like a good default.  I'd
rather not bake in a confusing change that doesn't actually
future-proof anything.

~TJ

Re: [whatwg] So if media-queries aren't for determining the media to be used what are they for?

On Thu, 17 May 2012 15:13:58 +0100, Matthew Wilcox  
 wrote:



I'd also point out I'm not claiming this is a replacement for srcset
or . I think it's a useful additional tool for web
developers, but it is aimed at *site wide* generalised uses to make
life a lot easier - I can't see a way to make it also cater to
specific individual instances without fundamentally breaking the
benefits of the generalisation.


I see. So we could proceed with the spec without it, and add it later.

What if you're creating WYSIWYG editor for CMSes and want to have  
button for inserting adaptive images, but have no access to ?


This is not a valid use case (to my mind). You'd not be choosing
response points for individual pictures, it is the design that has
response points and it's the CSS (and JS/HTML) which fit into the
design's breakpoints.


OK.

I see no nice solution for case when authors put  in  


— it'd either have re-evaluate and potentially reload images (wasted
requests) or ignore the meta (annoying gotcha when HTML5 parser  
unexpectedly

closes  or when people want to work around lack of access to the
)


This solution does not allow for  in the body, and nor does the
HTML5 spec unless I'm mistaken?


What spec allows and what happens on the web are separate things :)

HTML needs to define all error cases and be prepared for markup to be  
abused (lots of such cases had to be defined already).


How do you work with URLs you have no control over? e.g. you'd have to  
name
your breakpoints "40" and "80" to have adaptive size of gravatar.com  
URLs.


I'm not sure I understand this point. However you cook it, you have no
access to those images so you can't do anything with them regardless
of the method of adaption, be it this method, srcset, or .


Yes, you can. gravatar.com allows you to specify desired size:

gravarar.com/avatar/hash?s=40 # gives 40x40px image
gravarar.com/avatar/hash?s=80 # gives 80x80px image


What do you do when you have only two breakpoints for sidebar, but more  
for the main content? (mostly fixed-width sidebar with fluid main  
column) or if your page header adapts to portrait orientation, but  
images in main content only adapt to width?


Breakpoints are not something that apply to individual components,
they apply to the page as a whole?


In my designs I use it mainly for components. I don't think of pages as  
separate phone/tablet/desktop designs, but as fluid designs which fold and  
unfold component by component.



Let's say my fancy header logo is quite tall, and that doesn't look well  
in landscape orientation, so I want to use short/wide version of the  
design in landscape orientation.


And I have a square illustration in my content. It doesn't flip on  
orientation, but I want it to be 500x500px on 1000px+ screens, and  
320x320px on smaller ones.


In some srcset-source pseudocode I'd say:





	



How would you do that with breakpoints?

--
regards, Kornel Lesiński

Re: [whatwg] / not needed

2012-05-17 Thread Scott González

On Thu, May 17, 2012 at 10:24 AM, Aldrik Dunbar  wrote:

> On 2012/05/17 09:17, Scott González wrote:
> > I don't think this should just be about device capability. Users with
> > vision problems may opt-in to high contract mode and you may need to load
> > different resources based on this.
>
> I think assertive technology's can handled high contrast and colour
> blindness filters (additional images aren't really needed). Also
> monochrome can already be catered for with SVG/CSS.
>

Assistive technology can't magically detect that your image has low
contrast and provide a better image. I don't think that AT even comes into
play as high contrast mode is handled by the OS. High contrast mode is not
the same as choosing a monochrome display. On Windows, the default high
contrast display is mostly white on black, but there are still colors, and
text is larger. On OS X, high contrast mode is just extremely contrasty
with lots of detail getting washed out; you can separately choose to use
grayscale and/or invert colors.

Authors may want to provide images with lots of detail, but fall back to
images with less detail and/or larger objects/text in the case of high
contrast mode.

Re: [whatwg] / not needed

2012-05-17 Thread Aldrik Dunbar

On 2012/05/17 09:17, Scott González wrote:
> On Thu, May 17, 2012 at 7:30 AM, Bjartur Thorlacius 
> wrote:
> 
> > How common will it be for modern UAs to render pages to monochrome
> > displays using future HTML5 graphics features? How many of the monochrome
> > displays that are left will be attached to systems with modern heavy-weight
> > software? In fact, the only systems I know of that come close to being
> > monochrome are handhelds whose software isn't ever updated, and terminals
> > that aren't even used to display bitmaps. So I have to ask, for how long
> > will color-depth negotiation be a strong enough use case to warrant this
> > feature?
> >
> 
> I don't think this should just be about device capability. Users with
> vision problems may opt-in to high contract mode and you may need to load
> different resources based on this.

I think assertive technology's can handled high contrast and colour 
blindness filters (additional images aren't really needed). Also 
monochrome can already be catered for with SVG/CSS.

Re: [whatwg] Correcting some misconceptions about Responsive Images

>> WHATWG does not exist to be a closed society.
>
> (Is this a joke?  This is probably the most open and approachable spec
> development community in existance today.)

"This is probably the best square wheel there is today" does not make
it a good wheel, even if it's better than all the other square wheels.

If there was only one thing taken from the RICG I'd hope that it was
the observation that it got a *lot* more feedback from general authors
than any of the mailing lists do. It's simply much easier to access
and read than the mailing lists - it's not about the people running
either group, it's about the medium it is in.

Re: [whatwg] So if media-queries aren't for determining the media to be used what are they for?

>> That particular solution is, to my mind, the most flexible and useful
>> implementation I've seen, because it's really about breakpoint
>> management and abstraction - which is what all responsive elements
>> need in order to work together well and be future-friendly.
>>
>> It does, no doubt, have some technical considerations and implications
>> I'm not aware of. I would love to see this worked on more, I don't
>> think there's much more I can add to it from my authors perspective,
>> it needs work from an implementor perspective. But as a pattern, it
>> has a lot of plus points going for it.
>
>
> I'm trying to figure out how it's going to work in other situations than the
> happy case.

That's cool, it needs that level of "how do I break it" thinking.

I'd also point out I'm not claiming this is a replacement for srcset
or . I think it's a useful additional tool for web
developers, but it is aimed at *site wide* generalised uses to make
life a lot easier - I can't see a way to make it also cater to
specific individual instances without fundamentally breaking the
benefits of the generalisation.

> What if you want to provide copy&pasteable code snippet with an adaptive
> image? (like W3C Validator badges)

That would not be a case this method could support fully.
Srcset and  would offer full support for this use case.

That said, I'm not sure of the use case of pasting an adaptive image
into another domain; we're usually adapting the image to a design on a
given domain; any such image is unlikely to work properly in another
context anyway (because that other context has it's own measures at
that or other breakpoints).

> What if you're creating WYSIWYG editor for CMSes and want to have button for
> inserting adaptive images, but have no access to ?

This is not a valid use case (to my mind). You'd not be choosing
response points for individual pictures, it is the design that has
response points and it's the CSS (and JS/HTML) which fit into the
design's breakpoints.
All a CMS does is cater to the "upload a source image, create and/or
associate other images for the breakpoints".

> What if you want to insert a single image with custom/unique breakpoints
> (say an infographic prepared by an agency which used different breakpoints)
> on a website that already has its own breakpoints defined?

This is where  and srcset are useful. However as I say: in
general breakpoints are a property of a design, they are not a
property of the content directly. You do present a valid case for when
a breakpoint may actually be based on the content rather than the
design: infographics are more sensitive to this than the general image
use case (which I believe are photographs or other graphic
illustration).

> I see no nice solution for case when authors put  in 
> — it'd either have re-evaluate and potentially reload images (wasted
> requests) or ignore the meta (annoying gotcha when HTML5 parser unexpectedly
> closes  or when people want to work around lack of access to the
> )

This solution does not allow for  in the body, and nor does the
HTML5 spec unless I'm mistaken?

> How do you work with URLs you have no control over? e.g. you'd have to name
> your breakpoints "40" and "80" to have adaptive size of gravatar.com URLs.

I'm not sure I understand this point. However you cook it, you have no
access to those images so you can't do anything with them regardless
of the method of adaption, be it this method, srcset, or .

> What do you do when you have only two breakpoints for sidebar, but more for
> the main content? (mostly fixed-width sidebar with fluid main column) or if
> your page header adapts to portrait orientation, but images in main content
> only adapt to width?

Breakpoints are not something that apply to individual components,
they apply to the page as a whole?

> --
> regards, Kornel Lesiński

Re: [whatwg] Defaulting new image solution to 192dpi

On Thu, 17 May 2012 14:42:19 +0100, Andy Davies   
wrote:



Try browsing the web on the new iPad today. That's how every display is
going to look like in 10, maybe 20 years. Then DPI negotiation will not  
be an option, it'll be absolute requirement for *every* *single* image.


HTML5 is designed for the next 50-100 years.


The last line is exactly why baking in an assumption on the defaults
isn't the right way to go.


I know, somebody will quote me on "192dpi is enough for everybody", but we  
have 1x scaling assumption baked in already, so I'm suggesting changing  
existing bad assumption to a less bad assumption.



I don't disagree that higher DPI resolutions will be come the norm but
then what are we going to do about lower DPI devices, serve them a
higher DPI than needed image and let them work it out rather than
serve them appropriate images?


Yes. You do the same for 256-color and monochrome displays today, because  
potential bandwidth savings are small and popularity/quality of those  
screens is not significant enough to care.



The Zombie Apocalypse is coming there will be plenty of lower DPI
screens around for a long time...


Bandwidth will increase to the point that serving highdpi image to  
everybody won't be an issue.


Would you care about 100KB image vs 200KB image on 1Gbit connection?  
Google Fiber project is experimenting with such speeds already.


The answer is no: it takes only 0.8ms more, so even with *100* such images  
on the page the delay is literally comparable to blink of an eye  
(http://www.wolframalpha.com/input/?i=100KB+%2F+1Gbit+*+100)


The scaling factor won't increase forever, it's only going to be  
increasing until it matches capabilities of human vision. Depending on  
screen and viewing distance 2x is already claimed to be perfect ("Retina"  
display).


--
regards, Kornel Lesiński

Re: [whatwg] Correcting some misconceptions about Responsive Images

2012-05-17 Thread Glenn Maynard

On Thu, May 17, 2012 at 4:32 AM, Ben Schwarz  wrote:

> Non announcement _here_ is one thing, sure; but as those aiming to plan,
> test and measure different approaches, it's your role to research other
> developments out side of the WHATWG bubble.
>

As you must know, the srcset design did take the other proposals into
account; the  proposal was rejected for clearly-stated reasons.
That's not what we're talking about.

> WHATWG does not exist to be a closed society.
>

(Is this a joke?  This is probably the most open and approachable spec
development community in existance today.)

-- 
Glenn Maynard

Re: [whatwg] Defaulting new image solution to 192dpi

2012-05-17 Thread Andy Davies

On 17 May 2012 14:19, Kornel Lesiński  wrote:
> On Thu, 17 May 2012 13:47:12 +0100, Andy Davies  wrote:
>
>> srcset can be used to offer alternatives for higher or lower DPI,
>> and/or larger or smaller viewports so I'm still not convinced that an
>> assumption that somehow it should assume that the srcset images are 2x
>> scale by default really helps.
>>
>> Much of the usage I've seen for responsive images so far has
>> concentrated on providing images that change with viewport size rather
>> than DPI.
>
>
> Let me reiterate: it doesn't matter. Those are *separate* issues.
> "Responsive image" is a bad term as it conflates two distinct problems
> (screen density adaptation and physical screen size adaptation) into one.
> It's not either-or choice. Both have valid use-cases.
>
> Support for high DPI displays is an absolute necessity.
>
> Don't look at current or past. Think how web development is going to look
> like in 5, 10 or 20 years.
>
> There will be no low-res displays in the future. Everybody is going to have
> "Retina" displays and everybody will hate that  or  inserts
> crappy pixelated images.
>
> Try browsing the web on the new iPad today. That's how every display is
> going to look like in 10, maybe 20 years. Then DPI negotiation will not be
> an option, it'll be absolute requirement for *every* *single* image.
>
> HTML5 is designed for the next 50-100 years.
>

The last line is exactly why baking in an assumption on the defaults
isn't the right way to go.

I don't disagree that higher DPI resolutions will be come the norm but
then what are we going to do about lower DPI devices, serve them a
higher DPI than needed image and let them work it out rather than
serve them appropriate images?

The Zombie Apocalypse is coming there will be plenty of lower DPI
screens around for a long time...

Cheers

Andy

Re: [whatwg] So if media-queries aren't for determining the media to be used what are they for?

On Thu, 17 May 2012 14:16:24 +0100, Matthew Wilcox  
 wrote:



That particular solution is, to my mind, the most flexible and useful
implementation I've seen, because it's really about breakpoint
management and abstraction - which is what all responsive elements
need in order to work together well and be future-friendly.

It does, no doubt, have some technical considerations and implications
I'm not aware of. I would love to see this worked on more, I don't
think there's much more I can add to it from my authors perspective,
it needs work from an implementor perspective. But as a pattern, it
has a lot of plus points going for it.


I'm trying to figure out how it's going to work in other situations than  
the happy case.



What if you want to provide copy&pasteable code snippet with an adaptive  
image? (like W3C Validator badges)


What if you're creating WYSIWYG editor for CMSes and want to have button  
for inserting adaptive images, but have no access to ?


What if you want to insert a single image with custom/unique breakpoints  
(say an infographic prepared by an agency which used different  
breakpoints) on a website that already has its own breakpoints defined?


I see no nice solution for case when authors put  in  
 — it'd either have re-evaluate and potentially reload images  
(wasted requests) or ignore the meta (annoying gotcha when HTML5 parser  
unexpectedly closes  or when people want to work around lack of  
access to the )


How do you work with URLs you have no control over? e.g. you'd have to  
name your breakpoints "40" and "80" to have adaptive size of gravatar.com  
URLs.


What do you do when you have only two breakpoints for sidebar, but more  
for the main content? (mostly fixed-width sidebar with fluid main column)  
or if your page header adapts to portrait orientation, but images in main  
content only adapt to width?


--
regards, Kornel Lesiński

Re: [whatwg] Bandwidth media queries

Cheers for that feedback Andy - it is indeed a complicated issue with
much more nuance than I think many people (myself included) would have
expected. I still think there's a technical solution there, but as you
say - it's making that solution reliable enough to be worth it. The
problem really is "what is reliable enough"? How accurate does it need
to be.

I can understand that this is in practical terms too complex an issue
to be worth the effort required to get something workable.

And the logic isn't simple either. That said, it's only a matter of
making a decision about what to do. The actual mechanics shouldn't be
hard, it's the decision making that is.

Re: [whatwg] / not needed

2012-05-17 Thread Scott González

On Thu, May 17, 2012 at 7:30 AM, Bjartur Thorlacius wrote:

> How common will it be for modern UAs to render pages to monochrome
> displays using future HTML5 graphics features? How many of the monochrome
> displays that are left will be attached to systems with modern heavy-weight
> software? In fact, the only systems I know of that come close to being
> monochrome are handhelds whose software isn't ever updated, and terminals
> that aren't even used to display bitmaps. So I have to ask, for how long
> will color-depth negotiation be a strong enough use case to warrant this
> feature?
>

I don't think this should just be about device capability. Users with
vision problems may opt-in to high contract mode and you may need to load
different resources based on this.

Re: [whatwg] So if media-queries aren't for determining the media to be used what are they for?

On 17 May 2012 11:05, Kornel Lesiński  wrote:
> On Wed, 16 May 2012 21:11:41 +0100, Matthew Wilcox 
> wrote:
>
>>> What solution do you have in mind that would let you add a 'tv'
>>> breakpoint site-wide for all images that have been prepared for it, without
>>> need to
>>> update code that embeds those images? And is that really saving much
>>> effort?
>>> Wouldn't you have to revisit every page anyway to test the new layout?
>>
>>
>> That following link does it:
>>
>>>
>>> [1]http://www.w3.org/community/respimg/2012/05/13/an-alternative-proposition-to-and-srcset-with-wider-scope/
>
>
> Sorry, you're right. I glanced over URI template and assumed it was for
> media="(case: breakpoint1)" in .
>
> --
> regards, Kornel Lesiński

That particular solution is, to my mind, the most flexible and useful
implementation I've seen, because it's really about breakpoint
management and abstraction - which is what all responsive elements
need in order to work together well and be future-friendly.

It does, no doubt, have some technical considerations and implications
I'm not aware of. I would love to see this worked on more, I don't
think there's much more I can add to it from my authors perspective,
it needs work from an implementor perspective. But as a pattern, it
has a lot of plus points going for it.

Re: [whatwg] "fullscreenchange" event should be delayed to after transition is complete

2012-05-17 Thread Anne van Kesteren

On Thu, May 17, 2012 at 8:06 AM, Chris Pearce  wrote:
> I think it would be best to simply make everything from Step 2 onwards of
> the requestFullscreen() algorithm spec asynchronous. So in the
> requestFullscreen specification, move Step 5 and Step 6 up to be inserted
> before Step 2.
>
> We should do the same with exitFullscreen(), i.e. move Step 6 and Step 7 of
> the exitFullscreen algorithm spec up to be inserted before Step 3.
>
> We should also specify that those state changes happen in synchronous
> sections, to keep the world sane.

I have done that by putting the state changes on the same task that
dispatches the event.

http://dvcs.w3.org/hg/fullscreen/rev/73eda102ccb5

Thanks,


-- 
Anne — Opera Software
http://annevankesteren.nl/
http://www.opera.com/

Re: [whatwg] Defaulting new image solution to 192dpi

2012-05-17 Thread Julian Reschke


On 2012-05-17 14:39, Kornel Lesiński wrote:

On Thu, 17 May 2012 13:20:03 +0100, Julian Reschke
 wrote:


So to future-proof the solution I think:



should be equivalent to:


...


As far as I can tell, making descriptors optional breaks the syntax
(it allows comma both in the URI and as a separator between image
candidates).


Indeed. I'm not sure which solution is the best:


- make descriptors optional only for the last URL (which will work fine
for the case where only the 2x image is supplied)

srcset="a,b" is a single URL

srcset="a, b" is an invalid descriptor for a single URL

srcset="a 1x, b" is two URLs @1x and @2x


Ugly.


- parse trailing comma in URL as a separator and hope no URL scheme
needs it :)

srcset="a,b" is a single URL

srcset="a, b" is two URLs

srcset="a,#, b" is two URLs, first one being "a,#".


Ugly.


- introduce some kind of escaping for commas in the URL part:

srcset="a,b" two URLs

srcset="a\,b" one URL "a,b"

srcset="a\\\, , \,b" two URLs "a\," and ",b"


Likely to be confusing because it's only needed in edge cases.

Or:

- delimit URIs in text content with "<" and ">" as suggested by RFC 3986 
().


- don't use a microsyntax

Best regards, Julian

Re: [whatwg] Defaulting new image solution to 192dpi

2012-05-17 Thread Andy Davies

On 17 May 2012 13:05, Kornel Lesiński  wrote:
> On Thu, 17 May 2012 12:52:47 +0100, Andy Davies  wrote:
>
>>> My suggestion is that the srcset (or ) should assume that images
>>> are "2x" scale by default.
>>
>>
>> Doesn't this makes the assumption that pixel density is the most
>> likely reason for needing the alternative image rather than viewport /
>> image dimensions?
>
>
> Those two cases are orthogonal — one doesn't exclude the other, and I'm not
> claiming that it solves the "art-directed" case.
>

srcset can be used to offer alternatives for higher or lower DPI,
and/or larger or smaller viewports so I'm still not convinced that an
assumption that somehow it should assume that the srcset images are 2x
scale by default really helps.

Much of the usage I've seen for responsive images so far has
concentrated on providing images that change with viewport size rather
than DPI.

Cheers

Andy

Re: [whatwg] Defaulting new image solution to 192dpi

On Thu, 17 May 2012 13:20:03 +0100, Julian Reschke   
wrote:



So to future-proof the solution I think:



should be equivalent to:


...


As far as I can tell, making descriptors optional breaks the syntax (it  
allows comma both in the URI and as a separator between image  
candidates).


Indeed. I'm not sure which solution is the best:


- make descriptors optional only for the last URL (which will work fine  
for the case where only the 2x image is supplied)


srcset="a,b" is a single URL

srcset="a, b" is an invalid descriptor for a single URL

srcset="a 1x, b" is two URLs @1x and @2x


- parse trailing comma in URL as a separator and hope no URL scheme needs  
it :)


srcset="a,b" is a single URL

srcset="a, b" is two URLs

srcset="a,#, b" is two URLs, first one being "a,#".


- introduce some kind of escaping for commas in the URL part:

srcset="a,b" two URLs

srcset="a\,b" one URL "a,b"

srcset="a\\\, , \,b" two URLs "a\," and ",b"

--
regards, Kornel Lesiński

Re: [whatwg] Defaulting new image solution to 192dpi

2012-05-17 Thread Julian Reschke


On 2012-05-17 13:30, Kornel Lesiński wrote:


My suggestion is that the srcset (or ) should assume that
images are "2x" scale by default.


My reasoning behind is:

- we have  for easy embedding of 1x images today, but we don't have
2x  for the future. Having to specify width/height in  all the
time is annoying.

- highdpi displays will become dominant at some point, it's only a
matter of time (they pretty much are already in high-end smartphones,
and are going to appear in laptops next). Bandwidth is also going to be
less of a concern, so it'll be rational and desirable to serve images
for the 2x resolution only (and just rely on 96dpi displays scaling them
down).

Necessity to specify 2x scaling all the time will become a bad default
and a historical quirk (like the DOCTYPE), and a source of annoyance
where accidentally omitted "2x" syntax makes images large and pixelated.


So to future-proof the solution I think:



should be equivalent to:


...


As far as I can tell, making descriptors optional breaks the syntax (it 
allows comma both in the URI and as a separator between image candidates).


(Please read this as argument for making the syntax less brittle)

Best regards, Julian

Re: [whatwg] Defaulting new image solution to 192dpi

On Thu, 17 May 2012 12:52:47 +0100, Andy Davies   
wrote:


My suggestion is that the srcset (or ) should assume that  
images are "2x" scale by default.


Doesn't this makes the assumption that pixel density is the most
likely reason for needing the alternative image rather than viewport /
image dimensions?


Those two cases are orthogonal — one doesn't exclude the other, and I'm  
not claiming that it solves the "art-directed" case.



In fact, even if you have adaptive cropping of the image, you'd still want  
image resolution to match display's DPI, e.g.


obama-f...@2x.jpg vs obama-with-audie...@2x.jpg

and possibly negotiate on both axes at the same time:

obama-f...@2x.jpg vs obama-with-audie...@2x.jpg vs
obama-f...@1x.jpg vs obama-with-audie...@1x.jpg

--
regards, Kornel Lesiński

Re: [whatwg] / not needed

2012-05-17 Thread Bjartur Thorlacius

On Wed, May 16, 2012 at 07:46:54AM +0200, Anselm Hannemann Web Development 
wrote:
> The good thing on the picture element is that we have the possibility to 
> serve other image-crops and with that the meaning could change so we could 
> update the alt-attribute in the tag for every source-element. 
> I do know this is a very special case but valid: An image displayed for a 
> desktop while a monochrome display will get an drawing / shape-image instead. 
> This has the very much same meaning but a different content and has to have a 
> different description in alt-attribute IMO.
> 
How common will it be for modern UAs to render pages to monochrome displays 
using future HTML5 graphics features? How many of the monochrome displays that 
are left will be attached to systems with modern heavy-weight software? In 
fact, the only systems I know of that come close to being monochrome are 
handhelds whose software isn't ever updated, and terminals that aren't even 
used to display bitmaps. So I have to ask, for how long will color-depth 
negotiation be a strong enough use case to warrant this feature?

> Another thing is: We do not have any graphic editor to do such things you 
> have described yet. So you have to write this on your own along with SVG 
> polyfills etc.
> This is a valid solution but won't work for the masses of developers. Please, 
> always think of the millions of HTML-developers who only want to do a normal 
> cool website using responsive images.
> 
A significant portion of the masses will be dependent on new GUI, whichever 
solution we choose. The following CSS SVG wouldn't be created by an image 
manipulation program; it would most likely be generated by CMSs. That's 
equivalent to UAs themselves adapting images to their viewport, aside from 
bandwidth and CPU savings.

> 
> Am 16.05.2012 um 03:23 schrieb Aldrik Dunbar:
> > 
> > http://www.w3.org/2000/svg"; viewBox="0 0 900 1135">
> > A painting by Edvard Munch, commonly known as "the scream".
> >  > svg { background-size: 100% 100%; }
> > @media (min-width:477px) {
> > svg { background-image: 
> > url("https://upload.wikimedia.org/wikipedia/en/f/f4/The_Scream.jpg";); }
> > }
> > @media (max-width:476px) {
> > svg { background-image: 
> > url("https://upload.wikimedia.org/wikipedia/en/thumb/f/f4/The_Scream.jpg/476px-The_Scream.jpg";);
> >  }
> > }
> > ]]>
> >

[whatwg] Defaulting new image solution to 192dpi



My suggestion is that the srcset (or ) should assume that images  
are "2x" scale by default.



My reasoning behind is:

- we have  for easy embedding of 1x images today, but we don't have  
2x  for the future. Having to specify width/height in  all the  
time is annoying.


- highdpi displays will become dominant at some point, it's only a matter  
of time (they pretty much are already in high-end smartphones, and are  
going to appear in laptops next). Bandwidth is also going to be less of a  
concern, so it'll be rational and desirable to serve images for the 2x  
resolution only (and just rely on 96dpi displays scaling them down).


Necessity to specify 2x scaling all the time will become a bad default and  
a historical quirk (like the DOCTYPE), and a source of annoyance where  
accidentally omitted "2x" syntax makes images large and pixelated.



So to future-proof the solution I think:



should be equivalent to:




and I expect that it'll eventually be commonly used this way:



when people stop caring about bandwidth overhead for "low-end" displays.


The srcset still allows 1x scale to be specified, so this change doesn't  
take any functionality away.


--
regards, Kornel Lesiński

Re: [whatwg] Bandwidth media queries

On Wed, 16 May 2012 19:48:04 +0100, Matthew Wilcox  
 wrote:



First off I know that a number of people say this is not possible. I
am not wanting to argue this because I don't have the knowledge to
argue it - but I do want to understand why, and currently I do not.
Please also remember that I can only see this from an authors
perspective as I'm ignorant of the mechanics of how these things work
internally.

The idea is to have something like:





This make an obvious kind of sense to an author.


What would happen in this scenario:

I'm in a cafe with free WiFi browsing on my phone, I have 8mbps bandwidth.  
I open the page and read it (it could be a webapp or a long article that  
stays open for a long time).


I leave the cafe, my bandwidth drops to 1mbps, but I still have the same  
page open.


Should the design change? Should the browser throw away all high-res  
images it has downloaded and re-download them in poor quality?


What when I reload or browse to a next subpage? My browser still has  
high-res images in the cache. Should it now apply low-end design and  
re-download all images in poor quality?


--
regards, Kornel

Re: [whatwg] So if media-queries aren't for determining the media to be used what are they for?

On Wed, 16 May 2012 21:11:41 +0100, Matthew Wilcox  
 wrote:


What solution do you have in mind that would let you add a 'tv'  
breakpoint site-wide for all images that have been prepared for it,  
without need to
update code that embeds those images? And is that really saving much  
effort?

Wouldn't you have to revisit every page anyway to test the new layout?


That following link does it:


[1]http://www.w3.org/community/respimg/2012/05/13/an-alternative-proposition-to-and-srcset-with-wider-scope/


Sorry, you're right. I glanced over URI template and assumed it was for  
media="(case: breakpoint1)" in .


--
regards, Kornel Lesiński

Re: [whatwg] Features for responsive Web design