- From: Martin Kliehm <martin.kliehm@namics.com>
- Date: Fri, 18 Dec 2009 12:58:10 +0100
- To: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- CC: Cynthia Shelly <cyns@microsoft.com>, HTML Accessibility Task Force <public-html-a11y@w3.org>
Martin wrote: >> I believe since nobody objects @datetime and <time> in its two >> manifestations, using it as an analogy may help to get the point >> through. Leif wrote in reply: > It is easier, probably, for an developer to programmatically update the > date than to do the same with @summary. My point was that two different methods, an attribute and an element, exist for datetime. Therefore we can have the same for summary. Your point addresses the *quality* of the summary text. Yes, it's true from a developer standpoint: generated text is more likely to be correct than manually edited text. But in all other content we trust writers, why wouldn't we apply the same here? In my experience default summary text is often the result of a missing integration of an editable field in the CMS or missing support in the WYSIWYG editor. Somebody thought of it in the template, but it never made it into the CMS. But when it's visible in the CMS, authors will try to write something meaningful in it. This is also interesting in regard of the visibility discussion: the summary is *always* visible in the CMS. > As for <summary> as direct child of <table>, if that was your idea, > then this is just another variant of an invisible @summary Oh, I see, backwards compatibility. Yes, I agree <summary> needs to be inserted where current browsers will display the content. @Laura thanks for pointing me to the Wiki, I wasn't aware of that page. I'm glad the PFWG recommended something similar. Cheers, Martin
Received on Friday, 18 December 2009 11:58:56 UTC