Re: [whatwg] The <pic> element

On 1 cze 2012, at 00:58, Anselm Hannemann Web Development <info@anselm-hannemann.com> wrote:

>> • Improved alternative text — allows structured fallback, avoids duplication.
> This is where I do not agree. If you use MQ style with <source> you have a messy markup when writing alternative text inside the pic-element.

Since <source> is not read nor displayed, it doesn't matter. You can simply treat entire content as fallback. 

> Alt-text should always be in an attribute and this would also be easier for screenreaders etc.

Structure is there to aid screen readers. 

See http://lists.w3.org/Archives/Public/public-whatwg-archive/2012May/0216.html

>>    <pic src="portrait.jpg (orientation:portrait), landscape.jpg">alt text</pic>
>> 
>> Selects image based on orientation of the device.
> 
> Why won't you do this with separate attributes?
> Of course this is much shorter to write but it confuses the masses of developers because this is not a familiar HTML/CSS-pattern.
> I would like to see it this style which is much more common:
> 
> <pic src-xs="small.jpg" media-xs="(max-width:15em)" src-xl="large.jpg" alt="alt text" title="title text"></pic>

I don't mind either way, but this seems a bit more noisier and less compact. 

<source> can be an option for authors who prefer separate attributes.

>> Embeds image at 192dpi (default scaling is 2x, possible to override with CSS).
>> Same as `<pic src="image.jpg 2x">alt text</pic>` or
>> `<img src="100x100px" width="50" height="50" alt="alt text">`.
> Why is default scaling 2x? A default image should always be @1x, right?

We already have element for 1x images – <img>

In the future 1x displays will be low-end minority and 2x will be the norm. It'll be annoying for designers that the default looks terribly and every page always needs the bad default overridden. 

I'm trying to avoid need for yet another opt-out from the past like doctype and <meta charset>.
It'd be great if in 10-20 years all you had to do is type <pic src> instead of <img src> to get first-class support for hires images. 

To address Tab's concern the default is connected to image-resolution in CSS, so you can change it if you need to:

http://lists.w3.org/Archives/Public/public-whatwg-archive/2012May/0398.html

>> (I'm not sure if `<source>` should allow microsyntax in `src` `<source src="b 3x">` instead of `resolution="3x"`)
> I don't think so. It is much easier to have separate attributes. But what about extending the media-attr so we can write: 
> 
> <source src="b" media="3x">

Resolution descriptor is not a media query. I'd like to make that clear — it's not merely an abbreviation of min-device-pixel-ratio, it's a property of the image — more similar to width/height attributes. 

>> An `<img>` element can be used in place of any `<source>`. `width`/`height` defines size to display selected image at, but does not take part in selection of alternatives.
> If you could take the alt-text into pic and source I fully'll agree. You should be able to specify an alt-tag for every source if needed (in most use cases it isn't but in some it is if you have another crop with same meaning but different contents)

Alt is not supposed to be description of the image. It's supposed to be alternative content to be used instead. 

e.g. not "red triangle with exclamation mark" but "warning!"

So different alternative for each source would imply that purpose/meaning of the content changes with viewport size, and that'd be weird — content read to the user would change based on size of the window that a screen reader user may not even see?


>> The common syntax for use with JS polyfills is expected to be:
>> 
>>    <pic src="…"><noscript><img src="…" alt="…"></noscript></pic>
>> ##In formal terms
>> 
>> The `<pic>` element requires closing tag. The content is interpreted as a fallback for UAs that don't support `<pic>` or don't display the image (fallback includes text in <img alt> inside <pic>).
> I wouldn't necessary require a closing tag if you use the short syntax because the alt-text should be in attribute.

Void element is not an option due to backwards compatibility.

>> If there are commas or backslashes in the URL they must be escaped with `\`.
> This is another problem why I would separate the diff. srces.
> Escaping an URL is not something that should be necessary in HTML I think.

I agree, it's ugly, but otherwise you get ambiguous syntax for entries without descriptor or media query. 

I thought about specifying some magic, like ignoring trailing comma in URL, but all such magical solutions have surprising edge cases. Explicit escaping is at least easy to comprehend. 

>> * `media` — same as `media` part in `<pic src>`
>> * `resolution` — same as `resolution` part in `<pic src>`
>> * `src` — single URL without escaping or microsyntax
>> * `width` and `height` — analogous to `<img width/height>` for each alternative image
> * alt
> * title
> are missing IMO.

title is global, so available for <pic> too. Might be worthwhile to specify how title on <source> behaves.

As I've mentioned earlier I think it's not appropriate to have alt for non-visual agents vary based on visual properties. 

> What about 
> * usemap
> * ismap
> ?

Aren't these "legacy" features?

-- 
regards, Kornel

Received on Friday, 1 June 2012 18:25:43 UTC