Re: [whatwg] Proposal: tag for Web Intents API

2012-01-25 Thread Paul Kinlan 
Understood.  The case still stands that we can use the  tag in
the body, have script fallback if the publisher decides to add the
shim by way of adding the dom Element or just always including the
proxy code - or just have a nice piece of text/dom for some other
fallback mechanism of completing the action (such as a link to a
scriptlet).  We don't get this ability with the other methods
discussed ( - ).

Note: I added a script element inside a video element and a supporting
browser still executed the code.  It is a shame because I think it is
a nice solution (in theory).

P

On Wed, Jan 25, 2012 at 5:14 PM, Charles Pritchard  wrote:
> On 1/25/2012 5:06 PM, Paul Kinlan wrote:
>>
>> [Merging the digest reply from Charles]
>
>
> Thanks, sorry about breaking the subject line.
>
> For others: this mini thread is in relation to  src=""> behavior.
>
>
>> I would prefer to treat it like a embedded content element [1] and
>> have the intent spec define how fallback content should be presented
>> and parsed - so we would define that

Re: [whatwg] Proposal: tag for Web Intents API

2012-01-25 Thread Charles Pritchard 

On 1/25/2012 5:06 PM, Paul Kinlan wrote:

[Merging the digest reply from Charles]


Thanks, sorry about breaking the subject line.

For others: this mini thread is in relation to src=""> behavior.



I would prefer to treat it like a embedded content element [1] and
have the intent spec define how fallback content should be presented
and parsed - so we would define that

Re: [whatwg] The placeholder attribute

2012-01-25 Thread Ian Hickson 
On 22 and 24 Sep 2011, Bjartur Thorlacius wrote:
>
> The semantics of the placeholder and title attributes of inputs overlap 
> slightly; the placeholder attribute may contain a hint to aid the user, 
> while title is to contain "other advisory text." I can think of two 
> valid uses of placeholder: example value, and the text "click here to 
> type" or "enter search query here." The latter is obviously user 
> interface that should be implemented by interactive user agents. Then 
> there is the third use, use it as a title attribute (but with richer 
> presentation).
>
> Users might want values falling under the first to be prefixed with 
> "e.g.", "for example" or equivalent - but by allowing the latter use 
> forces authors to add it to all example values, rather than letting the 
> user's style sheet take care of it. Thus I suggest narrowing the 
> semantics of the attribute to example values, allowing for easier 
> styling by users (or agents, on their behalf). The second one should 
> have no valid representation. Lastly, the specification should make it 
> clearer what the title attribute is appropriate for; a description of 
> the input or format.
> 
> Also, I see no reason to suggest not rendering the text when the input 
> is focused - in special on 1D devices such as speech - considering that 
> JavaScript dependent sites (such as Hotmail) have placed example values 
> in a small font below the input so that it can be visible while the user 
> is typing, and, more importantly, after the input has been focused 
> (whether automatically or manually), but before the user starts typing.
> 
> As for the argument against using the title attribute for everything 
> that it would break existing sites, I do believe rendering the title 
> attribute of an empty and unfocused input inside of it is an improvement 
> over displaying a tooltip a second or two after the user positions a 
> cursor over the input (irrespective of focus). How on Earth is anyone to 
> think of doing that? Displaying the title attribute in a floating box in 
> a margin when an input is focused, followed by the example value 
> prefixed with "e.g." would be my preferred rendering, but that's just my 
> opinion.

> Should @placeholder be renamed @eg, and used exclusively for example 
> input?

I think you're overthinking it. :-)

In theory, the main differences between title="" and placeholder="" is 
that title="" can be longer and would be shown on request, while 
placeholder="" is shorter, shown as part of the input feature, typically 
only when there's no input already, and would be specifically about the 
input format.

In practice, on visual media, this means title="" is a tooltip and 
placeholder="" is an inline caption.


> P.S. The last paragraph of the section on the pattern attribute links 
> twice to . Should it not link to 
> ?

Fixed, thanks.

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

Re: [whatwg] Erroneous description of h1, h2, h3, etc. elements on Whatwg.org

