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 13937 - Specify editing of form controls
Summary: Specify editing of form controls
Status: NEW
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: HISTORICAL - HTML Editing APIs (show other bugs)
Version: unspecified
Hardware: PC Linux
: P2 enhancement
Target Milestone: ---
Deadline: 2015-07-30
Assignee: Aryeh Gregor
QA Contact: HTML Editing APIs spec bugbot
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-08-28 17:02 UTC by Aryeh Gregor
Modified: 2015-07-30 23:47 UTC (History)
5 users (show)

See Also:


Attachments

Description Aryeh Gregor 2011-08-28 17:02:52 UTC
HTML currently says UAs should allow the following:

"""
Edit form controls nested inside editing hosts
When an editable form control is edited, the changes must be reflected in both its current value and its default value. For input elements this means updating the defaultValue IDL attribute as well as the value IDL attribute; for select elements it means updating the option elements' defaultSelected IDL attribute as well as the selected IDL attribute; for textarea elements this means updating the defaultValue IDL attribute as well as the value IDL attribute. (Updating the default* IDL attributes causes content attributes to be updated as well.)
"""

At the face-to-face, we agreed that this is more or less how form elements should behave in contenteditable.  This needs to be specced in more detail.
Comment 1 Jonas Sicking (Not reading bugmail) 2011-08-30 08:25:57 UTC
Should all form controls have a .undoManager though?
Comment 2 Aryeh Gregor 2011-08-30 16:55:35 UTC
I dunno, I'm still happily ignorant of all this undo manager stuff.  :)  CCing Ryosuke and Ehsan in case they have opinions.
Comment 3 Ryosuke Niwa 2011-08-30 17:12:15 UTC
(In reply to comment #1)
> Should all form controls have a .undoManager though?

I don't think so.  In my current specification of undoscope, unless the author specifically adds undoscope attribute all nodes in a document share the same undo manager.  This is to match the current behavior of major UAs.
Comment 4 Ehsan Akhgari [:ehsan] 2011-08-30 19:07:25 UTC
(In reply to comment #3)
> (In reply to comment #1)
> > Should all form controls have a .undoManager though?
> 
> I don't think so.  In my current specification of undoscope, unless the author
> specifically adds undoscope attribute all nodes in a document share the same
> undo manager.  This is to match the current behavior of major UAs.

I agree with Aryeh.

Also, I think that we need to say something about how things like <button> elements should be edited.  Do we want them to accept arbitrary content?
Comment 5 Ehsan Akhgari [:ehsan] 2011-08-30 19:08:03 UTC
(In reply to comment #4)
> (In reply to comment #3)
> > (In reply to comment #1)
> > > Should all form controls have a .undoManager though?
> > 
> > I don't think so.  In my current specification of undoscope, unless the author
> > specifically adds undoscope attribute all nodes in a document share the same
> > undo manager.  This is to match the current behavior of major UAs.
> 
> I agree with Aryeh.

s/Aryeh/Ryosuke/  :-)
Comment 6 Aryeh Gregor 2011-08-30 20:18:54 UTC
Buttons should certainly accept at least inline markup.  That's the point of them.  Per HTML5, buttons can contain any non-interactive phrasing content, which seems reasonable.  To properly specify that, we'd need explicit special cases -- e.g., createLink inside a button should fail.  This is a long-term project.