Re: [whatwg] add html-attribute for "responsive images"

[Anselm Hannemann]

Am 08.02.2012 um 08:23 schrieb Tab Atkins Jr.:

> 2012/2/7 Anselm Hannemann :
>> Am 08.02.2012 um 01:54 schrieb Kornel Lesiński:
>>> On Tue, 07 Feb 2012 14:49:16 -, David Goss  wrote:
>>> 
 I guess I've moved away from similarities with , in that I've
 been thinking of the  as the default content, not the fallback
 content. Going with your angle for a simple example with two sizes:
 
 
  
  
 
>>> 
>>> A new element may be an opportunity to get the "alt" right, i.e. in 
>>> element's body, not flattened in an attribute.
>> 
>> Is there a reason for this? I think this is more confusing than everything 
>> else. And, an alternative text shouldn't have markup.
>> Alternative text should be all for accessibility. What you thinking about 
>> might be the title-attribute. But I'm totally against this approach to do 
>> this inside the element w/o attribute.
>> And I think screenreader won't be happy with that, too? (not sure about 
>> that).
> 
> No, definitely not.  @alt is useful for accessibility, yes, but it's
> also useful even for sighted people if the image is temporarily
> unavailable.  I have found this ability useful in several concrete
> instances in my webdev career.
> 
> Having the ability to do structured fallback would be even better.
> 
> Screenreaders only have a problem insofar as they don't currently have
> the ability to recognize such markup, because it doesn't exist yet.
> There's nothing theoretically difficult about it, though.

Thanks for clarifying. Then it would be okay to use this style. 

I only have the problem with this "unordered" markup.
In that case we don't have any wrapper for the alt-text and it would just 
follow as plain on the source-elements.
We always should have wrappers in my mind, we have this for noscript etc, too.
So why not adding my alternative text here to the spec?




alt text here


But in that cases we're now sure we don't want the solution to serve different 
contents, right?
I mean if we, we should use an attributed version as we then need different alt 
and title content, too.
And from discussion before that was only two people saying we don't need that.

I'd love to have *ability* (just for future use-cases which might come up and I 
already would have some for tablet-devices and smartphones) to add different 
media.
e.g. we could offer a cropped image for smartphone users which has another 
context (maybe missing important parts of the img due to crop but it's better 
for smartphone usage and still has it's right to be there as an diff.image).
Would love to hear what you all think about that? 

-Anselm

Re: [whatwg] add html-attribute for "responsive images"

[Tab Atkins Jr.]

2012/2/7 Anselm Hannemann :
> Am 08.02.2012 um 01:54 schrieb Kornel Lesiński:
>> On Tue, 07 Feb 2012 14:49:16 -, David Goss  wrote:
>>
>>> I guess I've moved away from similarities with , in that I've
>>> been thinking of the  as the default content, not the fallback
>>> content. Going with your angle for a simple example with two sizes:
>>>
>>> 
>>>  
>>>  
>>> 
>>
>> A new element may be an opportunity to get the "alt" right, i.e. in 
>> element's body, not flattened in an attribute.
>
> Is there a reason for this? I think this is more confusing than everything 
> else. And, an alternative text shouldn't have markup.
> Alternative text should be all for accessibility. What you thinking about 
> might be the title-attribute. But I'm totally against this approach to do 
> this inside the element w/o attribute.
> And I think screenreader won't be happy with that, too? (not sure about that).

No, definitely not.  @alt is useful for accessibility, yes, but it's
also useful even for sighted people if the image is temporarily
unavailable.  I have found this ability useful in several concrete
instances in my webdev career.

Having the ability to do structured fallback would be even better.

Screenreaders only have a problem insofar as they don't currently have
the ability to recognize such markup, because it doesn't exist yet.
There's nothing theoretically difficult about it, though.

~TJ

Re: [whatwg] add html-attribute for "responsive images"

[Anselm Hannemann]

Am 08.02.2012 um 01:54 schrieb Kornel Lesiński:

> On Tue, 07 Feb 2012 14:49:16 -, David Goss  wrote:
> 
>> I guess I've moved away from similarities with , in that I've
>> been thinking of the  as the default content, not the fallback
>> content. Going with your angle for a simple example with two sizes:
>> 
>> 
>>  
>>  
>> 
> 
> A new element may be an opportunity to get the "alt" right, i.e. in element's 
> body, not flattened in an attribute.

Is there a reason for this? I think this is more confusing than everything 
else. And, an alternative text shouldn't have markup.
Alternative text should be all for accessibility. What you thinking about might 
be the title-attribute. But I'm totally against this approach to do this inside 
the element w/o attribute.
And I think screenreader won't be happy with that, too? (not sure about that).

> 
>  
>  
> 
>  
> 
>  alternative text
> 
> 
> 
> For DPI/filesize selection I'd prefer something simpler:
> 
>  
>  alternative text
> 
> 
> as it's going to be very hard to write a media query that takes into account 
> various screen sizes, DPI and bandwidth/metering at the same time.

This is similar to my approach using the common img-tag. In that case we don't 
need a new element.
But as you've said many people (also here) find it a bit hard to write. Imagine 
using 6 different image sizes in that case…
You can read arguments some mails before on my approach.

> When browser has a high-quality image the cached already, but media query for 
> "network-connection: gprs" matches, it would be shame to force it to switch 
> to a lousy image.
> 
> -- 
> regards, Kornel Lesiński
-Anselm

Re: [whatwg] Should events be paused on detached iframes?

[Boris Zbarsky]

On 2/7/12 7:16 PM, Ian Hickson wrote:

All of the above seem consistent with what the spec requires.

Firefox actually seems to have a slight bug, which is that the event loop
keeps pumping in the original page, but that seems like a separate issue.

Here's the test case you describe above:

http://damowmow.com/playground/tests/alert/001.html


OK, then I don't understand something.  You said:

  It should put it up in the context of the top-level browsing context
  of the script that led to that point (the "first script").  This is
  the same as if someone in one tab calls another tab's script and that
  script calls alert().

I assume you meant "entry script", but maybe that was a bad assumption? 
 There is no "first script" anywhere in the spec.


In any case, in my testcase the "entry script" is the one running in 
test1.html, but the alert is being associated with test2.html.  In 
general, I would expect that alerts are associated with the window that 
was the |this| for the alert call


-Boris

Re: [whatwg] add html-attribute for "responsive images"

[Kornel Lesiński]

On Tue, 07 Feb 2012 14:49:16 -, David Goss  wrote:


I guess I've moved away from similarities with , in that I've
been thinking of the  as the default content, not the fallback
content. Going with your angle for a simple example with two sizes:


  
  



A new element may be an opportunity to get the "alt" right, i.e. in  
element's body, not flattened in an attribute.



  
  

  

  alternative text



For DPI/filesize selection I'd prefer something simpler:

 

  alternative text


as it's going to be very hard to write a media query that takes into  
account various screen sizes, DPI and bandwidth/metering at the same time.


When browser has a high-quality image the cached already, but media query  
for "network-connection: gprs" matches, it would be shame to force it to  
switch to a lousy image.


--
regards, Kornel Lesiński

Re: [whatwg] Decimal comma in numeric input

[Ian Hickson]

On Thu, 19 Jan 2012, John Tamplin wrote:
> 
> [...] a user types "1,575" in a field.  Is that interpreted as a value 
> between 1 and 2 or between 1000 and 2000? [...]

That's entirely up to the UA.


On Thu, 19 Jan 2012, Bronislav Klu�~Mka wrote:
> 
> This should depend on selected locale, is coma thousands or decimal 
> separator? Browser should follow such settings and display value 
> accordingly, but value MUST be sent to server according to 1 set of 
> rules, regardless of anything else (e.g. no thousands separator and full 
> stop as decimal separator). No browser locale, no server locale... one 
> set of rules. Consider JavaScript here... regardless of displayed value, 
> you always get Number type out of it (not string like 15.123,55 but 
> 15123.55) So it is just display here, but spec should explain the 
> difference between display value and underlying data.

Correct.


On Fri, 20 Jan 2012, Jukka K. Korpela wrote:
> 2012-01-20 1:19, David Singer wrote:
> > 
> > What the user enters and sees on screen is a presentational/locale 
> > issue
> 
> Which one?

That's defined by the UA. (The spec has some suggestions.)


On Fri, 20 Jan 2012, Cameron Heavon-Jones wrote:
> 
> The lang attribute is the structural declaration of the content's 
> localization, be it prose or data values.

Technically it just sets the language, not the localisation. I expect we 
will in due course add an attribute to explicitly set the locale of the 
content in the page. How it's rendered would then be controlled by new 
features in CSS (e.g. the page locale could be "British", and the 
presentation could be "American", which would mean dates would have their 
day and month fields flipped over). Similarly, the presentation layer 
ultimately controls the widgets, including how they work and what input 
formats they expect, e.g. through XBL or whatever replaces it.

This is all pie in the sky, though, it doesn't exist today.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] title/meta elements outside of

[Ian Hickson]

On Thu, 19 Jan 2012, Michael Day wrote:
> 
> Currently the spec seems to indicate that title and meta elements found 
> in the body will stay where they are and not be added to the head.
> 
> However, if these elements occur after the head and before the body then 
> they will be added to the head.
> 
> Is this intentional?
> 
> Sample document #1:
> 
> 
> 
> 
> 
> This will stay in the body
> 
> Sample document #2:
> 
> 
> 
> 
> This will be moved to the head
> 
> Sample document #3:
> 
> 
> 
> abc
> Now we are in the body, where this will stay
> 
> What is the reason why title/meta elements are not always moved to the 
> head, regardless of where they appear?

On Thu, 19 Jan 2012, Henri Sivonen wrote:
> 
> They didn't need to be for compatibility, so we went with less magic. 
> Also, being able to use  and  as descendants of  is 
> useful for Microdata and RDFa Lite without having to mint new void 
> elements.

Henri is correct.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] RWD Heaven: if browsers reported device capabilities in a request header

[Kornel Lesiński]

On Tue, 07 Feb 2012 21:17:22 -, divya manian   
wrote:



This is the info I would love to see any time for my app to make the
kind of decision it should:
* connection speed: so I know how fast my resources can load, how  
quickly.

* bandwidth caps: so I know I shouldn't be sending HD images.
* battery time: network requests are a drain on battery life, if I
know before hand, I can make sure the user gets information in time.


I understand you'd like to provide most appropriate images, but why do  
*you* have to exactly decide which is used when? Everybody is going to  
make basically same decisions: if network is slow, use smaller image. If  
network is fast and device is high-DPI, use larger image, etc.


So instead of requiring every server to reinvent essentially the same  
logic, why not have it in the browser? Browsers can query all the details  
of the system without any privacy risks or network overheads.


You could just say "I've got these image sizes available, choose which one  
suits you best", and browser would pick one that makes most sense. You  
(and every other web developer) wouldn't have to write and maintain code  
for computation of bandwidth/latency/battery/screen size/density/zoom/cpu  
speed/memory tradeoffs. With so many variables I'm afraid that average  
developer wouldn't make better choices than mobile browsers themselves can.



* notification of change of any of these: so I can provide scaled up
experiences when these alter.


With HTTP that would require browser to re-send requests for the page and  
assets just in case server would make a different decision, and if  
difference wasn't big enough to change server's decision, then energy to  
wake up cell radio and bandwidth to send requests would be wasted (e.g.  
cost of keeping server informed about often-changing zoom level could  
easily outweigh savings from reduced images).


OTOH if client was given information on what variants of resources are  
available, then it could cheaply re-check conditions when cell radio is  
off and only connect when necessary and only request files that have  
changed substantially.


--
regards, Kornel Lesiński

Re: [whatwg] RWD Heaven: if browsers reported device capabilities in a request header

[Boris Zbarsky]

On 2/7/12 5:06 PM, Matthew Wilcox wrote:

I agree about this. But realise that if we take your zoom use case to
it's logical conclusion, we'd need to supply images at an infinite
resolution. Which is patently absurd. With visual media, it is
expected, and the only practical thing, to have pixelation at zooms
higher than one CSS pixel.


I don't think that's expected if your initial zoom level maps a single 
CSS px to multiple device pixels.  If my device runs at 300dpi by 
default, I should be able to zoom in 3x or so before any pixelation 
happens, I'd hope.


-Boris

Re: [whatwg] RWD Heaven: if browsers reported device capabilities in a request header

[Charles Pritchard]

On 2/7/2012 2:06 PM, Matthew Wilcox wrote:

And, screen size is useful when understood to mean "CSS Pixels".
Because that's what a browser renders. If a device has a screen 1900px
CSS px wide, you know you never need send anything larger.

It's getting in the way, and it's certainly been a strong topic.

I know that if a screen is 480px wide that I know nothing. I spent a lot of 
time on work-arounds for DPI issues on mobile and desktop.

I agree about this. But realise that if we take your zoom use case to
it's logical conclusion, we'd need to supply images at an infinite
resolution. Which is patently absurd. With visual media, it is
expected, and the only practical thing, to have pixelation at zooms
higher than one CSS pixel.


The logical conclusion is that images are supplied at the highest 
resolution the author sees fit.

It's common to make that a 2x CSS pixel ratio.

Works well for density on items like the iPhone.



Unless you go out and disable zoom, the user can zoom into the image. That 
applies to mobile for sure. I hate it when I can't zoom in on some sites. 
Google news is a prime example.

I would never disable zoom, it's completely irresponsible. But so is
trying to supply an image that stands up to zoom. It's irresponsible
to every other user who doesn't zoom.


Well, I can script things, with javascript. But sure, in CSS it's not 
nice to waste someone's bandwidth.
Nor is it nice to cripple their computer by having it download dozens of 
huge images.


Thumbnailing is really what happens here. Tiling and thumbnailing. 
Common practices.


You're aiming too low on your mobile thumbnails. It's great on a 
resource-constrained pipe, or for a phone that has a 1:1 dpi ratio,

it's not nearly as nice on an iPhone sitting on an unmetered 3G connection.



But I'll try to bend my mind around it, now that we're over the initial hurdle 
about screen size.
Sure, if you want to have something like this, it's not the end of the world:

Re: [whatwg] RWD Heaven: if browsers reported device capabilities in a request header

[Matthew Wilcox]

> > > And, screen size is useful when understood to mean "CSS Pixels".
> > > Because that's what a browser renders. If a device has a screen 1900px
> > > CSS px wide, you know you never need send anything larger.

> > It's getting in the way, and it's certainly been a strong topic.

> I know that if a screen is 480px wide that I know nothing. I spent a lot of 
> time on work-arounds for DPI issues on mobile and desktop.

I agree about this. But realise that if we take your zoom use case to
it's logical conclusion, we'd need to supply images at an infinite
resolution. Which is patently absurd. With visual media, it is
expected, and the only practical thing, to have pixelation at zooms
higher than one CSS pixel.