2012-01-25 Thread Ian Hickson 
On Wed, 21 Sep 2011, Etienne Levesque Guitard wrote:
>
> Hello Community,
> 
> I've noticed that under section 4.4.6 of the HTML5 spec on
> Whatwg.org,
> the description of h1, h2, h3, etc. is as follows:
> 
> *These elements have a rank given by the number in their name. The h1
> element is said to have the highest rank, the h6 element has the lowest
> rank, and two elements with the same name have equal rank.*
> 
> I propose a rewrite to this in order to cover changes in HTML5:
> 
> *Unless they are contained within a section element, these elements have a
> rank given by the number in their name. The h1 element has the highest rank
> while the h6 element has the lowest rank. When used with the section
> element, the rank is determined by the nesting level of the given heading
> element within section elements.*
> *
> *
> I think this makes it more explicit for readers of the spec who won't go on
> section 4.4.11 to know exactly what the semantics mean.

Actually the rank applies even in a  element. Otherwise, things 
would stop working if you did:

   
My Section
My subsection
   

The rank concept is used to figure out the relative level of the headings 
in the document as a whole, it's not the end of the story. You can't just 
ignore the outline section, that's the section that says what the outlines 
mean.

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

Re: [whatwg] Shadows

2012-01-25 Thread Ian Hickson 
On Wed, 14 Sep 2011, Martijn wrote:
> On Jan 15, 2008 8:51 AM, Ian Hickson  wrote:
> > On Thu, 17 May 2007, Martijn wrote:
> > >
> > > Is how to render shadows defined here?
> > > http://www.whatwg.org/specs/web-apps/current-work/#shadows0
> > > So with that piece of text it is clear how to render shadows in canvas?
> >
> > I agree that it is a bit vague, but do you have any specific suggestions
> > as to what it should say exactly? I'm not sure what to write.
> 
> Not really, I may had some ideas but I can't remember.
> Maybe that part should just be removed then?

Well, we need _something_ to say how the shadows are rendered, so in the 
absence of any specific proposals for something better, what is there now 
seems better than nothing...

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

Re: [whatwg] Detached elements and delaying the load event

2012-01-25 Thread Ian Hickson 
On Tue, 6 Sep 2011, Andrew Oakley wrote:
>
> I'm going to use the  element as an example here, but the same 
> thing applies to other elements such as , , .
> 
> I'm going to assume that the user agent "obtains the images 
> immediately", given that seems to be what most browsers do.
> 
> If an img element is created and given a src attribute (but not 
> necessarily attached to the tree) then, according to HTML5, we need to 
> "update the image data" and therefore delay the load event.  I guess 
> this means we should lock the image element in a similar fashion to 
> XMLHttpRequest objects, otherwise the image could be garbage collected 
> before it has been loaded and therefore block the load event 
> indefinitely.
> 
> Firefox, Opera, Chrome and Safari do seem to implement this behaviour, 
> IE does not.
> 
> I would prefer not to implement this and just say "detached elements do 
> not delay the load event", but I'm not sure if that will always work.
> 
> Can we please get a clarification in HTML5, either to say that these 
> detached objects must not be garbage collected while they are delaying 
> the load event, or to say that they do not delay the load event.

Done for .

 and  already had requirements to this effect.

 outside a document doesn't initiate a load, so it's case is 
different.

Let me know if I missed anything.

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

[whatwg] Requests for new elements for comments

2012-01-25 Thread Ian Hickson 
On Sun, 4 Sep 2011, Shaun Moss wrote:
> 
> I've joined this list to put forward the argument that there should be 
> elements for  and  included in the HTML5 spec.

We already have an element for comments and other self-contained document 
modules, namely, . The spec in fact specifically calls out an 
 nested in another  as being, by definition, a comment 
on the outer .

For advertisments, I do not think it makes sense to add an element. In 
practice, it would likely not end up being used, since doing so would make 
it too easy to hide advertisments.

However, the  element is a close fit for the semantic, so I would 
recommend using that.


> Please also let me know the process for submitting a formal proposal to 
> the WHATWG or the W3C about this.

This is it.


On Mon, 5 Sep 2011, Shaun Moss wrote:
> 
> A suggested semantic meaning for : /The content of this element 
> has been contributed by a website user in reference to an article, 
> discussion topic, status update, image, video, or some other item of 
> content./

This is basically exactly the semantic for a nested .


On Mon, 5 Sep 2011, Shaun Moss wrote:
> > 
> > http://www.whatwg.org/specs/web-apps/current-work/multipage/sections.html#the-article-element
> 
> Yes, but this is not semantic!!! Comments are not articles.

 isn't just for articles. That's the point.

Note that its name is irrelevant here. It could be called  -- 
what matters is what it is defined to mean, not what it's name is. And 
it's definition is one that covers both articles and comments. They are 
both self-contained compositions.


> They are completely different.

Actually, they are remarkably similar. I think it's anachronistic to 
consider that the utterances of the site owner are in some way distinct 
from the utterances of the site readers. What makes them different?

