RE: Adaptive Image Element Proposal

Adrian Roselli, Thu, 30 Aug 2012 19:07:26 +0000:
>> From: Leif Halvard Silli
>>> Adrian Roselli, Thu, 30 Aug 2012 18:24:54 +0000:
>>>> From: Leif Halvard Silli
>> 

>> I should add that I had some kind of automated duplication mind, so 
>> that the author don't ned to think about the issue, especially
>> the issue of keeping in sync.
> 
> I had the same thing in mind.

Well, let's hope, of course. To aria-labelledby's advantage is that it 
is a global attribute.

> Web content isn't just created by web developers. So very much of it 
> is created in browsers with WYSIWYG controls that something like 
> Dreamweaver (if it even has ARIA support) only goes so far. In the 
> case of a CMS, the vast majority of that content is being entered by 
> non-web folk, which means they are using WYSIWYG editors like CKedit 
> (which does not have any ARIA that I could find) and others.

This is a good point, I agree. However, e.g. in CKEditor 4 (beta), it 
is simply to fake it: Just ad the content of the next line as the sole 
content of the class attribute, for instance:

" aria-labelledby="parent

And voila, you have split the attribute. 

> I am trying to keep in mind the marketing assistant who has to upload 
> a press release and embed a picture as part of it. He/she is likely 
> doing it via a CMS and a browser-based WYSIWYG. Those are the tools 
> about which I am most concerned.

So how do you think he/she would add <picture> *and* the <img> element 
as child? May be it is could work if (s)he adds img first, and then 
wraps an <picture> around it? Hm ... It is some time since I used 
CKeditor ... But I see that its is possible to add a link in its image 
tool. So, OK, they could perhaps add picture element capability to the 
the same tool. I agree - it is possible.

>>>>>>  <figure>
>>>>>>   <ficaption>Caption</figcaption>
>>>>>>    <picture>
>>>>>>     <source src=files >
>>>>>>     <img src=file >
>>>>>>    </picture>
>>>>>>  </figure>

>> OK. Then check the figure element example in the section "Graphical
>> representation of some of the surrounding text". [1] Or try the 
>> validator. [2]
> 
> I must be confused about your example. 4.8.1.1.6 leads off with the 
> statement "[T]he alt attribute must be present but its value must be 
> the empty string." That tells me there must still be an @alt on the 
> <img>. Your validator example appears to say the same thing.

Let's take it again. Regarding the validation example shows two things: 
First it contains a figure element, like the above, but without the 
<picture> - just the <img>. That validates. Then it contains the same 
<img> element OUTSIDE the figure element. THat does not validate. This 
was done to make you get the point faster. Sorry that it confused you. 
As for the spec text: If you read the entire 4.8.1.1.6 (until 4.8.1.1.7 
begins) - or use a search tool - then you will get to read about figure.

> I am of the opinion that in your example the <img> should have an 
> @alt.

OK. Strictly speaking, the above example is not covered by HTML5, yet, 
so.

> According to the new <picture> proposal, the <picture> should 
> also have an @alt of the same value as the <img>. I'm not seeing 
> anything in the spec that disagrees with the first part of what I 
> said, so perhaps we aren't talking about the same thing?

You just have to read it again:

>> [1]
>> 
http://dev.w3.org/html5/spec/the-img-element.html#a-graphical-representation-of-some-of-the-surrounding-text
>> [2] http://tinyurl.com/validinsidefigure
-- 
leif halvard silli

Received on Friday, 31 August 2012 02:19:36 UTC