Re: Current state of the summary discussion

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