> Unless you go out and disable zoom, the user can zoom into the image. That 
> applies to mobile for sure. I hate it when I can't zoom in on some sites. 
> Google news is a prime example.

I would never disable zoom, it's completely irresponsible. But so is
trying to supply an image that stands up to zoom. It's irresponsible
to every other user who doesn't zoom.

> It also applies to desktop. There are many instances of sites that have a 
> downsampled image, which you can then click to get a higher resolution 
> version.
> It'd be a nasty thing to have to change my system resolution settings because 
> someone thought it would be funny to serve me up small versions of images 
> based on my browser zoom or screen resolution.

Agreed. So don't report the browser zoom pixel size, report the screen
size at normal zoom.

> I'm all for exposing data. I had a very public tantrum about 
> devicePixelRatio; Microsoft exposes it directly,
> WebKit exposes it inadvertently, Mozilla exposes it via CSS selectors 
> (needing about 15 lines of css).
> While I am for exposing data, I'm just not seeing this idea of exposing "all" 
> css media attributes.

Same here, I'm open to figuring out what ones would actually be
useful. It's just my position that screen size is in fact critical -
but not necesarily for saving bandwidth as an end goal.

> But I'll try to bend my mind around it, now that we're over the initial 
> hurdle about screen size.
> Sure, if you want to have something like this, it's not the end of the world:
> 

Re: [whatwg] RWD Heaven: if browsers reported device capabilities in a request header

[Boris Zbarsky]

On 2/7/12 3:59 PM, Matthew Wilcox wrote:

Fair enough. This then becomes a cost/benefit issue. But there's nothing to 
stop this working if the user's default is an opt out and a prompt is given to 
allow. In exactly the same way that things currently work for geo-location 
data. Right?


Maybe.  That's pretty intrusive UI...  and I'm not a UI designer.


Just wait until UAs start shipping with JS disabled for certain domains by 
default, just like they're already shipping with other capabilities turned on 
or off with certain domains by default.


I browse with NoScript and regularly come across people that haven't coded 
site's responsibly (it drives me nuts). While I applaud this notion because 
it'll bring more attention to the issue - i highly doubt it'll have any impact 
on the larger spectrum of sites. JS is now relied on and if certain UA's 
deliver a broken web-page to users, the users are just going to blame the 
software, not the website. Why? Because the site works in every *other* 
browser, including their old ones...


I did say "certain domains".  Think "script disabled for Facebook Like 
buttons by default".  ;)



They should be. But at the same time a hell of a lot of people have read that 
FaceBook watches their every move, and yet happily continue to use it. Users 
don't weigh the issue in the same way we do.


A lot of them don't true.


Agreed! It's still my inclination to default to more permissive things though. 
If people build poor sites, users stop going, the site fails, and either the 
author learns (I hope) or switches to a job with less requirement on skill 
level. It's like in business - if you're not providing a decent product, you 
don't survive. The government doesn't just disallow people from making rubbish 
with the resources they have.


A problem comes when "too big to fail" sites are coded somewhat 
incompetently.  Things like Google's web properties, Yahoo, Microsoft, 
eBay.  Heck, CNN (which is coded _very_ incompetently, imo).  For sites 
like that, the user is more likely to switch browsers or even devices 
than to use a different site...  Sometimes there is no "different site": 
if MSDN breaks in your browser, what alternate documentation repository 
will you use, exactly?  If you use gmail and it breaks in your browser, 
then what?


Plenty of people have been producing websites of  varying quality 
... for a decade or more and surviving just fine.



In that case I completely agree. But the answer is educate them to test the 
right thing.


This is a _huge_ undertaking.  We (Mozilla) don't have the manpower for 
it; we've done evangelism and education in the past, and it's _very_ 
labor-intensive.  Opera has literally dozens of people working full-time 
on this sort of thing and they say they don't really have the manpower 
for it either.


The real answer needs to be to build things that are easier to use right 
than to use wrong, because developers will almost always choose the path 
of least resistance.  And I can't blame them.



Ooo, interesting. OK, doesn't SPDY allow pushing content and open connections? 
Can't we hijack that? And, given that any and all new info is triggered by a 
request of some sort, why wouldn't the browser send updated headers with those 
requests? (Again, may be a daft question, I am not familiar with how this stuff 
works on any real level of detail)


I'm not familiar enough with SPDY to comment intelligently.


Interesting example. OK, how could this be fixed? Could hooks not be provided 
for JS so that the site author could watch for these changes and re-request as 
needed?


That might be the right way to go, yeah...  Now we're getting somewhere.  ;)

-Boris

Re: [whatwg] RWD Heaven: if browsers reported device capabilities in a request header

[Charles Pritchard]

On 2/7/2012 1:21 PM, Matthew Wilcox wrote:

Whether screen-size is a good idea or not comes after.

And, screen size is useful when understood to mean "CSS Pixels".
Because that's what a browser renders. If a device has a screen 1900px
CSS px wide, you know you never need send anything larger.


It's getting in the way, and it's certainly been a strong topic.

I know that if a screen is 480px wide that I know nothing. I spent a lot 
of time on work-arounds for DPI issues on mobile and desktop.


Unless you go out and disable zoom, the user can zoom into the image. 
That applies to mobile for sure. I hate it when I can't zoom in on some 
sites. Google news is a prime example.


It also applies to desktop. There are many instances of sites that have 
a downsampled image, which you can then click to get a higher resolution 
version.


It'd be a nasty thing to have to change my system resolution settings 
because someone thought it would be funny to serve me up small versions 
of images based on my browser zoom or screen resolution.


I'm all for exposing data. I had a very public tantrum about 
devicePixelRatio; Microsoft exposes it directly,
WebKit exposes it inadvertently, Mozilla exposes it via CSS selectors 
(needing about 15 lines of css).



While I am for exposing data, I'm just not seeing this idea of exposing 
"all" css media attributes.
But I'll try to bend my mind around it, now that we're over the initial 
hurdle about screen size.


Sure, if you want to have something like this, it's not the end of the 
world:

Re: [whatwg] RWD Heaven: if browsers reported device capabilities in a request header

[Tim Kadlec]

>
> It's only an example. My point is that the server ought to be able to
> ask the client for data about *any given property* and if the client
> is capable it should send a header back. Which allows the server to
> then do whatever it needs with the information.


This approach makes sense to me as well. Client-side feature detection is
simply not capable of solving everything.

Something like this would also be very future friendly. We don't know what
properties are going to be important a few years down the line. If this
model is implemented carefully, it would be easy to add new properties to
the mix.

- Tim

On Tue, Feb 7, 2012 at 3:21 PM, Matthew Wilcox wrote:

> I think somehow lines are getting crossed and misunderstandings are
> happening.
>
> For what it's worth, everyone seems to be getting hung up on screen size.
>
> It's only an example. My point is that the server ought to be able to
> ask the client for data about *any given property* and if the client
> is capable it should send a header back. Which allows the server to
> then do whatever it needs with the information. Screen size is one
> example. Bandwidth is another.
>
> It's the *communication of capabilities* that interests me at this
> point, The allowing of an interrogation of possibliities and adaptive
> responses.
>
> Whether screen-size is a good idea or not comes after.
>
> And, screen size is useful when understood to mean "CSS Pixels".
> Because that's what a browser renders. If a device has a screen 1900px
> CSS px wide, you know you never need send anything larger.
>
> On 7 February 2012 20:24, Charles Pritchard  wrote:
> > On 2/7/2012 11:52 AM, Matthew Wilcox wrote:
> >>
> >> On 7 February 2012 17:59, Boris Zbarsky  wrote:
> >>
> >>> On 2/7/12 12:32 PM, Matthew Wilcox wrote:
> >>>  In what circumstances might this cause breakages?
> >>> Whenever the server developer makes dumb assumptions.  Which they do
> all
> >>> the time.  _All_ the time.
> >>>
> >>>
> >>>  And how could it possibly lock out any devices?
> >>> See my earlier example of a "desktop-class" touchscreen system that's
> >>> shipping right now.  Every single concrete proposal I've seen so far in
> >>> this thread would lock it out of actually using its touch capabilities
> on
> >>> sites that would support such capabilities fine on other devices.
> >>
> >>
> >> I don't think I have enough knowledge of the case in point to argue
> either
> >> way, but I'm confused how this would be the case at the moment.
> >
> >
> >
> > We already see some frustrating lockout with websites that detect mobile
> > user agents. They forward the agent to their special mobile website,
> where
> > they will often popup an alert ("Please download our APP!!!") every
> single
> > time you visit the page. Their mobile site is frequently crippled,
> limited
> > to only a few options, and the mobile browser is often capable of viewing
> > the full desktop site at a reasonable screen width. Now, as sites mature,
> > they have figured out to include a "Desktop Version" toggle, which is a
> big
> > help. It's still frustrating that there are a few steps in between.
> >
> > These sites make an assumption, that the screen size has something to do
> > with device capability. The screen size has to do with how much
> information
> > the viewer has decided to consume at one time.
> >
> > I'm frequently using browser zoom (though I use OS zoom as well), and I
> > don't need to be forwarded to the "mobile site" while I'm browsing on my
> > desktop just because I'm not wearing my glasses. That said, I do try to
> work
> > with my applications so that the "mobile" interface is an interface that
> I
> > would like to use on my desktop when I'm zoomed in. That middle ground
> works
> > well for me.
> >
> >
> >
> >>> Now obviously it's also good for the web in various ways, if people
> 
> use the information "correctly" and such.  My faith in this is
> somewhat tarnished by the fact that every concrete proposal for
> using it that I've seen seems to be broken by design, which means
> that chances of anyone using it "correctly" are vanishingly small.
> 
>  Can you tell us how they're broken so we can fix it?
> 
> >>> Did you read my earlier mails with examples of devices that are
> shipping
> >>> right now that violate the various assumptions people trying to create
> >>> these "device class" bins are making?
> >>
> >>
> >> I don't believe we should ever use "classes" of device. We've been down
> >> that route, it's a fail in and of itself. We should be using actual
> data,
> >> not assumed data based on some other data.
> >
> >
> > We have abstract means of accessibility. WCAG2 explores that.
> >
> > We have classes of how data is accessed. It should be accessible from a
> > keyboard only device.
> > With touch screens, the world has been exploring more, the concept of
> > accessible via pointer only (though virtual keyboards help).
> >
> > Keep in min

Re: [whatwg] RWD Heaven: if browsers reported device capabilities in a request header

[Matthew Wilcox]

Yes, you're getting the point I'm trying to make :D

However, there most certainly IS a use case for screen size. The
designers would kill me if I served up images that had to be
up-sampled to fit the device width. And I'd kill them if I had to send
an image 6 times larger than needed just to cater for a possibliity
that the browser may end up six times larger than it is now.

It's not purely about information adaption, there is visual design
consideration that is as paramount as any other argument. If a website
looks janky, the client (as in the web development agency's client)
isn't going to pay for it.



On 7 February 2012 21:19, Charles Pritchard  wrote:
> On 2/7/2012 1:14 PM, Matthew Wilcox wrote:
>>>
>>> >  Also, I am writing this on a laptop via a throttled mobile connection.
>>
>> It'd be nice if sites had the capability to adapt to that throttle
>> then wouldn't it...
>
>
> As I read through this thread -- all of these use cases are about bandwidth.
>
> a) Images are too big.
> b) Too many javascript files.
> c) Too much html content.
>
> The proposed fix:
> a) Send a display size header, have the server do magick.
>
> That doesn't seem to be the right approach.
>
> Let me know if I've got that right / wrong.
>
> I'm fine with sending a bandwidth-request header.
> Something to say: hey you, I'm on a metered connection, don't waste my time.
> Or just, hey, this connection is slow, give me a hand here.
>
> That one directly addresses the issue.
>
> On the server-side, I can decide if I want to serve downsampled images,
> lesser content
> or otherwise repackage my javascript.
>
> Nothing to do with viewport sizes.
>
> -Charles
>
>

Re: [whatwg] RWD Heaven: if browsers reported device capabilities in a request header

[Matthew Wilcox]

I think somehow lines are getting crossed and misunderstandings are happening.

For what it's worth, everyone seems to be getting hung up on screen size.

It's only an example. My point is that the server ought to be able to
ask the client for data about *any given property* and if the client
is capable it should send a header back. Which allows the server to
then do whatever it needs with the information. Screen size is one
example. Bandwidth is another.

It's the *communication of capabilities* that interests me at this
point, The allowing of an interrogation of possibliities and adaptive
responses.

Whether screen-size is a good idea or not comes after.

And, screen size is useful when understood to mean "CSS Pixels".
Because that's what a browser renders. If a device has a screen 1900px
CSS px wide, you know you never need send anything larger.

On 7 February 2012 20:24, Charles Pritchard  wrote:
> On 2/7/2012 11:52 AM, Matthew Wilcox wrote:
>>
>> On 7 February 2012 17:59, Boris Zbarsky  wrote:
>>
>>> On 2/7/12 12:32 PM, Matthew Wilcox wrote:
>>>  In what circumstances might this cause breakages?
>>> Whenever the server developer makes dumb assumptions.  Which they do all
>>> the time.  _All_ the time.
>>>
>>>
>>>  And how could it possibly lock out any devices?
>>> See my earlier example of a "desktop-class" touchscreen system that's
>>> shipping right now.  Every single concrete proposal I've seen so far in
>>> this thread would lock it out of actually using its touch capabilities on
>>> sites that would support such capabilities fine on other devices.
>>
>>
>> I don't think I have enough knowledge of the case in point to argue either
>> way, but I'm confused how this would be the case at the moment.
>
>
>
> We already see some frustrating lockout with websites that detect mobile
> user agents. They forward the agent to their special mobile website, where
> they will often popup an alert ("Please download our APP!!!") every single
> time you visit the page. Their mobile site is frequently crippled, limited
> to only a few options, and the mobile browser is often capable of viewing
> the full desktop site at a reasonable screen width. Now, as sites mature,
> they have figured out to include a "Desktop Version" toggle, which is a big
> help. It's still frustrating that there are a few steps in between.
>
> These sites make an assumption, that the screen size has something to do
> with device capability. The screen size has to do with how much information
> the viewer has decided to consume at one time.
>
> I'm frequently using browser zoom (though I use OS zoom as well), and I
> don't need to be forwarded to the "mobile site" while I'm browsing on my
> desktop just because I'm not wearing my glasses. That said, I do try to work
> with my applications so that the "mobile" interface is an interface that I
> would like to use on my desktop when I'm zoomed in. That middle ground works
> well for me.
>
>
>
>>>     Now obviously it's also good for the web in various ways, if people

    use the information "correctly" and such.  My faith in this is
    somewhat tarnished by the fact that every concrete proposal for
    using it that I've seen seems to be broken by design, which means
    that chances of anyone using it "correctly" are vanishingly small.

 Can you tell us how they're broken so we can fix it?

