Re: CHANGE PROPOSAL: Table Summary

On Dec 9, 2009, at 4:50 PM, John Foliot wrote:

> Cynthia Shelly wrote:
>>
>>
>> <cyns>
>> This says to show it by default *in authoring scenarios*.  For a  
>> current
>> browser, that would generally mean on things that are content- 
>> editable.
>> For a visual authoring tool, it would render in the editing/design
>> surface, but not in previews.  I'd like to get general agreement here
>> that this is a good idea, and then I'll happily take it to the IE  
>> team
>> and various authoring tools teams.  It sounds like you think it's a  
>> good
>> idea.  Is that correct?  Anyone else?  Anyone hate it?
>> </cyns>
>
> I believe it is both a good idea, and an idea that has been floating
> around in various forms, suggested by various folks, including both  
> myself
> and as I recall Matt May.  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.  Previously I had suggested a 'right-click' kind of
> functionality (knowing full well that this is a windows-centric
> suggestion, but a similar type of functionality could be achieved in  
> all
> of the major OSes)

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

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.

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

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.

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

Regards,
Maciej

Received on Thursday, 10 December 2009 01:04:52 UTC