On the contrary, on the Web there _is_ no difference. An article is just a 
comment that has been hoisted to a more prominent position.


> Comments can appear in reference to things that are not articles (such 
> as status updates), and therefore would not appear inside an  
> tag - so how would the browser recognise them as comments?

Status updates are another example of something that would be appropriate 
in .

On Mon, 5 Sep 2011, Shaun Moss wrote:
> 
> Please explain to me how it makes sense for a comment to stand on its 
> own.

Reddit is a great example of this.

Every comment on reddit has its own permalink and can be referenced alone.

Consider this page:

   
http://www.reddit.com/r/webdev/comments/ito6v/html5_article_tag_for_ecommerce_products/

It starts with a comment by iamfuzzydunlop. That's the "topic" article, 
for lack of a better phrase. Below that are other comments in response, 
for example holizz says "An interesting question.". You can see that 
article -- er, comment -- on its own page:

   
http://www.reddit.com/r/webdev/comments/ito6v/html5_article_tag_for_ecommerce_products/c26kn8g

Here it is standing on its own.


> To an HTML author, especially a newbie, an article *is* a newspaper 
> article, and this is entirely distinct from a user-submitted comment 
> related to the article. Semantics isn't just for robots, it's for 
> humans, too - a fact that seems to be frequently overlooked. Giving 
> elements obscure, unobvious meanings in the spec is a kludge, plain and 
> simple. For example, to the WHATWG and W3C the  tag now basically 
> means "different but not important". The ,  and  tags have 
> similarly gained bizarre new definitions. To everyone else on the 
> planet, however,  means bold,  means italic,  means underline 
> and  means strikethrough. This may come as a surprise, but 99.9% of 
> HTML authors don't read specs. They look at a tag, and think, now what 
> would I use that for? "Ok, so the  tag is for tables, right? I 
> guess  is for articles, then. Oh, it's for user-submitted 
> comments, too? wtf?"

Unfortunately, it is basically impossible for a single word -- or even a 
single letter -- to stand for a careful description of an element's 
semantics. While I agree that most authors won't read the specs, one can 
at least hope that authors will use quick-reference sheets that do include 
the basic definitions of the elements. Some authors might even refer to 
more comprehensive documentation such as:

   http://developers.whatwg.org/


> We don't need a whole slew of new tags. We need *one*: , and /maybe/
> one more: , to wrap them.

 covers a wide range of semantics:

 - forum posts
 - newspaper articles
 - magazine articles
 - books
 - blog posts
 - comment on a forum post
 - comment on a newspaper article
 - comment on a magazine article
 - comment on a blog post
 - an embeddable interactive widget
 - a post with a photograph on a social network
 - a comment on a photograph on a social network
 - a specification
 - an e-mail
 - a reply to an e-mail

Should each of these get its own element?



On Tue, 6 Sep 2011, Shaun Moss wrote:
> On 2011-09-05 11:13 PM, B

Re: [whatwg] whatwg Digest, Vol 94, Issue 44

2012-01-25 Thread Charles Pritchard 

On 1/25/12 7:39 AM, whatwg-requ...@lists.whatwg.org wrote:

>  Generally, I think that often a hybrid approach to Canvas, where you draw
>  into multiple Canvas elements and use CSS transforms, animations (and now
>  filters) for positioning and effects can give you the best of both worlds...
>

I disagree. I would much rather see filter functionality available to both
Canvas and CSS. That functionality is clearly in both Canvas' and CSS'
wheelhouses, and since they are both implemented by the browser vendor, why
not have that low-level functionality available to both Canvas and CSS? It
seems crazy to me to have that low-level code sitting in the browser and
then restrict it to CSS. Why would anyone want to do that?



Implementers may run shaders on the GPU.

You don't want to have your canvas bitmap uploaded to the gpu, filtered, 
then sent back to the cpu. There are undefined issues on quality. The 
image may be compressed in transit. The CSS layer is a very much 
separated from the Canvas rasterization process. This is a good thing.


I did ask about adding filters to Canvas years ago, I think in '09. So I 
want you to know, I am supportive. I worked on a large project with 
dozens of filters and blend modes atop Canvas and WebGL.


I want to write pixel shaders in JS so as to maintain backward 
compatibility and use the pixel shader with CSS semantics.


It does not help with the low level code issue you're talking about. But 
that's an area that's always been difficult. We have no direct access to 
deflate, either, nor many of the other low-level code assets sitting in 
the browser. With deflate, we could reasonably construct RGB and Indexed 
PNGs. But we don't have it, and that's ok.