>>> Did you read my earlier mails with examples of devices that are shipping
>>> right now that violate the various assumptions people trying to create
>>> these "device class" bins are making?
>>
>>
>> I don't believe we should ever use "classes" of device. We've been down
>> that route, it's a fail in and of itself. We should be using actual data,
>> not assumed data based on some other data.
>
>
> We have abstract means of accessibility. WCAG2 explores that.
>
> We have classes of how data is accessed. It should be accessible from a
> keyboard only device.
> With touch screens, the world has been exploring more, the concept of
> accessible via pointer only (though virtual keyboards help).
>
> Keep in mind that keyboard and pointer are also two abstractions, not
> physical objects.
>
> There's a third class of accessibility, and that's programmatic access.
> Ensuring that the DOM has sufficient information that third-party
> software can use. This is frequently used for eyes-free interfaces, but it's
> handy for many other targets.
>
> There's no assumption of a screen being in place, nor an assumption of any
> particular physical interface.
>
>
>>>  Especially if the current solution

 is to connect to some massive device database to query potential points
 of reference and then act accordingly.

>>> Which is just as broken, yes.  We've run into problems with the breakage
>>> of this database a good bit at Mozilla.
>>
>>
>> Cool so we agree databases are a bad solution and we should aim for better
>> :)
>
>
> Databases are a practical solution for specia

Re: [whatwg] RWD Heaven: if browsers reported device capabilities in a request header

[Charles Pritchard]

On 2/7/2012 1:14 PM, Matthew Wilcox wrote:

>  Also, I am writing this on a laptop via a throttled mobile connection.

It'd be nice if sites had the capability to adapt to that throttle
then wouldn't it...


As I read through this thread -- all of these use cases are about bandwidth.

a) Images are too big.
b) Too many javascript files.
c) Too much html content.

The proposed fix:
a) Send a display size header, have the server do magick.

That doesn't seem to be the right approach.

Let me know if I've got that right / wrong.

I'm fine with sending a bandwidth-request header.
Something to say: hey you, I'm on a metered connection, don't waste my time.
Or just, hey, this connection is slow, give me a hand here.

That one directly addresses the issue.

On the server-side, I can decide if I want to serve downsampled images, 
lesser content

or otherwise repackage my javascript.

Nothing to do with viewport sizes.

-Charles

Re: [whatwg] RWD Heaven: if browsers reported device capabilities in a request header

[divya manian]

This is the info I would love to see any time for my app to make the
kind of decision it should:
* connection speed: so I know how fast my resources can load, how quickly.
* bandwidth caps: so I know I shouldn't be sending HD images.
* battery time: network requests are a drain on battery life, if I
know before hand, I can make sure the user gets information in time.
* notification of change of any of these: so I can provide scaled up
experiences when these alter.

Feature testing would be sufficient for me to test support for various
standards, and ideally that should be something like this
http://dev.w3.org/csswg/css3-conditional/ for all open web
technologies. And based on my knowledge of the above I can provide a
decent experience for the user.

Screen resolution is something users have to work with. This is how it
has been on desktop and I suppose how this should work on mobile
rather than trying to detect it server side.

But yeah it seems like none of what I want can ever be provided
without a significant change in how ISPs, mobile data providers, etc
work. :

Re: [whatwg] RWD Heaven: if browsers reported device capabilities in a request header

[Matthew Wilcox]

On 7 February 2012 20:05, Nils Dagsson Moskopp
 wrote:
> Matthew Wilcox  schrieb am Tue, 7 Feb 2012
> 19:38:31 +:
>
>> Can we not turn this into an option in the same way browsers handle
>> requests to get the users location? With configuration too?
>>
>> Allow browsers to see my:
>>
>> screen size
>
> That would be yet another way to push “This web site was designed for
> 800x600, 16 colors, IE 5.5 or later.” – only with the added “feature”
> of “sucks to be you, get a bigger screen, this content will not
> display”. UA sniffing, now even worse! Oh, I would certainly be mad.

I tire of this viewpoint.
Of course it can be used that way. There isn't a technology in
existance that can't be mis-used. Does that mean it's a bad idea to
try to solve problems with new technology?

>
>> connection speed
>
> This is an interesting case – but today well handled by minimal sites.
> OkCupid, Twitter, Wikipedia all have well-known minimal alternatives
> that can be used when on a bandwith-constrained connection. Often, they
> are arguably better (not full of ads etc.).

Handled how? "By minimal sites" is not an answer, that's a design
approach consisting of "bring everything down to the lowest common
denominator" if you use it for one site, or an extension of "just
throw up a plain-text version" if you supply it as a separate URL.

The point of responsive designs is to allow one URL to work well on
multiple un-known devices whose characteristics vary enormously. The
screen can have a ten fold difference in width and a greater
difference in processing power and network connectivity. One of the
main issue in this arena is how to adapt images, because you don't
want to send big images to small devices. So, how do you see this
particular problem as already solved? Please - myself and a few dozen
other people who've been at this for the last year would like to know
- how do we serve a small image to small devices and a big one to
large devices? Reliably? Without the flaws of all the existing
attempted solutions, which are well documented elsewhere?

http://adaptive-images.com
http://filamentgroup.com/lab/responsive_images_experimenting_with_context_aware_image_sizing/
http://www.alistapart.com/articles/responsive-images-how-they-almost-worked-and-what-we-need/
etc

PS: UA sniffing and dedicated 'mobile' site's are expressly not the answer.

> Since that type of request is not narrowly constrained to specific
> circumstances (e.g. location-based services), there is a possibility
> for this to become very annoying.
>
> Externalizing the inability to provide content that works across
> multiple devices is a very easy cop-out for developers. I for one
> advocate control at the UA level (like with CSS media queries) so there
> won't be yet another UA string nightmare.

I would hate another UA string nightmare too. Hence why I want
headers. Explicit, direct, non-assumed reporting of actual, current
properties. Without guessing.

> Also, I am writing this on a laptop via a throttled mobile connection.

It'd be nice if sites had the capability to adapt to that throttle
then wouldn't it...

> --
> Nils Dagsson Moskopp // erlehmann
> 

Re: [whatwg] RWD Heaven: if browsers reported device capabilities in a request header

[Matthew Wilcox]

On 7 Feb 2012, at 20:19, Boris Zbarsky wrote:

On 2/7/12 2:52 PM, Matthew Wilcox wrote:
   Reporting more information about the user's hardware and software to
   the server allows better fingerprinting and hence tracking.  See
   
https://www.eff.org/deeplinks/__2010/01/primer-information-__theory-and-privacy
   
   and similar resources for details.


Agreed. But this already happens.

And browsers are working on mitigating the ways it already happens.
Which means they're reluctant to add new fingerprinting surface.

Fair enough. This then becomes a cost/benefit issue. But there's
nothing to stop this working if the user's default is an opt out and a
prompt is given to allow. In exactly the same way that things
currently work for geo-location data. Right?

Your point is the user must be able to
opt in and out, as they might be turning off JS (which, frankly, how
many non-webnerd people do?)

Just wait until UAs start shipping with JS disabled for certain
domains by default, just like they're already shipping with other
capabilities turned on or off with certain domains by default.

I browse with NoScript and regularly come across people that haven't
coded site's responsibly (it drives me nuts). While I applaud this
notion because it'll bring more attention to the issue - i highly
doubt it'll have any impact on the larger spectrum of sites. JS is now
relied on and if certain UA's deliver a broken web-page to users, the
users are just going to blame the software, not the website. Why?
Because the site works in every *other* browser, including their old
ones...

So you're saying the problem isn't the
tech but the user control? Can we not give that to them?

I'm saying that the _default_ behavior should ideally be as
user-friendly as possible.  That includes user privacy concerns.

Absolutely agree. I'm all for this being disabled by default and
opted-in as servers request. Or opted in via a user setting in the UA.

 There can be additional knobs to enable more privacy features, of
course, but a lot of what goes on in the privacy space on the web
right now basically depends on user ignorance about the information
websites are getting out of them.  When I actually describe the
underlying technology to non-technical users, they're almost uniformly
horrified…

They should be. But at the same time a hell of a lot of people have
read that FaceBook watches their every move, and yet happily continue
to use it. Users don't weigh the issue in the same way we do.

Point taken. Though it irks me no end that various technologies get
canned because of how inept people can mis-use them. I'd rather see
those inept people shoot themselves in the foot and pay the price.

The problem is that the price ends up being paid by someone else.
Classic example of externalities...  If we could make people fully
internalize the consequences of their own incompetence, a lot of
things would ure be easier!

Agreed! It's still my inclination to default to more permissive things
though. If people build poor sites, users stop going, the site fails,
and either the author learns (I hope) or switches to a job with less
requirement on skill level. It's like in business - if you're not
providing a decent product, you don't survive. The government doesn't
just disallow people from making rubbish with the resources they have.

   Did you read my earlier mails with examples of devices that are
   shipping right now that violate the various assumptions people
   trying to create these "device class" bins are making?

I don't believe we should ever use "classes" of device. We've been down
that route, it's a fail in and of itself. We should be using actual
data, not assumed data based on some other data.

OK, good.  We agree on that.  :)

Absolutely agree on "device class". I don't understand why screen-size
is broken.

Because half the people asking for it explicitly say they plan to use
it as a proxy for other device characteristics.  It's not broken per
se, of course, just the way people plan to use it.

In that case I completely agree. But the answer is educate them to
test the right thing. The *only* reason they say that they'll use it
that way right now is because that's what they *have* to do to guess
the information. Classic case being CSS media queries, where screen
size is a proxy for bandwidth and device processing power. It's a
mentality they're in because there is no other solution. Let's provide
one.

   My point is that we should perhaps be thinking about how to make
   things work when these device characteristics change while a page is
   loaded. Headers do NOT allow you to handle that, for obvious reasons.

Ah, loaded as in mid-stream?

That's a problem too, but a small one as you note.  I was thinking "as
in between when onload fires and when onunload fires".  For some web
pages, this time is typically measured in weeks for me (my web-based
RSS reader, for e

Re: [whatwg] RWD Heaven: if browsers reported device capabilities in a request header

[Charles Pritchard]

On 2/7/2012 11:52 AM, Matthew Wilcox wrote:

On 7 February 2012 17:59, Boris Zbarsky  wrote:


On 2/7/12 12:32 PM, Matthew Wilcox wrote:
  In what circumstances might this cause breakages?
Whenever the server developer makes dumb assumptions.  Which they do all
the time.  _All_ the time.


  And how could it possibly lock out any devices?
See my earlier example of a "desktop-class" touchscreen system that's
shipping right now.  Every single concrete proposal I've seen so far in
this thread would lock it out of actually using its touch capabilities on
sites that would support such capabilities fine on other devices.


I don't think I have enough knowledge of the case in point to argue either
way, but I'm confused how this would be the case at the moment.



We already see some frustrating lockout with websites that detect mobile 
user agents. They forward the agent to their special mobile website, 
where they will often popup an alert ("Please download our APP!!!") 
every single time you visit the page. Their mobile site is frequently 
crippled, limited to only a few options, and the mobile browser is often 
capable of viewing the full desktop site at a reasonable screen width. 
Now, as sites mature, they have figured out to include a "Desktop 
Version" toggle, which is a big help. It's still frustrating that there 
are a few steps in between.


These sites make an assumption, that the screen size has something to do 
with device capability. The screen size has to do with how much 
information the viewer has decided to consume at one time.


I'm frequently using browser zoom (though I use OS zoom as well), and I 
don't need to be forwarded to the "mobile site" while I'm browsing on my 
desktop just because I'm not wearing my glasses. That said, I do try to 
work with my applications so that the "mobile" interface is an interface 
that I would like to use on my desktop when I'm zoomed in. That middle 
ground works well for me.




 Now obviously it's also good for the web in various ways, if people

use the information "correctly" and such.  My faith in this is
somewhat tarnished by the fact that every concrete proposal for
using it that I've seen seems to be broken by design, which means
that chances of anyone using it "correctly" are vanishingly small.

Can you tell us how they're broken so we can fix it?


Did you read my earlier mails with examples of devices that are shipping
right now that violate the various assumptions people trying to create
these "device class" bins are making?


I don't believe we should ever use "classes" of device. We've been down
that route, it's a fail in and of itself. We should be using actual data,
not assumed data based on some other data.


We have abstract means of accessibility. WCAG2 explores that.

We have classes of how data is accessed. It should be accessible from a 
keyboard only device.
With touch screens, the world has been exploring more, the concept of 
accessible via pointer only (though virtual keyboards help).


Keep in mind that keyboard and pointer are also two abstractions, not 
physical objects.


There's a third class of accessibility, and that's programmatic access. 
Ensuring that the DOM has sufficient information that third-party
software can use. This is frequently used for eyes-free interfaces, but 
it's handy for many other targets.


There's no assumption of a screen being in place, nor an assumption of 
any particular physical interface.



  Especially if the current solution

is to connect to some massive device database to query potential points
of reference and then act accordingly.


Which is just as broken, yes.  We've run into problems with the breakage
of this database a good bit at Mozilla.


Cool so we agree databases are a bad solution and we should aim for better
:)


Databases are a practical solution for special situations, such as Boris 
brought up, targeting old and somewhat broken browser implementations.


This part of the thread reminds me of the other thing we did with 
server-side packaging -- a bunch of polyfill code. If the user string 
matches X, then we need to include a bunch of "compatibility" libraries.


It's fairly accepted that feature testing works better. At least in 
feature testing, when the compatibility is not available, there's a 
chance to show some kind of alternate item. People can get lazy on this 
as well, writing things like "You are not supported, go away" in 
fallback content. But that's just poor practice. There's every reason to 
think a manual, documentation and other media could take its place.




Absolutely agree on "device class". I don't understand why screen-size is
broken. Report back the maximum screen size used by the device at the
current moment. This allows us to plug iPads into TVs and have it all still
work.


Screen size is not and should not be a physical reflection of the 
viewing device.


The user may be using an eyes-free interface; they may be using browse

Re: [whatwg] RWD Heaven: if browsers reported device capabilities in a request header

[Boris Zbarsky]

On 2/7/12 2:52 PM, Matthew Wilcox wrote:

Reporting more information about the user's hardware and software to
the server allows better fingerprinting and hence tracking.  See

https://www.eff.org/deeplinks/__2010/01/primer-information-__theory-and-privacy


and similar resources for details.


Agreed. But this already happens.


And browsers are working on mitigating the ways it already happens. 
Which means they're reluctant to add new fingerprinting surface.



Your point is the user must be able to
opt in and out, as they might be turning off JS (which, frankly, how
many non-webnerd people do?)


Just wait until UAs start shipping with JS disabled for certain domains 
by default, just like they're already shipping with other capabilities 
turned on or off with certain domains by default.



So you're saying the problem isn't the
tech but the user control? Can we not give that to them?


