Re: [DRAFT] Heartbeat poll - update 2

Ian Hickson On 09-08-04 00.17:


> I've explained in detail the reasoning behind the current text in the 
> spec, all that I ask is that the data or reasoning contradicting this be 
> explained to even a tenth of the level of detail:

In that message you discussed:


> Explanatory text [...≈] Before [or after] the table in the prose: 

 > ARIA attributes could be used to more tightly
 > couple the two to enable screen readers to provide a link
 > between them

Aria could probably also be attached to a new summary element, if 
need be in a transition period.

>  - Introducing a new [summary] element inside <caption> ...


> - Introducing a new [summary] element inside <figure> ...


> This would make sense if the summary content was rendered very differently 
> than other content in specific media, but in practice in ATs the summary 
> content is just read out like caption content,

Overlooking such the word "very", we could probably agree that 
most AT read @summary _different_ from the caption.

> so it wouldn't add much here,

It would make them distinguishable, which is what is required.

> and in other UAs the author would be able to just style it using 
> CSS. 

This should be simpler if there were a designated summary element, 
as the author then would not need to wonder which element to use 
or how to make it selectable (e.g. he/she would not need to use 
indirection - aka a class name  [a difficult task, you have told 
us many time] to select it).

With a summary element, we may even find a default styling that works.

>(Media queries can also be used to hide content specifically from 
> particular media, e.g. having text not appear on screen.)

This is also something that should favor a summary element: A 
simple to select element is also easier to handle via media queries.

You also discussed

> - Using the summary="" attribute from HTML4:

Surprisingly you did not suggest that the text of the summary 
attribute should be identical to the summary text (or the @aria 
tagged text) in the table. OTOH, this is not so strange, because 
if you had done that, then you had effectively been dealing with 
it as a deprecated - not obsolete - feature. In addition, as long 
as you do not introduce  a designated summary element, it is also 
impossible for UAs to make a link between the two features (e.g. 
so that they may ignore the one if they support both).

The current draft thus prevents authors from making a page that 
/both/ fulfills the new requirement (which is to stuff the summary 
into a freely selected element inside caption) as well as the old 
requirement (which is to use @summary). If anyone would try to do 
that, then the user would get the table summary twice - once as 
part of the caption, and once as part of the summary attribute.

Whereas if HTML 5 had introduced a _new_ summary _feature_ - aka a 
<summary> element - then the draft could require that the @summary 
should contain the same text as the summary element as well as 
requiring that UAs give priority to the new feature. It would then 
be simple to get feedback from a validator in case the text of the 
@summary differed from the text of the <summary>.

Thus, there is advantages to deprecating rather than obsoleting 

Regardless, the problems of _only_ using @summary (rather than 
introducing a new feature) should not need to be solved at this 
moment in time.
leif halvard silli

Received on Tuesday, 4 August 2009 00:24:45 UTC