Robert O has done a lot of work on Workers running filters on an  
stream:

https://dvcs.w3.org/hg/audio/raw-file/tip/streams/StreamProcessing.html

We can extend that proposal to work on Uint8ClampedArray (previously, 
CanvasPixelArray) and/or a Uint32Array.
It may be more efficient to treat the data as a Uint32Array. Fast is 
good. It'd work on  and .


JS with typed arrays, especially Uint32Array, can be optimized very well 
by the compiler, and it can run across multiple cores. It's unlikely 
that the hard coded UA implementation of a few filter effects will have 
the long-term value of script shaders.


-Charles

Re: [whatwg] autocompletetype vs autocomplete, type attributes

2012-01-25 Thread Kornel Lesiński 


Google's annoucement of autocompletetype type[1] uses type="text" field  
for e-mail input, which doesn't seem right given that HTML has type="email"> already.


Should  behave just like  
? Similar ambiguity exists for autocompletetype=phone-full> and .



Why not fold autocompletetype types into the existing type attribute (or  
autocomplete attribute)? Type could be redefined as space-separated list,  
so  could work just  
like autocompletetype. It would be backwards compatible with HTML5 types  
and fall back to text for new types or lists.


Having all of type, autocomplete and autocompletetype looks quite messy.

[1]  
http://googlewebmastercentral.blogspot.com/2012/01/making-form-filling-faster-easier-and.html


--
regards, Kornel Lesiński

Re: [whatwg] CSS Filter Effects for Canvas 2D Context

2012-01-25 Thread Tab Atkins Jr. 
On Wed, Jan 25, 2012 at 6:41 AM, David Geary  wrote:
> On Tue, Jan 24, 2012 at 5:22 PM, Chris Marrin  wrote:
>> Adding filter functions to canvas would require you to re-render the items
>> for every filter change and you'd have to animate it all yourself.
>
> Sure, but you must create a superfluous canvas for each set of images that
> you animate, and invoke an entirely different technology to apply the
> filter. You must  make sure that those superfluous canvases have
> transparent backgrounds, no borders, and have the correct Z order so they
> appear over, and not under, the primary canvas for the application. And I'm
> sure there are other gotchas to this hybrid approach that don't immediately
> come to mind.
>
> I'd much rather use the filtering underlying API and control the rendering
> and animation myself.

Yes, it's effectively creating an ad-hoc retained-mode API out of
multiple  elements solely so it can apply filtering.

(Using multiple backing canvases to sprite things is a reasonable
performance hack, but I don't think it should be required for basic
functionality.)

~TJ

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

2012-01-25 Thread Matthew Wilcox 
It's also worth noting another use case for this being in mark-up and not
just server-negotiated rescaling of a single image:

Imagine a profile photo on an About page. At large sizes you want to use a
full body shot, at smaller sizes you need to retain what's important but no
longer clear at small scales: a recognisable face - so you substiture a
head and shoulders shot.

That's a strong use case where the semantic meaning of the content is the
same but requires a different resource to be properly conveyed at differing
scales.

On 25 January 2012 15:27, Markus Ernst  wrote:

> Am 25.01.2012 15:07 schrieb Matthew Wilcox:
>
>  In fact, please just read the blog post Bruce Lawson (Opera Software)
>> made summarising the last few months of effort on this, and his proposal
>> for a mark-up level solution (which I'm in broad support of, though there
>> are a lot of knotty issues with any potential solution - as can be seen by
>> the volume of blog-posts, comments, and articles on the topic):
>>
>> http://www.brucelawson.co.uk/**2011/notes-on-adaptive-images-**yet-again/
>>
>
> I would like to propose a use case different from the ones in this
> blog-post: Scaled images.
>
> The more physical screen densities improve, the less image pixels actually
> correspond to device pixels, and thus scaling images will be less a
> problem. E.g., designers might want to define an image size in em units
> rather than in px, so it keeps its relation to the text size.
>
> This use case requires a negotiation based on the dimensions of the image
> element rather than the dimensions of the media. It would be nice if a
> solution to the responsive images problem would address this use case, too.
> AFAICS this would require a more general syntax for the conditions.
>
>  On 25 January 2012 13:42, David Goss  wrote:
>>
>>> I'm proposing this (adapted from Bruce Lawson's  idea, and
>>> similar
>>>
>>> to how the  element works):
>>>
>>> 
>>>
>>>
>>>
>>>
>>> 
>>>
>>
> If the introduction of a new element is an option, it could also be the
> other way around, as image maps work:
>
> 
> 
>  
>  
> 
>
> To address my above use case, I replaced the media attribute with a more
> general cond attibute, which can take a condition with a selector and a
> rule. The selector can be the keyword "media" or a CSS selector, and the
> rule either a min-width and/or max-width declaration, or some statement
> about network speed or whatever, such as:
>
> 
> 
> or:
> 
> or:
> 
> or:
> 
>

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