I'm saying that the _default_ behavior should ideally be as 
user-friendly as possible.  That includes user privacy concerns.  There 
can be additional knobs to enable more privacy features, of course, but 
a lot of what goes on in the privacy space on the web right now 
basically depends on user ignorance about the information websites are 
getting out of them.  When I actually describe the underlying technology 
to non-technical users, they're almost uniformly horrified...



Point taken. Though it irks me no end that various technologies get
canned because of how inept people can mis-use them. I'd rather see
those inept people shoot themselves in the foot and pay the price.


The problem is that the price ends up being paid by someone else. 
Classic example of externalities...  If we could make people fully 
internalize the consequences of their own incompetence, a lot of things 
would ure be easier!



Did you read my earlier mails with examples of devices that are
shipping right now that violate the various assumptions people
trying to create these "device class" bins are making?


I don't believe we should ever use "classes" of device. We've been down
that route, it's a fail in and of itself. We should be using actual
data, not assumed data based on some other data.


OK, good.  We agree on that.  :)


Absolutely agree on "device class". I don't understand why screen-size
is broken.


Because half the people asking for it explicitly say they plan to use it 
as a proxy for other device characteristics.  It's not broken per se, of 
course, just the way people plan to use it.



My point is that we should perhaps be thinking about how to make
things work when these device characteristics change while a page is
loaded. Headers do NOT allow you to handle that, for obvious reasons.

Ah, loaded as in mid-stream?


That's a problem too, but a small one as you note.  I was thinking "as 
in between when onload fires and when onunload fires".  For some web 
pages, this time is typically measured in weeks for me (my web-based RSS 
reader, for example).



See above.  I don't see how just putting it in the headers helps.
  It just encourages websites to assume that the information won't
be changing after the request is done.

How does it encourage website that? That would involve using sessions to
track the user and know which request had what data the last time. And
manually writing some session tracking to do that. I see this as a per
request thing. New data every time.


My RSS reader loads its user interface precisely once over the course of 
several weeks.  If it based this interface on device characteristics at 
time of load (which it actually does, by the way, insofar as it sniffs 
the UA string and then guesses as you point out), then it would be 
broken if I ever change those device characteristics (which I do, and it 
is).


It'd be nice if we could create something that would not lead the people 
writing the RSS reader to end up with exactly the setup they have now...


-Boris

Re: [whatwg] RWD Heaven: if browsers reported device capabilities in a request header

[Nils Dagsson Moskopp]

Matthew Wilcox  schrieb am Tue, 7 Feb 2012
19:38:31 +:

> Can we not turn this into an option in the same way browsers handle
> requests to get the users location? With configuration too?
> 
> Allow browsers to see my:
> 
> screen size

That would be yet another way to push “This web site was designed for
800x600, 16 colors, IE 5.5 or later.” – only with the added “feature”
of “sucks to be you, get a bigger screen, this content will not
display”. UA sniffing, now even worse! Oh, I would certainly be mad.

> connection speed

This is an interesting case – but today well handled by minimal sites.
OkCupid, Twitter, Wikipedia all have well-known minimal alternatives
that can be used when on a bandwith-constrained connection. Often, they
are arguably better (not full of ads etc.).

Since that type of request is not narrowly constrained to specific
circumstances (e.g. location-based services), there is a possibility
for this to become very annoying.

Externalizing the inability to provide content that works across
multiple devices is a very easy cop-out for developers. I for one
advocate control at the UA level (like with CSS media queries) so there
won't be yet another UA string nightmare.

Also, I am writing this on a laptop via a throttled mobile connection.
-- 
Nils Dagsson Moskopp // erlehmann

Re: [whatwg] RWD Heaven: if browsers reported device capabilities in a request header

[Matthew Wilcox]

Thanks again, you make some good points :)

More responses inline...

On 7 February 2012 17:59, Boris Zbarsky  wrote:

> On 2/7/12 12:32 PM, Matthew Wilcox wrote:
>
>>This is a case of browser vendors (or at least me with my browser
>>implementor had on) thinking that sending this sort of information
>>will hurt their users' privacy
>>
>> Can you clarify how this hurts privacy? I'm not sure how reporting back
>> things like connection speed or screen size constitutes a genuine
>> privacy issue?
>>
>
> Reporting more information about the user's hardware and software to the
> server allows better fingerprinting and hence tracking.  See
> https://www.eff.org/deeplinks/**2010/01/primer-information-**
> theory-and-privacyand
>  similar resources for details.


Agreed. But this already happens. Your point is the user must be able to
opt in and out, as they might be turning off JS (which, frankly, how many
non-webnerd people do?). So you're saying the problem isn't the tech but
the user control? Can we not give that to them?


>
>
> , will cause their users to get more broken pages (which is what
>>happens in many cases with browser sniffing right now), will lock
>>new devices out of the market (which is what happens with new UA
>>strings right now).  And hence that the proposal is bad for the web
>>in various ways.
>>
>>
>> I'm not sure what your grounds are for thinking this. Would it not be
>> sensible for the server to have to serve some default if the headers
>> aren't there anyway
>>
>
> Maybe it would be _sensible_, but would people do it?  I suggest trying to
> browse the web with an empty UA string and seeing what fraction of servers
> serve "some default" for that as opposed to the fraction that completely
> break and return error pages for everything or return severely malformed
> pages...  Last I tried this, double-digit percentages of the sites I
> visited broke.


Point taken. Though it irks me no end that various technologies get canned
because of how inept people can mis-use them. I'd rather see those inept
people shoot themselves in the foot and pay the price. Personal philosophy
there.


>  In what circumstances might this cause breakages?
>>
>
> Whenever the server developer makes dumb assumptions.  Which they do all
> the time.  _All_ the time.
>
>
>  And how could it possibly lock out any devices?
>>
>
> See my earlier example of a "desktop-class" touchscreen system that's
> shipping right now.  Every single concrete proposal I've seen so far in
> this thread would lock it out of actually using its touch capabilities on
> sites that would support such capabilities fine on other devices.


I don't think I have enough knowledge of the case in point to argue either
way, but I'm confused how this would be the case at the moment.


>  This is a progressive-enhancement type tech, not a "if you don't have the
>> ability
>> to notify the server you can't get any info" type tech. Surely?
>>
>
> Surely not, in my experience with other things servers look for.


Fair enough :s


> Now obviously it's also good for the web in various ways, if people
>>use the information "correctly" and such.  My faith in this is
>>somewhat tarnished by the fact that every concrete proposal for
>>using it that I've seen seems to be broken by design, which means
>>that chances of anyone using it "correctly" are vanishingly small.
>>
>> Can you tell us how they're broken so we can fix it?
>>
>
> Did you read my earlier mails with examples of devices that are shipping
> right now that violate the various assumptions people trying to create
> these "device class" bins are making?


I don't believe we should ever use "classes" of device. We've been down
that route, it's a fail in and of itself. We should be using actual data,
not assumed data based on some other data.


>  Absolutely agree, but I don't see how a server requesting and then
>> getting a header is rocket sceince
>>
>
> The rocket science lies in deciding what to do with the information.


Ugh, I wrote 'rocket science'. Sorry.


>  Especially if the current solution
>> is to connect to some massive device database to query potential points
>> of reference and then act accordingly.
>>
>
> Which is just as broken, yes.  We've run into problems with the breakage
> of this database a good bit at Mozilla.


Cool so we agree databases are a bad solution and we should aim for better
:)


>  I can see your point, but there isn't any impact for users unless the
>> author has "opted in" and requested headers. Right? The defaults are
>> "server gets no headers". Put it another way - how can an author tailor
>> things for a user if the user isn't able to report anything to the
>> server?
>>
>
> I didn't say the user shouldn't report anything.  I said that the
> particular things people have asked to be reported so far (screen size,
> "device class"

Re: [whatwg] RWD Heaven: if browsers reported device capabilities in a request header

[Matthew Wilcox]

Well given that the point you raise is about opting in and out, not about
the capability of fingerprinting itself. Which as you say, already exists.

Can we not turn this into an option in the same way browsers handle
requests to get the users location? With configuration too?

Allow browsers to see my:

screen size

connection speed

…

On 7 February 2012 22:45, Mike Taylor  wrote:

> On Tue, 07 Feb 2012 11:32:23 -0600, Matthew Wilcox 
> wrote:
>
>  , will cause their users to get more broken pages (which is what happens
>>> in many cases with browser sniffing right now), will lock new devices out
>>> of the market (which is what happens with new UA strings right now).  And
>>> hence that the proposal is bad for the web in various ways.
>>>
>>>  I'm not sure what your grounds are for thinking this. Would it not be
>> sensible for the server to have to serve some default if the headers
>> aren't
>> there anyway, the assumption must be that the device can't send these
>> headers. In what circumstances might this cause breakages? And how could
>> it
>> possibly lock out any devices? This is a progressive-enhancement type
>> tech,
>> not a "if you don't have the ability to notify the server you can't get
>> any
>> info" type tech. Surely?
>>
>
> "Progressive-enhancement type tech" gets abused as well. Take the 
> element, with its lovely  elements for codecs and fallback content
> for non-supporting UAs. No hacks necessary. Then throw laziness and
> javascript at it and you've got a mess.
>
> An example, visit http://www.maerskfleet.com/ with an empty UA string (or
> use Opera). In a browser that should be able to support , you'll get
> a JS error and the page is blank. Even after including Modernizr and using
> HTML5 which is designed to gracefully degrade for older UAs, developers do
> the same old UA sniffing trick: 
> https://gist.github.com/**1761168
>
> I would love to believe that all developers would use this proposal "for
> good", as it were. Experience leads me to believe it will be just another
> technique sniffed and served to the regular suspects.
>
> --
> Mike Taylor
> Opera Software
>

Re: [whatwg] RWD Heaven: if browsers reported device capabilities in a request header

[Mike Taylor]

On Tue, 07 Feb 2012 11:32:23 -0600, Matthew Wilcox  
 wrote:



, will cause their users to get more broken pages (which is what happens
in many cases with browser sniffing right now), will lock new devices  
out
of the market (which is what happens with new UA strings right now).   
And

hence that the proposal is bad for the web in various ways.


I'm not sure what your grounds are for thinking this. Would it not be
sensible for the server to have to serve some default if the headers  
aren't

there anyway, the assumption must be that the device can't send these
headers. In what circumstances might this cause breakages? And how could  
it
possibly lock out any devices? This is a progressive-enhancement type  
tech,
not a "if you don't have the ability to notify the server you can't get  
any

info" type tech. Surely?


"Progressive-enhancement type tech" gets abused as well. Take the   
element, with its lovely  elements for codecs and fallback content  
for non-supporting UAs. No hacks necessary. Then throw laziness and  
javascript at it and you've got a mess.


An example, visit http://www.maerskfleet.com/ with an empty UA string (or  
use Opera). In a browser that should be able to support , you'll  
get a JS error and the page is blank. Even after including Modernizr and  
using HTML5 which is designed to gracefully degrade for older UAs,  
developers do the same old UA sniffing trick:  
https://gist.github.com/1761168


I would love to believe that all developers would use this proposal "for  
good", as it were. Experience leads me to believe it will be just another  
technique sniffed and served to the regular suspects.


--
Mike Taylor
Opera Software

Re: [whatwg] RWD Heaven: if browsers reported device capabilities in a request header

[Boris Zbarsky]

On 2/7/12 12:34 PM, David Goss wrote:

On 7 February 2012 17:11,  Boris wrote:

This is a case of browser vendors (or at least me with my browser
implementor had on) thinking that sending this sort of information will
hurt their users' privacy...


Sorry if I'm missing something obvious, but how? I don't think
anyone's asking for the browser to send anything that can't be
detected client-side and sent to the server anyway.


The idea is to prevent pervasive user tracking via fingerprinting.  It's 
actually easy to prevent client-side detection of some of these things; 
just turn off script execution for the relevant origins.


-Boris

Re: [whatwg] RWD Heaven: if browsers reported device capabilities in a request header

[Boris Zbarsky]

On 2/7/12 12:32 PM, Matthew Wilcox wrote:

This is a case of browser vendors (or at least me with my browser
implementor had on) thinking that sending this sort of information
will hurt their users' privacy

Can you clarify how this hurts privacy? I'm not sure how reporting back
things like connection speed or screen size constitutes a genuine
privacy issue?


Reporting more information about the user's hardware and software to the 
server allows better fingerprinting and hence tracking.  See 
https://www.eff.org/deeplinks/2010/01/primer-information-theory-and-privacy 
and similar resources for details.



, will cause their users to get more broken pages (which is what
happens in many cases with browser sniffing right now), will lock
new devices out of the market (which is what happens with new UA
strings right now).  And hence that the proposal is bad for the web
in various ways.


I'm not sure what your grounds are for thinking this. Would it not be
sensible for the server to have to serve some default if the headers
aren't there anyway


Maybe it would be _sensible_, but would people do it?  I suggest trying 
to browse the web with an empty UA string and seeing what fraction of 
servers serve "some default" for that as opposed to the fraction that 
completely break and return error pages for everything or return 
severely malformed pages...  Last I tried this, double-digit percentages 
of the sites I visited broke.



In what circumstances might this cause breakages?


Whenever the server developer makes dumb assumptions.  Which they do all 
the time.  _All_ the time.



And how could it possibly lock out any devices?


See my earlier example of a "desktop-class" touchscreen system that's 
shipping right now.  Every single concrete proposal I've seen so far in 
this thread would lock it out of actually using its touch capabilities 
on sites that would support such capabilities fine on other devices.



This is a progressive-enhancement type tech, not a "if you don't have the 
ability
to notify the server you can't get any info" type tech. Surely?


Surely not, in my experience with other things servers look for.


Now obviously it's also good for the web in various ways, if people
use the information "correctly" and such.  My faith in this is
somewhat tarnished by the fact that every concrete proposal for
using it that I've seen seems to be broken by design, which means
that chances of anyone using it "correctly" are vanishingly small.

Can you tell us how they're broken so we can fix it?


Did you read my earlier mails with examples of devices that are shipping 
right now that violate the various assumptions people trying to create 
these "device class" bins are making?



Absolutely agree, but I don't see how a server requesting and then
getting a header is rocket sceince


The rocket science lies in deciding what to do with the information.


Especially if the current solution
is to connect to some massive device database to query potential points
of reference and then act accordingly.


Which is just as broken, yes.  We've run into problems with the breakage 
of this database a good bit at Mozilla.



I can see your point, but there isn't any impact for users unless the
author has "opted in" and requested headers. Right? The defaults are
"server gets no headers". Put it another way - how can an author tailor
things for a user if the user isn't able to report anything to the
server?


I didn't say the user shouldn't report anything.  I said that the 
particular things people have asked to be reported so far (screen size, 
"device class") are broken by design.



