This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 11797 - Declarative way to get formatting UI for contenteditable="" (as in <video controls=""> but for text editing)
Summary: Declarative way to get formatting UI for contenteditable="" (as in <video con...
Status: NEW
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: HISTORICAL - HTML Editing APIs (show other bugs)
Version: unspecified
Hardware: Other other
: P3 enhancement
Target Milestone: ---
Assignee: Aryeh Gregor
QA Contact: HTML Editing APIs spec bugbot
URL: https://www.w3.org/Bugs/Public/show_b...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-01-19 00:42 UTC by contributor
Modified: 2013-03-19 14:24 UTC (History)
9 users (show)

See Also:

Attachments

Description contributor 2011-01-19 00:42:49 UTC 
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
Comment 1 Aryeh Gregor 2011-01-19 09:27:48 UTC 
This is kind of an interesting suggestion, actually.  Maybe this could be done by having some kind of "controls" attribute for contenteditable, à la video.
Comment 2 Toby Inkster 2011-01-20 14:37:39 UTC 
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.
Comment 3 Ian 'Hixie' Hickson 2011-02-16 08:18:48 UTC 
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.
Comment 4 Michael[tm] Smith 2011-08-04 05:14:25 UTC 
mass-move component to LC1
Comment 5 public-rdfa-wg 2013-01-24 06:36:55 UTC 
This bug was cloned to create HTML WG bug 19058.
Comment 6 Ian 'Hixie' Hickson 2013-03-19 00:19:08 UTC 
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.
Comment 7 Aryeh Gregor 2013-03-19 14:24:50 UTC 
Note that the editing spec is not maintained right now, unless someone took it over when I wasn't looking.