11797 2011-01-19 00:42:49 +0000 Declarative way to get formatting UI for contenteditable="" (as in <video controls=""> but for text editing) 2013-03-19 14:24:50 +0000 1 1 1 Unclassified WebAppsWG HISTORICAL - HTML Editing APIs unspecified Other other NEW https://www.w3.org/Bugs/Public/show_bug.cgi?id=19058 P3 enhancement --- 1 contributor ayg ayg ian mail mike mounir public-html-admin public-html-wg-issue-tracking public-webapps robin sideshowbarker+html-editing-api oldest_to_newest 44457 0 contributor 2011-01-19 00:42:49 +0000 Specification: http://dev.w3.org/html5/spec/Overview.html Section: http://www.whatwg.org/specs/web-apps/current-work/#top Comment: <richtext> </richtext> This will provide a default rich text widget which is scriptable and should also support the Rich Text Format (RTF) Default widget implementation should be a text area with richtext controls above it. This will enable browsers to provide native support for rich / advanced text entry and editing. Posted from: 41.220.69.7 44465 1 ayg 2011-01-19 09:27:48 +0000 This is kind of an interesting suggestion, actually. Maybe this could be done by having some kind of "controls" attribute for contenteditable, à la video. 44513 2 mail 2011-01-20 14:37:39 +0000 contenteditable is such a poorly designed feature. It's essentially useless without Javascript. Its design is inherited from original proprietary implementations, and I'd like to think that if it had originated in the HTML WG instead, we'd have something much better. Something like: <textarea type="text/html">...</textarea> would be far preferable. 45655 3 ian 2011-02-16 08:18:48 +0000 IE5 had <richedit>, IIRC. Microsoft dropped it. Do we know why? It would be useful to find out what their reasoning was, to make sure we didn't make the same mistake. In the meantime, I'm going to mark this LATER since it's a _major_ new feature and now isn't a particularly convenient time to be adding new features. EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Partially Accepted Change Description: none yet Rationale: We should wait for implementations to catch up before adding new features, especially in the space of rich text editing where there's a lot of work to be done just in getting the existing features interoperably implemented. 53497 4 mike 2011-08-04 05:14:25 +0000 mass-move component to LC1 82025 5 public-rdfa-wg 2013-01-24 06:36:55 +0000 This bug was cloned to create HTML WG bug 19058. 84597 6 ian 2013-03-19 00:19:08 +0000 Moving this to the HTML Editing APIs spec for now. If this is something that makes sense to add, then I'll be happy to coordinate and provide the markup side of this, but really I think the HTML Editing APIs spec needs to be the place where we define what it does. 84611 7 ayg 2013-03-19 14:24:50 +0000 Note that the editing spec is not maintained right now, unless someone took it over when I wasn't looking.