2012-01-25 Thread Markus Ernst 

Am 25.01.2012 15:07 schrieb Matthew Wilcox:

In fact, please just read the blog post Bruce Lawson (Opera Software)
made summarising the last few months of effort on this, and his proposal
for a mark-up level solution (which I'm in broad support of, though there
are a lot of knotty issues with any potential solution - as can be seen by
the volume of blog-posts, comments, and articles on the topic):

http://www.brucelawson.co.uk/2011/notes-on-adaptive-images-yet-again/


I would like to propose a use case different from the ones in this 
blog-post: Scaled images.


The more physical screen densities improve, the less image pixels 
actually correspond to device pixels, and thus scaling images will be 
less a problem. E.g., designers might want to define an image size in em 
units rather than in px, so it keeps its relation to the text size.


This use case requires a negotiation based on the dimensions of the 
image element rather than the dimensions of the media. It would be nice 
if a solution to the responsive images problem would address this use 
case, too. AFAICS this would require a more general syntax for the 
conditions.



On 25 January 2012 13:42, David Goss  wrote:

I'm proposing this (adapted from Bruce Lawson's  idea, and similar
to how the  element works):









If the introduction of a new element is an option, it could also be the 
other way around, as image maps work:





  
  


To address my above use case, I replaced the media attribute with a more 
general cond attibute, which can take a condition with a selector and a 
rule. The selector can be the keyword "media" or a CSS selector, and the 
rule either a min-width and/or max-width declaration, or some statement 
about network speed or whatever, such as:




or:

or:

or:

Re: [whatwg] CSS Filter Effects for Canvas 2D Context

2012-01-25 Thread Boris Zbarsky 

On 1/25/12 3:41 PM, David Geary wrote:

On Tue, Jan 24, 2012 at 5:22 PM, Chris Marrin  wrote:

You can apply CSS Filters to a Canvas element. Maybe it would be better to
put the items you want filtered into a separate canvas element and use CSS
Filters on that? The big advantage of doing it that way is that the CSS
filters can be animated and hardware accelerated.


That advantage fixes a problem that shouldn't exist: You shouldn't have to
choose one technology over another because one is hardware accelerated.
That's ridiculous.


Indeed.  Especially since what's accelerated and what's not is likely to 
be UA-dependent and not be time-invariant, moving in the direction of 
more and more things being accelerated.


-Boris

Re: [whatwg] CSS Filter Effects for Canvas 2D Context

2012-01-25 Thread David Geary 
On Tue, Jan 24, 2012 at 5:22 PM, Chris Marrin  wrote:

