RE: Finalizing an Issue-204 CP

Benjamin Hawkes-Lewis wrote:
> 
> > For example, it would be incorrect to use the href attribute to link
> to a section marked with the hidden attribute. Since the content is not
> rendered, linking to it</del> would have unpredictable
> behavior</del><ins>would result in behavior the user does not
> expect</ins> , either dropping the user at a location with no rendered
> content, or failing to navigate.
> 
> This still introduces a self-contradiction into the specifications,
> since the behavior is defined to navigate the user to a location with
> rendered content. There's no "or" and both your alternatives are
> wrong.

"Defined" where? Ben can you supply relevant references when you make these statements please. For ease of comprehension, direct quotes are also appreciated, with the reference URL then provided. Don't make us go hunting to find where you are reading (or misreading) these assertions. Thanks.


> 
> > <p class="note">Any structure in the referenced element, including
> headings, links, tables, paragraphs, and form elements, will be lost.
> The text children of the element will be flattened to a string. As such,
> authors should only use this technique <del>for string content</del>
> </ins>where such flattened content will provide a good user
> experience</ins>. At the time of this writing, some screen reader
> products will read both the accessible name and accessible description,
> so authors should take care with the length of text provided via this
> method.</p>
> 
> Where's the rationale for introducing such text under @hidden rather
> than in the ARIA specification or the WAI-ARIA section of the HTML5
> spec?

One rationale is that it is common practice throughout the HTML5 draft spec to provide warnings, advisories or "Notes" - in line - that provides relevant and pertinent advice to content creators (who may or may not go look in other documents). This is a philosophical debate that cannot delay the progress of this CP, with some who feel this is inappropriate, and others who feel it is "smart". That debate aside, this is how the current spec is being authored and presented.  Myself (and others) felt sufficiently strongly that this advisory be included in the replacement text that we were able to build a consensus position that it be included. You may or may not agree with this position, but consensus is not unanimity.


> 
> Saying "The text children of the element will be flattened to a
> string" is a direct contradiction of the ARIA specification which
> takes account of various elements and attributes in the calculation of
> the accessible name and description.

Again Ben, can you please supply relevant references when you make these statements. Show us where you are getting this from.


> 
> Markup is a "string" so "string" is the wrong word to use here:
> 
> http://en.wikipedia.org/wiki/String_(computer_science)

While this very much feels like a splitting of hairs, if you have a better definition / description of what we are talking about here, please be kind enough to provide that change. A criticism without an alternative is simply a waste of everyone's time (IMO) - and this is a time sensitive undertaking.


> 
> Also, you didn't explain why "should" is the appropriate conformance
> language here…
> 
> http://dev.w3.org/html5/spec/infrastructure.html#conformance-
> requirements

Do you have a reason why it shouldn't be "should"? Close the loop Ben, please. 

What rationale should we be considering (from your perspective) that would cause us to change the word "should" to something else? (And, FWIW, this is not authored as a RFC 2119 SHOULD - traditionally shown as ALL CAPS - but rather as the appropriate grammatical auxiliary or conditional verb, as opposed to can, might or may). I think you are reading more into the text than is there.

JF

Received on Saturday, 21 April 2012 05:08:27 UTC