- From: Maciej Stachowiak <mjs@apple.com>
- Date: Wed, 09 Dec 2009 17:04:18 -0800
- To: John Foliot <jfoliot@stanford.edu>
- Cc: 'Cynthia Shelly' <cyns@microsoft.com>, 'Ian Hickson' <ian@hixie.ch>, 'HTML Accessibility Task Force' <public-html-a11y@w3.org>
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