Yes, but "size" and "performance" are not necessarily a function of
the actual device.  They can be a function of the device, the
network, the currently attached peripherals, etc.  Importantly, they
are not time-invariant.  The question is what we can do about that...

Agreed - which is *exactly* why I think headers are the only viable
solution.


My point is that we should perhaps be thinking about how to make things 
work when these device characteristics change while a page is loaded. 
Headers do NOT allow you to handle that, for obvious reasons.



The other solutions operate by detecting the device and making
assumptions about those variables based on the device specifications.


Assuming you can detect the device at all, which I think servers should 
not be able to do.



Exactly! Hence the need for the browser to report *as a header* with
each request what the current values are for those variables.


See above.  I don't see how just putting it in the headers helps.  It 
just encourages websites to assume that the information won't be 
changing after the request is done.


-Boris

Re: [whatwg] RWD Heaven: if browsers reported device capabilities in a request header

[David Goss]

On 7 February 2012 17:11,  Boris wrote:
> This is a case of browser vendors (or at least me with my browser
> implementor had on) thinking that sending this sort of information will
> hurt their users' privacy...

Sorry if I'm missing something obvious, but how? I don't think
anyone's asking for the browser to send anything that can't be
detected client-side and sent to the server anyway.

Re: [whatwg] RWD Heaven: if browsers reported device capabilities in a request header

[Matthew Wilcox]

Thanks for the feedback :)

I've replied inline, but please be aware that I don't have a browser-vendor
hat to put on so some of my questions may well be a bit naive (for which I
apologise in advance)

On 7 February 2012 17:11, Boris Zbarsky  wrote:

> On 2/7/12 9:13 AM, Matthew Wilcox wrote:
>
>> To be clear: this is a case of browser vendors deciding it's too
>> expensive and therefor not allowing it to be implemented
>>
>
> This is a case of browser vendors (or at least me with my browser
> implementor had on) thinking that sending this sort of information will
> hurt their users' privacy


Can you clarify how this hurts privacy? I'm not sure how reporting back
things like connection speed or screen size constitutes a genuine privacy
issue?


> , will cause their users to get more broken pages (which is what happens
> in many cases with browser sniffing right now), will lock new devices out
> of the market (which is what happens with new UA strings right now).  And
> hence that the proposal is bad for the web in various ways.
>

I'm not sure what your grounds are for thinking this. Would it not be
sensible for the server to have to serve some default if the headers aren't
there anyway, the assumption must be that the device can't send these
headers. In what circumstances might this cause breakages? And how could it
possibly lock out any devices? This is a progressive-enhancement type tech,
not a "if you don't have the ability to notify the server you can't get any
info" type tech. Surely?


> Now obviously it's also good for the web in various ways, if people use
> the information "correctly" and such.  My faith in this is somewhat
> tarnished by the fact that every concrete proposal for using it that I've
> seen seems to be broken by design, which means that chances of anyone using
> it "correctly" are vanishingly small.


Can you tell us how they're broken so we can fix it?


>  We should strive to provide information that will enable the server to
> better serve the user without it being rocket science to do so without
> breaking other users.


Absolutely agree, but I don't see how a server requesting and then getting
a header is rocket sceince. Especially if the current solution is to
connect to some massive device database to query potential points of
reference and then act accordingly.


>  when it should be
>> authors in the position to know whether it's too expensive given their
>> specific use case.
>>
>
> This is privileging authors over users. I understand the author
> perspective on this, but in general I care about users more than we do
> about authors  I don't think I'm the only one.


I can see your point, but there isn't any impact for users unless the
author has "opted in" and requested headers. Right? The defaults are
"server gets no headers". Put it another way - how can an author tailor
things for a user if the user isn't able to report anything to the server?
Not allowing this process is a disservice to the user *and* the author.
It's basically saying "no, you can't drive the car because you may end up
on a busy road which will be even slower than walking".


>  No offense taken btw. Things have to prove themselves. The danger is the
>> standards process is too slow to react well, and some even more hacky
>> solution turning into a de-facto standard.
>>
>
> Yes, this is a problem.
>
>
>  Devices of significantly varied size and performance are here to stay
>>
>
> Yes, but "size" and "performance" are not necessarily a function of the
> actual device.  They can be a function of the device, the network, the
> currently attached peripherals, etc.  Importantly, they are not
> time-invariant.  The question is what we can do about that...
>

Agreed - which is *exactly* why I think headers are the only viable
solution. The other solutions operate by detecting the device and making
assumptions about those variables based on the device specifications. Only
the device you're talking with right then can possibly have that
information.


> (Simple example: the performance of my laptop will vary by easily a factor
> of close to 1.5 just depending on whether it's plugged in and what sort of
> surface it's resting on.  I expect this trend to continue unless we get
> some sort of revolutionary improvements in battery and cooling technology.)


Exactly! Hence the need for the browser to report *as a header* with each
request what the current values are for those variables.


> -Boris

Re: [whatwg] RWD Heaven: if browsers reported device capabilities in a request header

[Boris Zbarsky]

On 2/7/12 4:28 AM, James Graham wrote:

This basically amounts to "the requirements were wrong".


Given the limited information I have so far, yes.


Since the same developer made both the desktop and mobile frontends and he is 
one of
the major users of the system, and the mobile frontend was purely
scratching his own itch, I find it very difficult to justify the
position that he ought to have wanted something different to what he
actually wanted and made.


The fewer users a system has the more weird the requirements can get.  I 
accept that.  I do wonder how much we should care about that on the web, 
though.



In general the idea that sites/applications should be essentially the
same, but perhaps slightly rearranged, regardless of the device they run
on just doesn't seem to be something that the market agrees with.


I'm willing to accept that too.  How much of this is a matter of 
effectively cepy/paste, how much is a matter of this being the path of 
least resistance in the face of technical challenges and political 
opposition (e.g. removing most ads from the "desktop" version of a site 
might not be viewed favorably), and how much is actually dictated by the 
device differences is unclear to me.



It seems to me that we can either pretend that this isn't true, and watch
as platform-specific apps become increasingly entrenched, or work out
ways to make the UX on sites that target multiple types of hardware as
good as possible.


Clearly the latter is preferable.  It's hard to do that without very 
specific use cases; we've been getting some in this thread, but there's 
a high level of "we just want it to look different, and need a way to 
guess what it should look like" going on too.



Of course. The critical point was that there was different information
in the two cases.


This is the part I'd like to understand.  Why?  Did this have to do with 
the actual devices, or with the way the particular person happened to 
use the two devices in his day-to-day activities?  I realize you may not 
know.


That said, if the information was really _different_ then I'm not sure I 
agree with the "same URI" requirement.



So it seems to me that we have a problem that real people are hacking
their way around by using techniques that are known to be suboptimal or
downright harmful. Therefore we should take the desire for a solution
seriously


Yes.

-Boris

Re: [whatwg] RWD Heaven: if browsers reported device capabilities in a request header

[Boris Zbarsky]

On 2/7/12 9:13 AM, Matthew Wilcox wrote:

To be clear: this is a case of browser vendors deciding it's too
expensive and therefor not allowing it to be implemented


This is a case of browser vendors (or at least me with my browser 
implementor had on) thinking that sending this sort of information will 
hurt their users' privacy, will cause their users to get more broken 
pages (which is what happens in many cases with browser sniffing right 
now), will lock new devices out of the market (which is what happens 
with new UA strings right now).  And hence that the proposal is bad for 
the web in various ways.


Now obviously it's also good for the web in various ways, if people use 
the information "correctly" and such.  My faith in this is somewhat 
tarnished by the fact that every concrete proposal for using it that 
I've seen seems to be broken by design, which means that chances of 
anyone using it "correctly" are vanishingly small.  We should strive to 
provide information that will enable the server to better serve the user 
without it being rocket science to do so without breaking other users. 
The problem is that we haven't found a way to do that yet.



when it should be
authors in the position to know whether it's too expensive given their
specific use case.


This is privileging authors over users.  I understand the author 
perspective on this, but in general I care about users more than we do 
about authors  I don't think I'm the only one.



No offense taken btw. Things have to prove themselves. The danger is the
standards process is too slow to react well, and some even more hacky
solution turning into a de-facto standard.


Yes, this is a problem.


Devices of significantly varied size and performance are here to stay


Yes, but "size" and "performance" are not necessarily a function of the 
actual device.  They can be a function of the device, the network, the 
currently attached peripherals, etc.  Importantly, they are not 
time-invariant.  The question is what we can do about that...


(Simple example: the performance of my laptop will vary by easily a 
factor of close to 1.5 just depending on whether it's plugged in and 
what sort of surface it's resting on.  I expect this trend to continue 
unless we get some sort of revolutionary improvements in battery and 
cooling technology.)


-Boris

Re: [whatwg] RWD Heaven: if browsers reported device capabilities in a request header

[Matthew Wilcox]

I don't agree that it's a good idea to have to have the server query some
massive device database in order to find out what the requesting device
does and does not support. Device databases are, by their nature, going to
be hard to maintain, hard to support, and not tell us all we need to
know. How is a device database going to tell us the current connection
speed, or the user's zoom level, or device orientation, or anything else
dynamic that may be relevant to know on the server?

The database route is merely an extension of UA sniffing, which was about
detecting devices and assuming capabilities and settings. The problem with
that was inaccuracy, and ongoing laboured maintenance. I want us to detect
the actual capabilities directly - exactly how CSS works. Detect what's
there. Skip the middle-man. How does it make sense to resort to siloing
this information in a database, when we're the body that makes the
standards that would allow direct knowledge?

I'm less interested in current work-arounds (and that's what those are,
workarounds and best guesses destined to fail at some point) and more
interested in getting accurate, reliable, future-proof data exposed.


On 7 February 2012 16:46, Charles McCathieNevile  wrote:

> On Tue, 07 Feb 2012 15:13:03 +0100, Matthew Wilcox 
> wrote:
>
>  Personally, I think the issue of adapting resources to client
>> capabilities is here to stay.
>>
>
> For sure, although the mechanisms might evolve.
>
>
>  Devices of significantly varied size and performance are here to stay,
>>
>
> Yes...
>
>
>  and adapting images to suit is only one example of smart resource
>> adaption - it doesn't seem like it would become irrelevant until all
>> devices are memory and processor monsters over high speed connections.
>>
>
> Actually I suspect the end condition is "until memory and processing and
> bandwidth are all free" which is slightly different.
>
>
>  Which is going to take decades, if it ever happens.
>>
>
> I will be surprised if I see it.
>
> Anyway, I would really encourage you to look at
> http://en.wikipedia.org/wiki/**Device_Description_Repositoryandperhaps
>  something like
> http://www.openddr.org/ or the commercial solutions that deal with this
> area.
>
> cheers
>
>
> --
> Charles 'chaals' McCathieNevile  Opera Software, Standards Group
>je parle français -- hablo español -- jeg kan litt norsk
> http://my.opera.com/chaals   Try Opera: http://www.opera.com
>

Re: [whatwg] add html-attribute for "responsive images"

[Jason Grigsby]

I’ve read that comment three times and still don’t grok it. :-)

It seems the comment mixes lookahead pre-parsing behavior with pre-fetching and 
pre-rendering behavior. Compare the definitions of pre-fetching and 
pre-rendering in the Google Chrome documentation that the comment points to:
http://code.google.com/chrome/whitepapers/prerender.html

With the definition of the lookahead pre-parser from the IE team:
http://blogs.msdn.com/b/ieinternals/archive/2011/07/18/optimal-html-head-ordering-to-avoid-parser-restarts-redownloads-and-improve-performance.aspx

The comment also states “A pre-_render_, on the other hand, loads a page and 
all its content, but keeps it hidden. At the moment, it only happens on 
Chrome.” That was the biggest clue to me that the person was talking about 
something different because the IE team has written about their lookahead 
pre-parser.

That said, it wouldn’t be the first time something went over my head. Am I 
wrong that the comment is talking about something different?

-Jason

On Feb 7, 2012, at 5:37 AM, Anselm Hannemann wrote:

> As far as I understand browsers like Chrome preparse sites where they don't 
> actually get the DOM but load resources they find in code. So it would be 
> impossible to say it shouldn't be loaded.
> See this comment about it: 
> http://www.alistapart.com/comments/responsive-images-how-they-almost-worked-and-what-we-need/P40/#41

Re: [whatwg] RWD Heaven: if browsers reported device capabilities in a request header

[Charles McCathieNevile]

On Tue, 07 Feb 2012 15:13:03 +0100, Matthew Wilcox  
 wrote:



Personally, I think the issue of adapting resources to client
capabilities is here to stay.


For sure, although the mechanisms might evolve.


Devices of significantly varied size and performance are here to stay,


Yes...


and adapting images to suit is only one example of smart resource
adaption - it doesn't seem like it would become irrelevant until all
devices are memory and processor monsters over high speed connections.


Actually I suspect the end condition is "until memory and processing and  
bandwidth are all free" which is slightly different.



Which is going to take decades, if it ever happens.


I will be surprised if I see it.

Anyway, I would really encourage you to look at  
http://en.wikipedia.org/wiki/Device_Description_Repository andperhaps  
something like http://www.openddr.org/ or the commercial solutions that  
deal with this area.


cheers

--
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg kan litt norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com

Re: [whatwg] add html-attribute for "responsive images"

[Matthew Wilcox]

That's a fair enough point. I'd /like/ to be able to over-ride the alt with
something even more specific, but I do agree the core semantics should be
the same - so a 'generalised' alt would work too, just be a little less
informative than it could be.

I could see the advantage of not allowing alt over-riding in that it forces
the alt to be applicable to all sources which then strengthens the vibe
that the images, although different, should have the same semantics.

On 7 February 2012 14:59, David Goss  wrote:

