Re: additional sentence for 204

Janina, one more point:

A so far unmentioned issue, even in my map clarification letter,[1] is 
this: What if the <map> that @usemap points to fails to contain <area> 
elements? Yeah, let's imagine that the <map> only contained 
non-interactive elements.

Per HTML5, the <img> would then be an interactive element, despite the 
lack of interactive content in the <map>. To me it sounds as if Ted's 
and James' text allows this. And the HTML5 validator also blesses it. 
But is this what you want to imply? It would be an entire new way of 
using @usemap and map. Such a use would be like turning a hidden <map> 
into some kind of - well - long description container. It is a possible 
use, but it might be considered a hack - perhaps. That said, one 
solution to the issues that I take up,[1] could perhaps be to say that 
the 'reveal hidden="" <map> at user request' mechanism is only supposed 
to be valid whenever there are no <area> elements inside the <map>.

[1] 
http://www.w3.org/mid/20120918011221114332.35925f1d@xn--mlform-iua.no

Leif H Silli

Leif Halvard Silli, Tue, 18 Sep 2012 17:41:46 +0200:
> Hi Janina,
> 
> the discussion deemed the @for/@id relationship between <label> and 
> <input> to be unsuitable as basis for revealing anything. This was 
> based on a concrete evaluation, though it also contained some 
> general/principle based arguments.
> 
> I agree that the @headers/@id relationship is OK. But for <map>, then I 
> have pointed out a number of issues.[1] I personally would love to be 
> able to include @usemap/@name in this mechanism. However I think the 
> issues that I have pointed out, should be evaluated. May be they can be 
> solved. Or may be you find my arguments invalid? Please have a look.
> 
> [1] 
> http://www.w3.org/mid/20120918011221114332.35925f1d@xn--mlform-iua.no
> 
> Leif Halvard Silli
> 
> Janina Sajka, Tue, 18 Sep 2012 10:36:58 -0400:
>> Hi, Leif:
>> 
>> The intention of the language we're looking for is to allow software to
>> identify which hidden conten can be revealed to users at their request,
>> and which content cannot. If the id and href approach is insufficient
>> for that, then we would need a different approach. But, the approach
>> must be one that software can reliably use to distinguish between the
>> two use cases of hidden content.
>> 
>> Janina
>> 
>> 
>> Leif Halvard Silli writes:
>>> Leif Halvard Silli, Mon, 17 Sep 2012 22:40:25 +0200:
>>> 
>>>> ]]
>>>>  Note: Only hidden="" elements that are referenced indirectly by a 
>>>>  unique identifier (ID) reference or valid hash-name reference may 
>>>>  have their structure and content exposed upon user request.<zzz>Note
>>>>  that  this functionality means that the only certain way to prevent 
>>>>  user-initiated viewing of hidden="" elements is to remove the 
>>>>  identifier (ID) or hash-name reference to the element in question.
>>>>  </zzz>
>>>> [[
>>> 
>>> Hm - I am not satisfied with my own text there. Retry:
>>> 
>>> <zzz>
>>> If an author would like to prevent all user-initiated viewing of 
>>> hidden="" elements, a removal of the identifier (ID) or the hash-name 
>>> reference would be necessary. But note that such a removal in some 
>>> cases also has semantic side-effects for the element from which it is 
>>> removed. For example if a @usemap attribute was removed, the 
>>> <code>object</code> or <code>img</code> element from which it was 
>>> removed, would change from interactive content to a normal graphic.
>>> </zzz>
>>> 
>>> Leif H Silli
>> 
>> -- 
>> 
>> Janina Sajka,	Phone:	+1.443.300.2200
>> 			sip:janina@asterisk.rednote.net
>> 		Email:	janina@rednote.net
>> 
>> The Linux Foundation
>> Chair, Open Accessibility:	http://a11y.org
>> 
>> The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
>> Chair,	Protocols & Formats	http://www.w3.org/wai/pf
>> 	Indie UI			http://www.w3.org/WAI/IndieUI/
>> 
>

Received on Tuesday, 18 September 2012 16:05:11 UTC