Re: CHANGE PROPOSAL: Table Summary

Maciej Stachowiak, Wed, 09 Dec 2009 17:04:18 -0800:
> On Dec 9, 2009, at 4:50 PM, John Foliot wrote:
>> Cynthia Shelly wrote:
>>> This says to show it by default *in authoring scenarios*.  For a current
>>> browser, that would generally mean on things that are content-editable.
    [...]

>> It would be even *better* if the browsers/UI
>> allowed the end user to toggle 'display' on or off as determined by any
>> given user. [...]

> I think displaying the summary by default on tables in 
> contentEditable content is not a good idea. Here are some specific 
> reasons:

I note that you emphasize "by default".

By default, a GUI web browser identifies itself as of media type 
"screen". What if - when using content-editable - a user agents 
permitted that the user switches the identity to e.g. "screenreader" (a 
proposed media type) or "aural"/whatever? As I see it, it is not very 
useful to single out @summary as something that needs attention. By 
switching to a relevant media type, the user/author could get to also 
see other related issues for that media type.

Amaya is a browser-editor that allows you to change the media identity, 
in the preferences.

> 1) In general we try to make the layout and display provide 100% 
> visual and layout fidelity in contentEditable regions. We don't want 
> things to suddenly change appearance when you convert from editable 
> to not.

But actively switching the media type should work?

> 2) Inserting and editing normally-invisible information that lives in 
> attributes is normally done by editing toolkits written in JavaScript 
> that live on top of contentEditable. For example, if you want to add 
> a link and set the URL, then a toolkit like TinyMCE would have an 
> "add link" or "edit link" button that you

This doesn't seem far from the toggle that John had in mind.

> 3) contentEditable normally just edits text that's in contents, not 
> text from attributes. It would require significant work to be able to 
> not only display the text from the summary attribute but edit it in 
> place.
> 
> To give a specific example of this, MobileMe web mail uses 
> contentEditable mode. You can receive a Web page that way that was 
> created with a "Mail this Page" feature already containing a table. 
> Now let's say the user replies - it goes into editable mode and the 
> summary text for the table mysteriously appears. Then the user 
> forwards the email, and when the recipient sees it, the summary 
> disappears again. Or worse yet, the user may be confused and might 
> delete the summary, and if the recipient is blind they no longer have 
> benefit of the summary. This seems like a poor user experience. There 
> are many contentEditable use cases  like this where the unaware user 
> should not have it thrust upon them. We should leave it up to 
> higher-level JS editing libraries to deal with this, just as we do 
> for inserting links, editing images, etc.

But, if you reply to a message containing a table, then that table 
should be treated as a blockquote that was quoted literally and 
therefore should not be edited. Likewise, if you insert a table from 
some other source, the authors should have to do something extra if 
he/she really want to change it.

At any rate, if the summary would not be shown unless the user switched 
to a relevant mediatype, then this problem should not appear.

Btw, Mozilla Thunderbird supports summary on tables in html mail 
messages, as it uses the normal Mozilla editor "toolkit". Thunderbird 
(at least version 2 - version 3 was just released) will prompt you to 
add a alt description for an image that you inserts, but there is no 
prompt for summary for tables.

> Entering things like summary and alt text should be the province of 
> full-power authoring tools. It should not be enforced for 
> contentEditable mode.

Above you also mentioned "toolkits" as a way to access these features. 
But perhaps you consider e.g. TinyMCE as a "full-power" tool? 

I suppose that e.g. a blind author would like to have access to edit 
these features, and a blind user might also use contenteditable.
-- 
leif halvard silli

Received on Thursday, 10 December 2009 12:57:51 UTC