> On 7 February 2012 14:00, Matthew Wilcox  wrote:
> > I'm glad this is making a reasonable amount of sense to people :)
> >
> > Please note however that this isn't just a case of "the image is
> cropped".
> > It could be an entirely different image *as long as* it still carries the
> > same semantic message. In that, the image in the About example is merely
> to
> > give a visual representation of someone. As long as all of the scaled
> images
> > do that, they do not need to be *the same image* re-cropped. In fact, it
> > would be better in this case to have different images. Hence why it makes
> > sense to have the ability to over-ride the alt attribute on each source.
> >
> > There's nothing to stop us saying that an alt attribute can be declared
> on
> > the default image, and is only over-written if the  contains a new
> alt
> > attribute?
> >
> > -Matt
> >
> > On Tuesday, Feb 7, 2012, at 7:35 AM, David Goss wrote:
> >>
> >> I'm not really sure whether  should get an alt attribute - my
> >> thinking is that if one alt attribute doesn't correctly describe all the
> >> s then perhaps they are different content. Matthew's example
> does
> >> make sense, in that the extra alt attributes describe the way the image
> has
> >> been cropped (although it's still the same image). But maybe it would be
> >> better to only allow alt on the  to reinforce the idea that all the
> >> s should basically be the same image albeit
> >> cropped/monochrome/whatever.
> >>
>
> My point is that if the two images are supposed to have the same
> semantic message, then you should be able to describe them both with
> the same alt text (even if the differences between those images make
> the alt text a little more vague than it might be). So, as you say,
> you could have two different photos of the same person for different
> media, but the alt text "photo of Matthew Wilcox" would be applicable
> for both, so that's fine.
>
> I'm with you in that I want the flexibility (e.g. the sources
> shouldn't all have to be literally the same image just resized), I
> just think saying "all sources must correspond with same alt text"
> gives a nice clear definition of what's okay for authors.
>

Re: [whatwg] add html-attribute for "responsive images"

[David Goss]

On 7 February 2012 14:00, Matthew Wilcox  wrote:
> I'm glad this is making a reasonable amount of sense to people :)
>
> Please note however that this isn't just a case of "the image is cropped".
> It could be an entirely different image *as long as* it still carries the
> same semantic message. In that, the image in the About example is merely to
> give a visual representation of someone. As long as all of the scaled images
> do that, they do not need to be *the same image* re-cropped. In fact, it
> would be better in this case to have different images. Hence why it makes
> sense to have the ability to over-ride the alt attribute on each source.
>
> There's nothing to stop us saying that an alt attribute can be declared on
> the default image, and is only over-written if the  contains a new alt
> attribute?
>
> -Matt
>
> On Tuesday, Feb 7, 2012, at 7:35 AM, David Goss wrote:
>>
>> I'm not really sure whether  should get an alt attribute - my
>> thinking is that if one alt attribute doesn't correctly describe all the
>> s then perhaps they are different content. Matthew's example does
>> make sense, in that the extra alt attributes describe the way the image has
>> been cropped (although it's still the same image). But maybe it would be
>> better to only allow alt on the  to reinforce the idea that all the
>> s should basically be the same image albeit
>> cropped/monochrome/whatever.
>>

My point is that if the two images are supposed to have the same
semantic message, then you should be able to describe them both with
the same alt text (even if the differences between those images make
the alt text a little more vague than it might be). So, as you say,
you could have two different photos of the same person for different
media, but the alt text "photo of Matthew Wilcox" would be applicable
for both, so that's fine.

I'm with you in that I want the flexibility (e.g. the sources
shouldn't all have to be literally the same image just resized), I
just think saying "all sources must correspond with same alt text"
gives a nice clear definition of what's okay for authors.

Re: [whatwg] add html-attribute for "responsive images"

[David Goss]

On 7 February 2012 13:42, Mathew Marquis  wrote:
>
> On Tuesday, Feb 7, 2012, at 7:35 AM, David Goss wrote:
>>
>> On 7 February 2012 11:31:15 +0100, Anselm Hannemann wrote:
>>>
>>> This is a good solution except the fallback img element would be twice
>>> loaded in your case which is not good.
>>> There should be the img element containing the standard (normal) size and
>>> src elements to add diff. other resolutions. With that the browser won't
>>> load the resource twice.
>>
>> Would it? I think Matthew's example implies that a supporting browser
>> *wouldn't* load the src from the  unless none of the s got a
>> media match. Right?
>>
>
> I’m not sure how it’s intended to work with  currently, but I believe
> the fallback is only loaded if  is unsupported—if none of the sources
> match, I believe nothing is displayed. I may be wrong, but that seems to be
> the most predictable behavior.

Ah, good point.  has its own src attrribute, which is where the
default source goes. Then it can be overridden by the last 
element with a media match, if any.

>>
>> I'm not really sure whether  should get an alt attribute - my
>> thinking is that if one alt attribute doesn't correctly describe all the
>> s then perhaps they are different content. Matthew's example does
>> make sense, in that the extra alt attributes describe the way the image has
>> been cropped (although it's still the same image). But maybe it would be
>> better to only allow alt on the  to reinforce the idea that all the
>> s should basically be the same image albeit
>> cropped/monochrome/whatever.
>>
>
> I’m with you, here. I’m hesitant to have any logic hinge on the fallback
> img, though, as it wouldn’t be strictly required—the fallback content could
> be, say, descriptive text instead (Granted I wouldn’t do it, but just trying
> to keep things as flexible as possible). I do think all sources should be
> described by a single alt tag, though, possibly on  itself?
>

I guess I've moved away from similarities with , in that I've
been thinking of the  as the default content, not the fallback
content. Going with your angle for a simple example with two sizes:


  
  


The duplication of the alt and default src attributes bothers me, but
on reflection perhaps it's better to have consistency with .

Re: [whatwg] RWD Heaven: if browsers reported device capabilities in a request header

[Jason Grigsby]

Then yes, I can get behind the idea of that such a communication method would 
be very useful.

On Feb 7, 2012, at 4:55 AM, Matthew Wilcox wrote:

> Absolutely agree that we should not be concentrating on one specific thing. 
> What I want is the ability to have the server ask for whatever info it needs 
> about the client device/environment, and have that sent as a header. And only 
> sent if the server has asked. I don't mean we want "screen size" alone, that 
> is but one example of something the server might care about. Bandwidth is 
> another, as is viewport size, and I am sure there are a lot more. I want to 
> see a *communication method* defined here, not a one-issue semi-solution to 
> an overly specific example of what is in reality a much broader problem (the 
> server not having reliable information about the client).

Re: [whatwg] RWD Heaven: if browsers reported device capabilities in a request header

[Matthew Wilcox]

Ahhh, ok. I was not aware that SPDY is intended to suffer from the flaws
inflicted by the dated mechanics of HTTP. Is it really different semantics
though? I don't see how it's harmful to enable resource adaption over SPDY
just because browser vendors have decided that HTTP is too expensive to do
it? To be clear: this is a case of browser vendors deciding it's too
expensive and therefor not allowing it to be implemented, when it should be
authors in the position to know whether it's too expensive given their
specific use case.

I'm sensing the SPDY/HTTP identical-semantics standpoint may be a
philosophical thing rather than technical?

No offense taken btw. Things have to prove themselves. The danger is the
standards process is too slow to react well, and some even more hacky
solution turning into a de-facto standard. Personally, I think the issue of
adapting resources to client capabilities is here to stay. Devices of
significantly varied size and performance are here to stay, and adapting
images to suit is only one example of smart resource adaption - it doesn't
seem like it would become irrelevant until all devices are memory and
processor monsters over high speed connections. Which is going to take
decades, if it ever happens.

I'm glad the discussion is going on though, and there are as always points
to be considered that are not obvious at first.

It just seems like SPDY as a technology is in a great position to do this.
It's the choice of restricting SPDY to HTTP's viable capabilities which is
the cause of a potential veto of this.

:)

On 7 February 2012 13:34, Henri Sivonen  wrote:

> On Mon, Feb 6, 2012 at 5:52 PM, Matthew Wilcox 
> wrote:
> > Also, as indicated, with SPDY this is much much less of a problem than
> for HTTP.
>
> SPDY transfers the HTTP semantics more efficiently when supported. You
> aren't supposed to communicate different semantics depending on
> whether SPDY is enabled. That would be a layering violation.
>
> That is, SPDY is supposed to work as a drop-in replacement for the old
> way of putting HTTP semantics over IP. You aren't supposed to send
> different headers depending on whether SPDY is there or not.
>
> And the old HTTP is going to be around for a *long* time, so even if a
> bunch of important sites start supporting SPDY, if browsers send the
> same headers in all cases to avoid the layering violation, the long
> tail of plain old HTTP sites would be harmed by request size bloat.
>
> So I think "SPDY will fix it" is not a persuasive argument for
> allowing HTTP request bloat to cater to the bandwagon of the day.
> (Sorry if that seems offensive. You've worked on responsive images, so
> they evidently seem important to you, but in the long-term big
> picture, it's nowhere near proven that they aren't a fad of interest
> to a relative small number of Web developers.)
>
> If there is evidence that responsive images aren't just a fad
> bandwagon and there's a long-term need to support them in the
> platform, I think supporting something like
> 
> 
> 
> 
> 
> would make more sense, since the added to transfer this markup would
> affect sites that use this stuff instead of affecting each request to
> all sites that don't use this stuff. This would be more
> intermediary-friendly, too, by not involving the Vary header.
>
> The points Boris made about the device pixel size of the image
> changing after the page load still apply, though.
>
> But still, engineering for sites varying the number of pixels they
> send for photos seems a bit premature when sites haven't yet adopted
> SVG for illustrations, diagrams, logos, icons, etc.
>
> --
> Henri Sivonen
> hsivo...@iki.fi
> http://hsivonen.iki.fi/
>

Re: [whatwg] add html-attribute for "responsive images"

[Matthew Wilcox]

PS: I am a strong believer that we need both a server-side and client-side
solution to this problem of adaptive media. They solve different aspects of
what seem superficially the same things :)

Re: [whatwg] add html-attribute for "responsive images"

[Matthew Wilcox]

I'm glad this is making a reasonable amount of sense to people :)

Please note however that this isn't just a case of "the image is cropped".
It could be an entirely different image *as long as* it still carries the
same semantic message. In that, the image in the About example is merely to
give a visual representation of someone. As long as all of the scaled
images do that, they do not need to be *the same image* re-cropped. In
fact, it would be better in this case to have different images. Hence why
it makes sense to have the ability to over-ride the alt attribute on each
source.

There's nothing to stop us saying that an alt attribute can be declared on
the default image, and is only over-written if the  contains a new alt
attribute?

-Matt

On 7 February 2012 13:42, Mathew Marquis  wrote:

>
> On Tuesday, Feb 7, 2012, at 7:35 AM, David Goss wrote:
>
> On 7 February 2012 11:31:15 +0100, Anselm Hannemann wrote:
>
> Am 07.02.2012 um 11:16 schrieb Matthew Wilcox:
>> > To me this makes most sense /from an author perspective/ (I make no
>> claims as to how practical this really is):
>> >
>> > 
>> >   > media="min-width:320" />
>> >   
>> >   > media="min-width:640" />
>> >
>> >   
>> >   
>> > 
>> >
>> > The reason being:
>> >
>> > * it's easy to read
>> > * it uses familiar element structures and properties
>> > * it allows us to adjust to any given media requirement, not just
>> screen size (you could query bandwidth with this > syntax, though I contest
>> bandwidth is the domain of server side adaption rather than client side)
>>
>> This is a good solution except the fallback img element would be twice
>> loaded in your case which is not good.
>> There should be the img element containing the standard (normal) size and
>> src elements to add diff. other resolutions. With that the browser won't
>> load the resource twice.
>>
>
> Would it? I think Matthew's example implies that a supporting browser
> *wouldn't* load the src from the  unless none of the s got a
> media match. Right?
>
>
> I’m not sure how it’s intended to work with  currently, but I
> believe the fallback is only loaded if  is unsupported—if none of
> the sources match, I believe nothing is displayed. I may be wrong, but that
> seems to be the most predictable behavior.
>
>
> The way I proposed it would have the same behaviour but have the  as
> the first child element of , making it more apparent that it's the
> default content as well as the fallback content. Also, it would contain
> important attributes like alt. So:
>
> 
>   
>media="min-width:320" />
>   
>media="min-width:640" />
> 
>
> And:
>
> - unsupporting browsers would get default.jpg (but the author could
> implement some JS to run the  media queries and swap in the most
> appropriate image if desired)
> - supporting browsers narrower than 320px would also get default.jpg,
> because none of the s would get a media match
> - supporting browsers 320px or wider would get the image from the last
>  to get a media match (because a 800px wide screen would match all
> 3 in this example)
>
> I'm not really sure whether  should get an alt attribute - my
> thinking is that if one alt attribute doesn't correctly describe all the
> s then perhaps they are different content. Matthew's example does
> make sense, in that the extra alt attributes describe the way the image has
> been cropped (although it's still the same image). But maybe it would be
> better to only allow alt on the  to reinforce the idea that all the
> s should basically be the same image albeit
> cropped/monochrome/whatever.
>
>
> I’m with you, here. I’m hesitant to have any logic hinge on the fallback
> img, though, as it wouldn’t be strictly required—the fallback content could
> be, say, descriptive text instead (Granted I wouldn’t do it, but just
> trying to keep things as flexible as possible). I do think all sources
> should be described by a single alt tag, though, possibly on 
> itself?
>
>
> FWIW, whatever becomes of the discussion about sending media-query-like
> data in headers to the server (RWD Heaven: if browsers reported device
> capabilities in a request header), we need this responsive image markup
> regardless.
>
>
> Hear hear!
>
>
> Thanks
>
> David
>
>
>

Re: [whatwg] add html-attribute for "responsive images"

[Henri Sivonen]

On Tue, Feb 7, 2012 at 1:15 AM, Bjartur Thorlacius  wrote:
> Why not use a media attribute of ?

There's probably already a better answer to "Why not use  for
foo?" in the archives of this list, but the short version is that it's
nicer for implementations to have elements that support particular
functionality when node is created instead of having elements that
change their nature substantially depending on attributes, network
fetches, presence of plug-ins, etc., etc.

-- 
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/

Re: [whatwg] add html-attribute for "responsive images"

[Mathew Marquis]

On Tuesday, Feb 7, 2012, at 7:35 AM, David Goss wrote:

> On 7 February 2012 11:31:15 +0100, Anselm Hannemann wrote:
> 
> Am 07.02.2012 um 11:16 schrieb Matthew Wilcox:
> > To me this makes most sense /from an author perspective/ (I make no claims 
> > as to how practical this really is):
> >
> > 
> >> media="min-width:320" />
> >> media="min-width:480" />
> >> media="min-width:640" />
> >
> >   
> >   
> > 
> >
> > The reason being:
> >
> > * it's easy to read
> > * it uses familiar element structures and properties
> > * it allows us to adjust to any given media requirement, not just screen 
> > size (you could query bandwidth with this > syntax, though I contest 
> > bandwidth is the domain of server side adaption rather than client side)
> 
> This is a good solution except the fallback img element would be twice loaded 
> in your case which is not good.
> There should be the img element containing the standard (normal) size and src 
> elements to add diff. other resolutions. With that the browser won't load the 
> resource twice.
> 
> Would it? I think Matthew's example implies that a supporting browser 
> *wouldn't* load the src from the  unless none of the s got a 
> media match. Right?

I’m not sure how it’s intended to work with  currently, but I believe 
the fallback is only loaded if  is unsupported—if none of the sources 
match, I believe nothing is displayed. I may be wrong, but that seems to be the 
most predictable behavior.

> 
> The way I proposed it would have the same behaviour but have the  as the 
> first child element of , making it more apparent that it's the 
> default content as well as the fallback content. Also, it would contain 
> important attributes like alt. So:
> 
> 
>   
>media="min-width:320" />
>media="min-width:480" />
>media="min-width:640" />
> 
> 
> And:
> 
> - unsupporting browsers would get default.jpg (but the author could implement 
> some JS to run the  media queries and swap in the most appropriate 
> image if desired)
> - supporting browsers narrower than 320px would also get default.jpg, because 
> none of the s would get a media match
> - supporting browsers 320px or wider would get the image from the last 
>  to get a media match (because a 800px wide screen would match all 3 
> in this example)
> 
> I'm not really sure whether  should get an alt attribute - my 
> thinking is that if one alt attribute doesn't correctly describe all the 
> s then perhaps they are different content. Matthew's example does 
> make sense, in that the extra alt attributes describe the way the image has 
> been cropped (although it's still the same image). But maybe it would be 
> better to only allow alt on the  to reinforce the idea that all the 
> s should basically be the same image albeit 
> cropped/monochrome/whatever.

I’m with you, here. I’m hesitant to have any logic hinge on the fallback img, 
though, as it wouldn’t be strictly required—the fallback content could be, say, 
descriptive text instead (Granted I wouldn’t do it, but just trying to keep 
things as flexible as possible). I do think all sources should be described by 
a single alt tag, though, possibly on  itself?

> 
> FWIW, whatever becomes of the discussion about sending media-query-like data 
> in headers to the server (RWD Heaven: if browsers reported device 
> capabilities in a request header), we need this responsive image markup 
> regardless.

Hear hear!

> 
> Thanks
> 
> David

Re: [whatwg] RWD Heaven: if browsers reported device capabilities in a request header

[Henri Sivonen]

On Mon, Feb 6, 2012 at 5:52 PM, Matthew Wilcox  wrote:
> Also, as indicated, with SPDY this is much much less of a problem than for 
> HTTP.

SPDY transfers the HTTP semantics more efficiently when supported. You
aren't supposed to communicate different semantics depending on
whether SPDY is enabled. That would be a layering violation.

That is, SPDY is supposed to work as a drop-in replacement for the old
way of putting HTTP semantics over IP. You aren't supposed to send
different headers depending on whether SPDY is there or not.

And the old HTTP is going to be around for a *long* time, so even if a
bunch of important sites start supporting SPDY, if browsers send the
same headers in all cases to avoid the layering violation, the long
tail of plain old HTTP sites would be harmed by request size bloat.

So I think "SPDY will fix it" is not a persuasive argument for
allowing HTTP request bloat to cater to the bandwagon of the day.
(Sorry if that seems offensive. You've worked on responsive images, so
they evidently seem important to you, but in the long-term big
picture, it's nowhere near proven that they aren't a fad of interest
to a relative small number of Web developers.)

If there is evidence that responsive images aren't just a fad
bandwagon and there's a long-term need to support them in the
platform, I think supporting something like





would make more sense, since the added to transfer this markup would
affect sites that use this stuff instead of affecting each request to
all sites that don't use this stuff. This would be more
intermediary-friendly, too, by not involving the Vary header.

The points Boris made about the device pixel size of the image
changing after the page load still apply, though.

But still, engineering for sites varying the number of pixels they
send for photos seems a bit premature when sites haven't yet adopted
SVG for illustrations, diagrams, logos, icons, etc.

-- 
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/

Re: [whatwg] add html-attribute for "responsive images"

[David Goss]

On 7 February 2012 11:31:15 +0100, Anselm Hannemann wrote:

Am 07.02.2012 um 11:16 schrieb Matthew Wilcox:
> > To me this makes most sense /from an author perspective/ (I make no
> claims as to how practical this really is):
> >
> > 
> >media="min-width:320" />
> >media="min-width:480" />
> >media="min-width:640" />
> >
> >   
> >   
> > 
> >
> > The reason being:
> >
> > * it's easy to read
> > * it uses familiar element structures and properties
> > * it allows us to adjust to any given media requirement, not just screen
> size (you could query bandwidth with this > syntax, though I contest
> bandwidth is the domain of server side adaption rather than client side)
>
> This is a good solution except the fallback img element would be twice
> loaded in your case which is not good.
> There should be the img element containing the standard (normal) size and
> src elements to add diff. other resolutions. With that the browser won't
> load the resource twice.
>

Would it? I think Matthew's example implies that a supporting browser
*wouldn't* load the src from the  unless none of the s got a
media match. Right?

The way I proposed it would have the same behaviour but have the  as
the first child element of , making it more apparent that it's the
default content as well as the fallback content. Also, it would contain
important attributes like alt. So:


  
  
  
  


And:

- unsupporting browsers would get default.jpg (but the author could
implement some JS to run the  media queries and swap in the most
appropriate image if desired)
- supporting browsers narrower than 320px would also get default.jpg,
because none of the s would get a media match
- supporting browsers 320px or wider would get the image from the last
 to get a media match (because a 800px wide screen would match all
3 in this example)

I'm not really sure whether  should get an alt attribute - my
thinking is that if one alt attribute doesn't correctly describe all the
s then perhaps they are different content. Matthew's example does
make sense, in that the extra alt attributes describe the way the image has
been cropped (although it's still the same image). But maybe it would be
better to only allow alt on the  to reinforce the idea that all the
s should basically be the same image albeit
cropped/monochrome/whatever.

FWIW, whatever becomes of the discussion about sending media-query-like
data in headers to the server (RWD Heaven: if browsers reported device
capabilities in a request header), we need this responsive image markup
regardless.

Thanks

David

Re: [whatwg] add html-attribute for "responsive images"

[Bjartur Thorlacius]

On 2/7/12, Ashley Sheridan  wrote:
> The main problem I see with that is that the  tag doesn't have
> the same accessibility attributes, so you'd effectively lock out a lot
> of people using browsers that don't understand the context of the tag in
> this case. I think the better way is to add something to the  tag
> as you'd still have full backwards compatibility.
>
What accessibility features, exactly? For compatibility, the deepest
child of  would be , inheriting the accessibility
features of img. Alternatively, it might just as well be markup, which
is surely better accessibility wise than @alt and @longdesc.
Furthermore, you could theoretically link to an animation, a still and
a sound and embed a hypertext fallback.
(I'm sorry if 's being generally terrible for accessibility
has been established already.)

Re: [whatwg] add html-attribute for "responsive images"

[Ashley Sheridan]

On Tue, 2012-02-07 at 10:56 +, Bjartur Thorlacius wrote:

> On 2/7/12, Ashley Sheridan  wrote:
> > The main problem I see with that is that the  tag doesn't have
> > the same accessibility attributes, so you'd effectively lock out a lot
> > of people using browsers that don't understand the context of the tag in
> > this case. I think the better way is to add something to the  tag
> > as you'd still have full backwards compatibility.
> >
> What accessibility features, exactly? For compatibility, the deepest
> child of  would be , inheriting the accessibility
> features of img. Alternatively, it might just as well be markup, which
> is surely better accessibility wise than @alt and @longdesc.
> Furthermore, you could theoretically link to an animation, a still and
> a sound and embed a hypertext fallback.
> (I'm sorry if 's being generally terrible for accessibility
> has been established already.)


Because browsers about now understand how to display an image in the
object tag, and so won't do anything with the nested image inside of it,
thus negating any benefit of the alt tag within it. Adding images that
way would prevent modern browsers from being accessible.

-- 
Thanks,
Ash
http://www.ashleysheridan.co.uk

Re: [whatwg] add html-attribute for "responsive images"

[Matthew Wilcox]

I don't have the expertise on exactly how these things function, but from
my "common sense" approach to it surely the browser has to have encountered
the  opening tag before it can encounter the  tag in order to
read the source URL for that image. At which point, would the browser not
know to apply the "don't load an img if it's in a " behaviour?

And if that's not the case, can we not argue the case to vendors that the
pre-fetch behaviour needs to take this into account because it's the
pre-fetch behaviour that is causing the harm here?



On 7 February 2012 10:37, Anselm Hannemann  wrote:

> As far as I understand browsers like Chrome preparse sites where they
> don't actually get the DOM but load resources they find in code. So it
> would be impossible to say it shouldn't be loaded.
> See this comment about it:
> http://www.alistapart.com/comments/responsive-images-how-they-almost-worked-and-what-we-need/P40/#41
>
> Am 07.02.2012 um 11:34 schrieb Matthew Wilcox:
>
> Can you clarify why the image would be loaded twice?
>
> Can we not, as part of the logic for the  element, say that 
> is ignored in supporting browsers? Thus, never called by a supporting
> browser. Non supporting browsers wouldn't load the  elements and would
> only load the 
>
> Right?
>
> On 7 February 2012 10:31, Anselm Hannemann  wrote:
>
>> Am 07.02.2012 um 11:16 schrieb Matthew Wilcox:
>>
>> 2012/2/7 Anselm Hannemann – Novolo Designagentur 
>>
>>> Ashley,
>>>
>>> so you think about the  element attributes like I proposed?
>>> >> media-m="(min-device-width:640px and max-device-width:1024px)"
>>> media-src-m="myimage_m.jpg" media-xl="(min-device-width:1024px)"
>>> media-src-xl="myimage_xsl.jpg">
>>> (View as gist: https://gist.github.com/1158855)
>>>
>>
>> This, to me, is WAY too over-wrought to be useful. Readability is a
>> feature of HTML and this kind of kills that a little - it looks like
>> something some automated solution would spit out, not what a human would
>> author. I can't imagine it getting much uptake with web developers for that
>> reason alone (I put my hand up, I'm a member of that fickle bunch).
>>
>>
>> Yeah this is indeed true. I just want this as an option which is a
>> semantically valid approach. But you're totally right at readability.
>>
>> To me this makes most sense /from an author perspective/ (I make no
>> claims as to how practical this really is):
>>
>> 
>>   > media="min-width:320" />
>>   > media="min-width:480" />
>>   > media="min-width:640" />
>>
>>   
>>   
>> 
>>
>> The reason being:
>>
>> * it's easy to read
>> * it uses familiar element structures and properties
>> * it allows us to adjust to any given media requirement, not just screen
>> size (you could query bandwidth with this syntax, though I contest
>> bandwidth is the domain of server side adaption rather than client side)
>>
>>
>> This is a good solution except the fallback img element would be twice
>> loaded in your case which is not good.
>> There should be the img element containing the standard (normal) size and
>> src elements to add diff. other resolutions. With that the browser won't
>> load the resource twice.
>>
>
>
>

Re: [whatwg] add html-attribute for "responsive images"

[Anselm Hannemann]

As far as I understand browsers like Chrome preparse sites where they don't 
actually get the DOM but load resources they find in code. So it would be 
impossible to say it shouldn't be loaded.
See this comment about it: 
http://www.alistapart.com/comments/responsive-images-how-they-almost-worked-and-what-we-need/P40/#41

Am 07.02.2012 um 11:34 schrieb Matthew Wilcox:

> Can you clarify why the image would be loaded twice?
> 
> Can we not, as part of the logic for the  element, say that  is 
> ignored in supporting browsers? Thus, never called by a supporting browser. 
> Non supporting browsers wouldn't load the  elements and would only load 
> the 
> 
> Right?
> 
> On 7 February 2012 10:31, Anselm Hannemann  wrote:
> Am 07.02.2012 um 11:16 schrieb Matthew Wilcox:
> 
>> 2012/2/7 Anselm Hannemann – Novolo Designagentur 
>> Ashley,
>> 
>> so you think about the  element attributes like I proposed?
>> > media-m="(min-device-width:640px and max-device-width:1024px)" 
>> media-src-m="myimage_m.jpg" media-xl="(min-device-width:1024px)" 
>> media-src-xl="myimage_xsl.jpg">
>> (View as gist: https://gist.github.com/1158855)
>> 
>> This, to me, is WAY too over-wrought to be useful. Readability is a feature 
>> of HTML and this kind of kills that a little - it looks like something some 
>> automated solution would spit out, not what a human would author. I can't 
>> imagine it getting much uptake with web developers for that reason alone (I 
>> put my hand up, I'm a member of that fickle bunch).
> 
> Yeah this is indeed true. I just want this as an option which is a 
> semantically valid approach. But you're totally right at readability.
> 
>> To me this makes most sense /from an author perspective/ (I make no claims 
>> as to how practical this really is):
>> 
>> 
>>   > media="min-width:320" />
>>   > media="min-width:480" />
>>   > media="min-width:640" />
>> 
>>   
>>   
>> 
>> 
>> The reason being:
>> 
>> * it's easy to read
>> * it uses familiar element structures and properties
>> * it allows us to adjust to any given media requirement, not just screen 
>> size (you could query bandwidth with this syntax, though I contest bandwidth 
>> is the domain of server side adaption rather than client side)
> 
> This is a good solution except the fallback img element would be twice loaded 
> in your case which is not good.
> There should be the img element containing the standard (normal) size and src 
> elements to add diff. other resolutions. With that the browser won't load the 
> resource twice.
> 

Re: [whatwg] add html-attribute for "responsive images"

[Matthew Wilcox]

Can you clarify why the image would be loaded twice?

Can we not, as part of the logic for the  element, say that 
is ignored in supporting browsers? Thus, never called by a supporting
browser. Non supporting browsers wouldn't load the  elements and would
only load the 

Right?

On 7 February 2012 10:31, Anselm Hannemann  wrote:

> Am 07.02.2012 um 11:16 schrieb Matthew Wilcox:
>
> 2012/2/7 Anselm Hannemann – Novolo Designagentur 
>
>> Ashley,
>>
>> so you think about the  element attributes like I proposed?
>> > media-m="(min-device-width:640px and max-device-width:1024px)"
>> media-src-m="myimage_m.jpg" media-xl="(min-device-width:1024px)"
>> media-src-xl="myimage_xsl.jpg">
>> (View as gist: https://gist.github.com/1158855)
>>
>
> This, to me, is WAY too over-wrought to be useful. Readability is a
> feature of HTML and this kind of kills that a little - it looks like
> something some automated solution would spit out, not what a human would
> author. I can't imagine it getting much uptake with web developers for that
> reason alone (I put my hand up, I'm a member of that fickle bunch).
>
>
> Yeah this is indeed true. I just want this as an option which is a
> semantically valid approach. But you're totally right at readability.
>
> To me this makes most sense /from an author perspective/ (I make no claims
> as to how practical this really is):
>
> 
>media="min-width:320" />
>media="min-width:480" />
>media="min-width:640" />
>
>   
>   
> 
>
> The reason being:
>
> * it's easy to read
> * it uses familiar element structures and properties
> * it allows us to adjust to any given media requirement, not just screen
> size (you could query bandwidth with this syntax, though I contest
> bandwidth is the domain of server side adaption rather than client side)
>
>
> This is a good solution except the fallback img element would be twice
> loaded in your case which is not good.
> There should be the img element containing the standard (normal) size and
> src elements to add diff. other resolutions. With that the browser won't
> load the resource twice.
>

Re: [whatwg] add html-attribute for "responsive images"

[Anselm Hannemann]

Am 07.02.2012 um 11:16 schrieb Matthew Wilcox:

> 2012/2/7 Anselm Hannemann – Novolo Designagentur 
> Ashley,
> 
> so you think about the  element attributes like I proposed?
>  media-m="(min-device-width:640px and max-device-width:1024px)" 
> media-src-m="myimage_m.jpg" media-xl="(min-device-width:1024px)" 
> media-src-xl="myimage_xsl.jpg">
> (View as gist: https://gist.github.com/1158855)
> 
> This, to me, is WAY too over-wrought to be useful. Readability is a feature 
> of HTML and this kind of kills that a little - it looks like something some 
> automated solution would spit out, not what a human would author. I can't 
> imagine it getting much uptake with web developers for that reason alone (I 
> put my hand up, I'm a member of that fickle bunch).

Yeah this is indeed true. I just want this as an option which is a semantically 
valid approach. But you're totally right at readability.

> To me this makes most sense /from an author perspective/ (I make no claims as 
> to how practical this really is):
> 
> 
>media="min-width:320" />
>media="min-width:480" />
>media="min-width:640" />
> 
>   
>   
> 
> 
> The reason being:
> 
> * it's easy to read
> * it uses familiar element structures and properties
> * it allows us to adjust to any given media requirement, not just screen size 
> (you could query bandwidth with this syntax, though I contest bandwidth is 
> the domain of server side adaption rather than client side)

This is a good solution except the fallback img element would be twice loaded 
in your case which is not good.
There should be the img element containing the standard (normal) size and src 
elements to add diff. other resolutions. With that the browser won't load the 
resource twice.

Re: [whatwg] add html-attribute for "responsive images"

[Matthew Wilcox]

@Mathew Marquis - that was a good article, I was so pleased to see the
thinking behind it getting some attention at last! I've been trying to push
this idea since launching adaptive-images.com , and a number of people have
come up with the same client-side quasi-solution independently. Bruce
Lawson's mark-up suggestion was the first example I'm aware of and I've
linked to it on the list before.


2012/2/7 Anselm Hannemann – Novolo Designagentur 

> Ashley,
>
> so you think about the  element attributes like I proposed?
>  media-m="(min-device-width:640px and max-device-width:1024px)"
> media-src-m="myimage_m.jpg" media-xl="(min-device-width:1024px)"
> media-src-xl="myimage_xsl.jpg">
> (View as gist: https://gist.github.com/1158855)
>

This, to me, is WAY too over-wrought to be useful. Readability is a feature
of HTML and this kind of kills that a little - it looks like something some
automated solution would spit out, not what a human would author. I can't
imagine it getting much uptake with web developers for that reason alone (I
put my hand up, I'm a member of that fickle bunch).

To me this makes most sense /from an author perspective/ (I make no claims
as to how practical this really is):


  
  
  

  
  


The reason being:

* it's easy to read
* it uses familiar element structures and properties
* it allows us to adjust to any given media requirement, not just screen
size (you could query bandwidth with this syntax, though I contest
bandwidth is the domain of server side adaption rather than client side)

Re: [whatwg] add html-attribute for "responsive images"

[Ashley Sheridan]

On Tue, 2012-02-07 at 10:49 +0100, Anselm Hannemann – Novolo
Designagentur wrote:

> Ashley,
> 
> so you think about the  element attributes like I proposed?
>  media-m="(min-device-width:640px and max-device-width:1024px)" 
> media-src-m="myimage_m.jpg" media-xl="(min-device-width:1024px)" 
> media-src-xl="myimage_xsl.jpg">
> (View as gist: https://gist.github.com/1158855)
> 
> Or did I misunderstood you?
> -Anselm
> 
> Am 07.02.2012 um 10:45 schrieb Ashley Sheridan:
> 
> > On Mon, 2012-02-06 at 23:15 +, Bjartur Thorlacius wrote:
> > 
> >> On Mon, 06 Feb 2012 21:23:37 -, Mathew Marquis   
> >> wrote:
> >>> I recently published a sum-up of our thinking at A List Apart (  
> >>> http://www.alistapart.com/articles/responsive-images-how-they-almost-worked-and-what-we-need/
> >>>   
> >>> )—in short, using the  markup pattern as the inspiration, with  
> >>> the use of media attributes on the  elements to determine the  
> >>> rendered source, and the inclusion of an --ideally a smaller image,  
> >>> to account for the lowest-common-denominator--as a fallback similar to  
> >>> the way Flash or an image might be used as a  fallback.
> >>> 
> >> Why not use a media attribute of ? That way you should get media  
> >> type disambiguation for free.
> > 
> > 
> > The main problem I see with that is that the  tag doesn't have
> > the same accessibility attributes, so you'd effectively lock out a lot
> > of people using browsers that don't understand the context of the tag in
> > this case. I think the better way is to add something to the  tag
> > as you'd still have full backwards compatibility.
> > 
> > -- 
> > Thanks,
> > Ash
> > http://www.ashleysheridan.co.uk
> > 
> > 
> 


Yeah, that seems along the right lines to me, although I'd probably not
use the media-xs type attributes, and just instead use one attribute
with comma delimited value parameters like:



It does look ugly, but I think it's easier to only need to remember one
attribute rather than a bunch; the fewer changes required for this to
work would surely be better?

-- 
Thanks,
Ash
http://www.ashleysheridan.co.uk

Re: [whatwg] RWD Heaven: if browsers reported device capabilities in a request header

[Matthew Wilcox]

On 7 February 2012 00:12, Jason Grigsby  wrote:

> I agree that this is a problem. I’ve spent far too much time trying to
> find solutions for images in responsive designs and none that I reviewed
> work. (research at http://cloudfour.com/responsive-imgs-part-2).
>

Seconded, my work has been http://adaptive-images.com


> But I find the arguments that Henri Sivonen made against putting the
> information in the header to be compelling:
>
> http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-February/034642.html
>


>
> FWIW, there was an RFC back in 1996 describing a similar request:
> http://tools.ietf.org/html/draft-mutz-http-attributes-01
>
> Personally, I’d rather see a new element or a new image format a la the
> "add html-attribute for 'responsive images'" thread going on right now. Or
> if it is headers, I’d like to see something that is more inclusive and
> could be used for servers requesting different information instead of
> codifying something only for screen size.
>

Absolutely agree that we should not be concentrating on one specific thing.
What I want is the ability to have the server ask for whatever info it
needs about the client device/environment, and have that sent as a header.
And only sent if the server has asked. I don't mean we want "screen size"
alone, that is but one example of something the server might care about.
Bandwidth is another, as is viewport size, and I am sure there are a lot
more. I want to see a *communication method* defined here, not a one-issue
semi-solution to an overly specific example of what is in reality a much
broader problem (the server not having reliable information about the
client).

-Jason


Also, as I've mentioned whenever I talk about this stuff: server side is
ONE half of the solution. The other is new HTML. They do two different
things, and they appear superficially similar when they aren't. Server side
adaptation is about the times when it's right for the server to take
automated action based on the client's capabilties: e.g., sending lower
quality graphics when it detects the bandwidth is low. Mark-up solution is
about sending actual different URLs. e.g., an about page mug-shot. At high
device sizes this may be a full-length body shot. At smaller sizes it's not
practical to simly shrink it as you no longer recognise what's important,
so you substitute a head and shoulders shot for lower screen sizes.
Different content that's doing the same semantic job.

Re: [whatwg] add html-attribute for "responsive images"

[Anselm Hannemann – Novolo Designagentur]

Ashley,

so you think about the  element attributes like I proposed?

(View as gist: https://gist.github.com/1158855)

Or did I misunderstood you?
-Anselm

Am 07.02.2012 um 10:45 schrieb Ashley Sheridan:

> On Mon, 2012-02-06 at 23:15 +, Bjartur Thorlacius wrote:
> 
>> On Mon, 06 Feb 2012 21:23:37 -, Mathew Marquis   
>> wrote:
>>> I recently published a sum-up of our thinking at A List Apart (  
>>> http://www.alistapart.com/articles/responsive-images-how-they-almost-worked-and-what-we-need/
>>>   
>>> )—in short, using the  markup pattern as the inspiration, with  
>>> the use of media attributes on the  elements to determine the  
>>> rendered source, and the inclusion of an --ideally a smaller image,  
>>> to account for the lowest-common-denominator--as a fallback similar to  
>>> the way Flash or an image might be used as a  fallback.
>>> 
>> Why not use a media attribute of ? That way you should get media  
>> type disambiguation for free.
> 
> 
> The main problem I see with that is that the  tag doesn't have
> the same accessibility attributes, so you'd effectively lock out a lot
> of people using browsers that don't understand the context of the tag in
> this case. I think the better way is to add something to the  tag
> as you'd still have full backwards compatibility.
> 
> -- 
> Thanks,
> Ash
> http://www.ashleysheridan.co.uk
> 
> 

Re: [whatwg] RWD Heaven: if browsers reported device capabilities in a request header

[Matthew Wilcox]

Can I suggest you read
http://24ways.org/2011/adaptive-images-for-responsive-designs-again then
please?

It does not work "fine" at all.

Cheers,
-Matt

On 6 February 2012 20:23, Charles Pritchard  wrote:

> Scripting on the client side works just fine. It's pure markup situations
> where you run into problems.
>
> I'm well aware that Image nodes are alive. I'm keeping an eye out on the
> DOMParser method to see if they're alive when it parses as text/html.
>
> I recently wrapped some noscript tags around HTML image nodes to prevent
> them from blocking my onload. Works fine.
>
>
> -Charles
>
>
>
> On Feb 6, 2012, at 12:16 PM, Matthew Wilcox 
> wrote:
>
> >>
> >> Scripting on the client side for the purposes of content negotiation
> *does
> >> not work*
> >>
> > Please, understand this. Because browsers pre-fetch as soon as a node is
> >> created there can be no client-side solution to this issue with the
> current
> >> HTML/JS specifications and browser behaviour. The image linked in the
> HTML
> >> is *always* requested, and it is requested before the client can do a
> >> damned thing about it.
> >>
> >
> >
> >>
> >> On 6 Feb 2012, at 20:03, Charles Pritchard wrote:
> >>
> >>> On Feb 6, 2012, at 11:49 AM, Boris Zbarsky  wrote:
> >>>
>  On 2/6/12 2:26 PM, Bjartur Thorlacius wrote:
> > On Mon, 06 Feb 2012 18:59:14 -, Boris Zbarsky 
> >> wrote:
> >> That really depends on what the application is doing. Depending on
> >> input capabilities, you may want to have multiple pages instead of a
> >> single page for some sort of configuration setup, for example.
> >>
> > Whether to use monolithic forms or paginated wizards is a
> presentation
> > thing
> 
>  Not on the HTML level.  Not if you want to allow useful non-scripted
> >> semantic submission of partially-filled-in info in the paginated case.
> 
> > that need not even have anything to do with HTTP. You can fetch
> > half the monolithic form and fetch the rest when the user has filled
> in
> > most of former half.
> 
>  Not without script.
> >>>
> >>>
> >>> I really didn't like the consequences of server-side scripting to
> manage
> >> dependencies. It was always more work than simply doing the scripting in
> >> the client side. It was more prone to error. It let our coders get away
> >> with less rugged design.
> >>>
> >>> I'm in the responsive and universal design camp. I'm in the
> >> accessibility camp. At present, it does require scripting. I'm building
> web
> >> apps, so, scripting comes with that territory.
> >>>
> >>>
> >>> It seems to me like these folk are looking for  and
> 

Re: [whatwg] add html-attribute for "responsive images"

[Ashley Sheridan]

On Mon, 2012-02-06 at 23:15 +, Bjartur Thorlacius wrote:

> On Mon, 06 Feb 2012 21:23:37 -, Mathew Marquis   
> wrote:
> > I recently published a sum-up of our thinking at A List Apart (  
> > http://www.alistapart.com/articles/responsive-images-how-they-almost-worked-and-what-we-need/
> >   
> > )—in short, using the  markup pattern as the inspiration, with  
> > the use of media attributes on the  elements to determine the  
> > rendered source, and the inclusion of an --ideally a smaller image,  
> > to account for the lowest-common-denominator--as a fallback similar to  
> > the way Flash or an image might be used as a  fallback.
> >
> Why not use a media attribute of ? That way you should get media  
> type disambiguation for free.


The main problem I see with that is that the  tag doesn't have
the same accessibility attributes, so you'd effectively lock out a lot
of people using browsers that don't understand the context of the tag in
this case. I think the better way is to add something to the  tag
as you'd still have full backwards compatibility.

-- 
Thanks,
Ash
http://www.ashleysheridan.co.uk

Re: [whatwg] RWD Heaven: if browsers reported device capabilities in a request header

[James Graham]

On 02/06/2012 11:05 PM, Boris Zbarsky wrote:

On 2/6/12 3:20 PM, James Graham wrote:

1) Same URL structure as the main site


OK, makes sense.


2) Less (only citical) information on each screen


Why not do this for the "desktop" version as well?

Alternately, if it's nice to see the information at a glance on desktop,
why not make the UI such that this information is at the top in both
versions and the less-critical information is effectively below the fold
on mobile? I realize that this may be more work and that there may be
other constraints here, but it seems like that would be ideal in this
situation.


This basically amounts to "the requirements were wrong". Since the same 
developer made both the desktop and mobile frontends and he is one of 
the major users of the system, and the mobile frontend was purely 
scratching his own itch, I find it very difficult to justify the 
position that he ought to have wanted something different to what he 
actually wanted and made.


In general the idea that sites/applications should be essentially the 
same, but perhaps slightly rearranged, regardless of the device they run 
on just doesn't seem to be something that the market agrees with. It 
seems to me that we can either pretend that this isn't true, and watch 
as platform-specific apps become increasingly entrenched, or work out 
ways to make the UX on sites that target multiple types of hardware as 
good as possible.



3) No looking up / transfering information that would later be thrown
away


Again, this seems to apply to desktop as well.


Of course. The critical point was that there was different information 
in the two cases. The unacceptable solution here would have been to 
compute the union of all possible information required but only display 
the relevant subset.



4) Fast => No extra round trip to report device properties


Agreed that this is desirable.


This is the only property that is currently hard to achieve in 
conjunction with the others. If one gives up this requirement one can 
simply download a minimal framework, detect whatever device properties 
you like through the DOM and then pull down the rest of the site. The 
only problem is that this introduces — possibly significant — extra 
latency. One can avoid this by browser sniffing. Which never causes 
problems. Obviously.


So it seems to me that we have a problem that real people are hacking 
their way around by using techniques that are known to be suboptimal or 
downright harmful. Therefore we should take the desire for a solution 
seriously, even though I agree that sending the device screen size, or 
some sort of nebulous "device class" in the HTTP header isn't good enough.