>
> On Jan 24, 2012, at 11:56 AM, Ronald Jett wrote:
>
> > I think that bringing the new CSS filters (
> http://html5-demos.appspot.com/static/css/filters/index.html) to canvas
> might be a good idea. Some of the new filters, specifically blur, would
> definitely speed up some applications. I saw that there was a previous
> discussion on this list about bringing SVG filters to canvas, but it was a
> few years back and it doesn't seem like the discussion yielded much.
> >...
> > Thoughts?
>
> You can apply CSS Filters to a Canvas element. Maybe it would be better to
> put the items you want filtered into a separate canvas element and use CSS
> Filters on that? The big advantage of doing it that way is that the CSS
> filters can be animated and hardware accelerated.


That advantage fixes a problem that shouldn't exist: You shouldn't have to
choose one technology over another because one is hardware accelerated.
That's ridiculous.


> Adding filter functions to canvas would require you to re-render the items
> for every filter change and you'd have to animate it all yourself.
>

Sure, but you must create a superfluous canvas for each set of images that
you animate, and invoke an entirely different technology to apply the
filter. You must  make sure that those superfluous canvases have
transparent backgrounds, no borders, and have the correct Z order so they
appear over, and not under, the primary canvas for the application. And I'm
sure there are other gotchas to this hybrid approach that don't immediately
come to mind.

I'd much rather use the filtering underlying API and control the rendering
and animation myself.


> Generally, I think that often a hybrid approach to Canvas, where you draw
> into multiple Canvas elements and use CSS transforms, animations (and now
> filters) for positioning and effects can give you the best of both worlds...
>

I disagree. I would much rather see filter functionality available to both
Canvas and CSS. That functionality is clearly in both Canvas' and CSS'
wheelhouses, and since they are both implemented by the browser vendor, why
not have that low-level functionality available to both Canvas and CSS? It
seems crazy to me to have that low-level code sitting in the browser and
then restrict it to CSS. Why would anyone want to do that?


David
corehtml5canvas.com


>
> -
> ~Chris
> cmar...@apple.com
>
>
>
>
>

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

2012-01-25 Thread Matthew Wilcox 
Ugh, my Gmail keeps sending mail from the wrong address, let me try again:

...

In fact, please just read the blog post Bruce Lawson (Opera Software)
made summarising the last few months of effort on this, and his proposal
for a mark-up level solution (which I'm in broad support of, though there
are a lot of knotty issues with any potential solution - as can be seen by
the volume of blog-posts, comments, and articles on the topic):

http://www.brucelawson.co.uk/2011/notes-on-adaptive-images-yet-again/

...

I should add that relying on mobile-networks compressing images is not a
good enough solution either. Firstly, they don't always. Secondly, this is
about performance and device capability not mobile network behaviour.

Personally I think media should respond to detected connection speed and/or
device capabilities. That involves equipping HTML with the ability to
detect those things which is a big ask. But, I feel, very worth while in
terms of future-proofing. I'm all for headers being sent with all HTTP
requests to inform the server of device details - allowing the server to
choose appropriately. But, we also need a mark-up level solution. They're
not the same problem though superficially they appear similar.

On 25 January 2012 13:42, David Goss  wrote:

> On Tue, 24 Jan 2012 23:26, Ian Hickson wrote:
>
> >
> > What's the use case for doing it for images in  elements? Typically
> >  elements are for content images, where you don't usually want to
> > adapt anything.
> >
> > On Tue, 30 Aug 2011, Karl Dubost wrote:
> > >
> > > And as I explained elsewhere it is not a question of
> high/low-resolution
> > > only, but about interaction contexts. Different images for different
> > > surface sizes.
> > >
> > > Desktop: Show a full photo of Anne van Kesteren riding on a plane
> > 1024*250 px
> > > Tablet: Show the photo a closer shot of the plane (cowboy frame)
> >  400*150 px
> > > Mobile: Show a portrait of Anne with his leather pilot helmet 100x100
> px
> >
> > I don't understand the use case. For something like a user profile icon
> > surely it would be rather bad UI to use a different icon on different
> > devices. I presume you don't mean a profile icon though, since 1024x250
> is
> > a bit excessive for an icon these days, and I'm not aware of any site
> that
> > lets users pick different icons for different size contexts.
> >
>
> The use case is that you want to serve the same image (same content) to all
> users, but you want to serve it in different resolutions depending on their
> context to avoid wasting bandwidth and killing performance (especially on
> mobile devices where performance is key - you don't want to download a
> 1000px-wide image when you're scaling it down to 320px wide to display it).
>
> Karl's example is on dangerous ground, IMO. The different sizes of the
> image could be slightly cropped/zoomed as appropriate, but should still
> clearly represent the same thing - in other words, the same alt text should
> correctly describe all of them.
>
>
> > On Wed, 31 Aug 2011, Bjartur Thorlacius wrote:
> > >
> > > Bottom (top?) line: User agents should negotiate an appropriate
> > > message-body size using HTTP. Sending an accept-size (or some such)
> > > could solve both the problem of high resolution photography and lengthy
> > > documents. The amount of split articles ("Click here to go to the next
> > > page / page 4") and long search results show clear demand.
> >
> > I don't think that really works. You wouldn't want to get different
> > results if I started with a small window vs starting with a big window
> and
> > narrowing it. It should adapt in realtime.
> >
>
> I agree: this needs to be done in markup, not on the server with headers.
> Not that users resize their browsers all that much (except orientation
> changes on phones and tablets). But, yeah.
>
>
> > Note that "resolution" and "number of pixels on the screen" are
> orthogonal
> > issues. Also, note that the number of pixels on the screen is irrelevant,
> > it's the number of pixels on the viewport that matters.
> >
> > My phone has a far higher resolution than my TV, but has the same number
> > of pixels. My phone also has a higher resolution than my desktop, but
> > windows on my desktop typically have far more pixels.
> >
>
> You're right - all pixels are not equal. The solution I'm going to propose
> involves media queries, so things like device-pixel-ratio can be used to
> address that issue.
>
> I'm proposing this (adapted from Bruce Lawson's  idea, and similar
> to how the  element works):
>
> 
>
>
>
>
> 
>
> Yep, another new element: . It doesn't have any attributes of
> its own (except the standard ones). It must contain one  element,
> which the author will furnish with an alt attribute and whatever else as
> normal. It then contains one or more  elements, each with a media
> attribute containing a valid media query.
>
> The user agent should cycle through each  element in order,
> updating the s

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

2012-01-25 Thread David Goss 
On Tue, 24 Jan 2012 23:26, Ian Hickson wrote:

>
> What's the use case for doing it for images in  elements? Typically
>  elements are for content images, where you don't usually want to
> adapt anything.
>
> On Tue, 30 Aug 2011, Karl Dubost wrote:
> >
> > And as I explained elsewhere it is not a question of high/low-resolution
> > only, but about interaction contexts. Different images for different
> > surface sizes.
> >
> > Desktop: Show a full photo of Anne van Kesteren riding on a plane
> 1024*250 px
> > Tablet: Show the photo a closer shot of the plane (cowboy frame)
>  400*150 px
> > Mobile: Show a portrait of Anne with his leather pilot helmet 100x100 px
>
> I don't understand the use case. For something like a user profile icon
> surely it would be rather bad UI to use a different icon on different
> devices. I presume you don't mean a profile icon though, since 1024x250 is
> a bit excessive for an icon these days, and I'm not aware of any site that
> lets users pick different icons for different size contexts.
>

The use case is that you want to serve the same image (same content) to all
users, but you want to serve it in different resolutions depending on their
context to avoid wasting bandwidth and killing performance (especially on
mobile devices where performance is key - you don't want to download a
1000px-wide image when you're scaling it down to 320px wide to display it).

Karl's example is on dangerous ground, IMO. The different sizes of the
image could be slightly cropped/zoomed as appropriate, but should still
clearly represent the same thing - in other words, the same alt text should
correctly describe all of them.


> On Wed, 31 Aug 2011, Bjartur Thorlacius wrote:
> >
> > Bottom (top?) line: User agents should negotiate an appropriate
> > message-body size using HTTP. Sending an accept-size (or some such)
> > could solve both the problem of high resolution photography and lengthy
> > documents. The amount of split articles ("Click here to go to the next
> > page / page 4") and long search results show clear demand.
>
> I don't think that really works. You wouldn't want to get different
> results if I started with a small window vs starting with a big window and
> narrowing it. It should adapt in realtime.
>

I agree: this needs to be done in markup, not on the server with headers.
Not that users resize their browsers all that much (except orientation
changes on phones and tablets). But, yeah.


> Note that "resolution" and "number of pixels on the screen" are orthogonal
> issues. Also, note that the number of pixels on the screen is irrelevant,
> it's the number of pixels on the viewport that matters.
>
> My phone has a far higher resolution than my TV, but has the same number
> of pixels. My phone also has a higher resolution than my desktop, but
> windows on my desktop typically have far more pixels.
>

You're right - all pixels are not equal. The solution I'm going to propose
involves media queries, so things like device-pixel-ratio can be used to
address that issue.

I'm proposing this (adapted from Bruce Lawson's  idea, and similar
to how the  element works):








Yep, another new element: . It doesn't have any attributes of
its own (except the standard ones). It must contain one  element,
which the author will furnish with an alt attribute and whatever else as
normal. It then contains one or more  elements, each with a media
attribute containing a valid media query.

The user agent should cycle through each  element in order,
updating the src of the  accordingly if the media query is matched. If
there are no  elements, or none of the media queries are matched,
the original src on the  is used. Only after this logic has completed
should the HTTP request for the image file take place (so there are no
wasted downloads). The media queries I've used in the example are very
simple, using just min-width and max-width, but in reality authors would
often include other things such as device-pixel-ratio and color/monochrome.

Non-supporting UAs would simply ignore the new elements and render the
 as normal, but the structure would allow authors to implement a
JavaScript polyfill if desired.

To be clear, all the s should point to different sizes of the same
image — otherwise the content is being changed, which isn't what we're
looking to do here. In other words, the same alt attribute should correctly
describe all the s.

I'm sure there's a lot I haven't thought of, but hopefully this is a good
start. Thoughts?

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

2012-01-25 Thread Matthew Wilcox 
Please see responses inline:

On 24 January 2012 23:26, Ian Hickson  wrote:

> On Wed, 24 Aug 2011, Anselm Hannemann - Novolo Designagentur wrote:
> >
> > As we now have the possibility of creating fluid and responsive layouts
> > in several ways we have a problem with images.
> >
> > There's currently no good feature to implement something like responsive
> > images which adapt to the different device-resolutions. We only can
> > implement one image with one resolution scaling-up and down.
>
> You can do adaptive sites using media queries.
>
>   
>   My Site
>
>   // CSS
>   @media (min-width: 320px and max-width: 640px) {
> h1::before { content: url(http://cdn.url.com/img/myimage_xs.jpg) }
>   }
>   @media (min-width: 640px and max-width: 1024px) {
> h1::before { content: url(http://cdn.url.com/img/myimage_m.jpg) }
>   }
>   @media (min-width: 1024px) {
> h1::before { content: url(http://cdn.url.com/img/myimage_xsl.jpg) }
>   }
>
>
This is of no use to content images - which are the real problem. CSS
supplied images are not an issue.


>
> On Tue, 30 Aug 2011, Karl Dubost wrote:
> >
> > It is easy to do right now with background images, but not at all for
> > images in  element.
>
> What's the use case for doing it for images in  elements? Typically
>  elements are for content images, where you don't usually want to
> adapt anything.
>

Sorry, you couldn't be more wrong. Content images need to adapt because of
the performance problems with mobile. Huge effort has been expended in the
community to answer this problem - mobiles should not be delivered the same
sized images as desktop, even though the semantic value of the images are
the same. What we are talking here is device-appropriate re-scaled versions
of the same image. This saves bandwidth and allows phones with weak
hardware to perform acceptably. For more on the issue please read
http://adaptive-images.com,
http://24ways.org/2011/adaptive-images-for-responsive-designs,
http://www.brucelawson.co.uk/2011/notes-on-adaptive-images-yet-again/, or
http://filamentgroup.com/lab/responsive_images_experimenting_with_context_aware_image_sizing/to
name but a few recent in-depth articles on exactly this requirement.

Or to look at the extreme hoops we have to jump through for a client-side
solution read
http://24ways.org/2011/adaptive-images-for-responsive-designs-again - it is
not pretty.


> On Tue, 30 Aug 2011, Karl Dubost wrote:
> >
> > And as I explained elsewhere it is not a question of high/low-resolution
> > only, but about interaction contexts. Different images for different
> > surface sizes.
> >
> > Desktop: Show a full photo of Anne van Kesteren riding on a plane
> 1024*250 px
> > Tablet: Show the photo a closer shot of the plane (cowboy frame)
>  400*150 px
> > Mobile: Show a portrait of Anne with his leather pilot helmet 100x100 px
>
> I don't understand the use case. For something like a user profile icon
> surely it would be rather bad UI to use a different icon on different
> devices. I presume you don't mean a profile icon though, since 1024x250 is
> a bit excessive for an icon these days, and I'm not aware of any site that
> lets users pick different icons for different size contexts.
>

With retina displays, don't be surprised to see icons around this size very
soon.


>
>
> On Wed, 31 Aug 2011, Bjartur Thorlacius wrote:
> >
> > Bottom (top?) line: User agents should negotiate an appropriate
> > message-body size using HTTP. Sending an accept-size (or some such)
> > could solve both the problem of high resolution photography and lengthy
> > documents. The amount of split articles ("Click here to go to the next
> > page / page 4") and long search results show clear demand.
>
> I don't think that really works. You wouldn't want to get different
> results if I started with a small window vs starting with a big window and
> narrowing it. It should adapt in realtime.
>

By re-requesting image resources after re-scale? That's not performant. But
I do agree that it'd be nicer to getreal-time resource re-requests, if only
the penalty didn't involve page layout jumps. The fact os, it's rare anyone
resizes the browser. The adaptive image agenda is mostly about supporting
massively differing viewport sizes and device configurations. Dynamic
rescaling is a side-agenda.


>
>
> On Tue, 6 Sep 2011, Ashley Sheridan wrote:
> >
> > Yes, but the point is, the alternative images you may want to display
> > for visitors on a smaller screen/resolution could be completely
> > different from the original image (cropped shot not showing all the
> > detail, etc).
>
> Note that "resolution" and "number of pixels on the screen" are orthogonal
> issues. Also, note that the number of pixels on the screen is irrelevant,
> it's the number of pixels on the viewport that matters.
>

Yes and no. It depends on how the image request happens. For example, AI
(linked above) cares only about the number of pixels on the screen. Why?
Because given HTML at the moment yo