- From: <bugzilla@jessica.w3.org>
- Date: Mon, 05 May 2014 23:18:28 +0000
- To: public-webapps-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25562 --- Comment #7 from Dimitri Glazkov <dglazkov@chromium.org> --- (In reply to Jonas Sicking from comment #6) > (In reply to Dimitri Glazkov from comment #4) > > > We should probably file a separate bug on form controls like <input> and > > > fight out how they should behave (do they submit? Do they appear in > > > form.controls? Do they affect validation?) I personally don't think that > > > <input> in Shadow DOM should by default behave any differently than other > > > not-in-document <input>s. I.e. they should not submit by default. > > > > Why not? This seems very limiting, considering we still don't have a way for > > developers to participate in form submission? > > It breaks the standard behavior where you can just interact with elements > like normal, independently of if they have Shadow DOM or not. > > If <input>s inside Shadow DOM submit, that now means that if you add an > element to the DOM, you now have to reach in to that elements Shadow DOM in > order to affect what is submitted. > > I definitely agree that we should enable hooking in to form submission. > However the thread started here seems like a better design: > > http://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0448.html > > We could even add sugar for implementing a .formData() function by > traversing a DocumentFragment (or all shadow DOMs) and adding the form > fields to the submission. > > With that design the outside world would interact with the shadow host as a > real form control, rather than having to reach into its shadow DOM. Okay. I guess the idea is that we don't make implicit assumptions about what the author might want and instead give them better controls. BTW, this is bug 22443. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Monday, 5 May 2014 23:18:30 UTC