- From: Leif Halvard Silli <lhs@malform.no>
- Date: Tue, 04 Aug 2009 02:24:02 +0200
- To: Ian Hickson <ian@hixie.ch>
- CC: Sam Ruby <rubys@intertwingly.net>, HTML WG <public-html@w3.org>
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: > > http://lists.w3.org/Archives/Public/public-html/2009Jul/0148 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 @summary. 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