Re: Form submission participation (was Re: Goals for Shadow DOM review)
On Feb 21, 2014, at 2:12 PM, Edward O'Connor wrote: > Ryosuke wrote: > >> What if we added "formparticipant" boolean content attribute and fired >> "formdata" event during form submission to serialize data? >> >> This way, we can add more events like "validate" to support more >> features of builtin form elements. > > Hmm, right, validation. In the model I have in my head, there are > roughly two kinds of custom form participants: custom form controls > (probably implemented with custom elements & other web components > features) and "application state" (JS objects with no corresponding DOM > presence but that nevertheless should be submittable). > > Suppose in the first case we add a nonconfigurable boolean property to > Element. The engine inspects this property to determine validity, and > it's the responsibility of the component to keep the property up to > date. That way, we don't have to invoke userland JS when performing form > validation or when resolving :valid/:invalid style rules. Right. We may want to move "willValidate", "validity", "validationMessage", "checkValidity()", "reportValidity()" and "setCustomValidity(DOMString error)" IDL attributes from HTMLInputElement to HTMLElement, and make ValidityState's IDL attributes settable on HTMLElement or add a method to update validity states. > In the second case, I think we can just punt completely—form > participants that aren't Elements don't participate in validation, only > submission. Because it's the application's responsibility for > maintaining its own state, there's no sensible visual location in the > document to display a validation error, and no no-application-specific > way for the user to resolve the issue. Right. Since HTML spec already assumes some UI to exist to show validation messages for builtin form controls, I don't think it makes sense for UA to validate form data not associated with any element in the document. - R. Niwa
Re: Form submission participation (was Re: Goals for Shadow DOM review)
On Feb 21, 2014, at 2:28 PM, Ian Hickson wrote:
> On Fri, 21 Feb 2014, Maciej Stachowiak wrote:
>>
>> I'd guess most sophisticated webapps do not use attribute-based event
>> handlers (as opposed to addEventListener), so they would not get this
>> convenient scoping benefit.
>
> That's not clear to me. I mean, certainly today, with div soup, they
> don't. But that's at least partly because there's no sane way to do it
> when your markup isn't really declarative in any useful sense.
>
> When you have Web components that let you get the effect you want while
> sticking to a terse markup language, it becomes much more feasible to
> return to using inline event handlers.
Might be, but I'm not sure you can center a design on a hypothetical future
change in web developer behavior.
>
>> If you're looking at an out-of-line function, then your comparison is:
>>
>> this.a.value = process(value)
>> this.querySelector("#a").value = process(value)
>>
>> which is a less dramatic difference.
>
> It's a pretty compelling difference, IMHO.
>
>
>> Also, the short version gives you the risk of namespace conflicts with
>> the built-in methods and properties of form.
>
> You can do this instead if that feels like a real risk:
>
> this.elements.a.value = process(value)
Which is hardly an upgrade at all over:
this.querySelector("#a").value = process(value)
Cheers,
Maciej
Re: Form submission participation (was Re: Goals for Shadow DOM review)
On Fri, 21 Feb 2014, Maciej Stachowiak wrote:
>
> I'd guess most sophisticated webapps do not use attribute-based event
> handlers (as opposed to addEventListener), so they would not get this
> convenient scoping benefit.
That's not clear to me. I mean, certainly today, with div soup, they
don't. But that's at least partly because there's no sane way to do it
when your markup isn't really declarative in any useful sense.
When you have Web components that let you get the effect you want while
sticking to a terse markup language, it becomes much more feasible to
return to using inline event handlers.
> If you're looking at an out-of-line function, then your comparison is:
>
> this.a.value = process(value)
> this.querySelector("#a").value = process(value)
>
> which is a less dramatic difference.
It's a pretty compelling difference, IMHO.
> Also, the short version gives you the risk of namespace conflicts with
> the built-in methods and properties of form.
You can do this instead if that feels like a real risk:
this.elements.a.value = process(value)
...but in practice I think it's a pretty minimal risk.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Form submission participation (was Re: Goals for Shadow DOM review)
On Fri, Feb 21, 2014 at 2:28 PM, Ian Hickson wrote: > On Fri, 21 Feb 2014, Maciej Stachowiak wrote: >> >> I'd guess most sophisticated webapps do not use attribute-based event >> handlers (as opposed to addEventListener), so they would not get this >> convenient scoping benefit. > > That's not clear to me. I mean, certainly today, with div soup, they > don't. But that's at least partly because there's no sane way to do it > when your markup isn't really declarative in any useful sense. > > When you have Web components that let you get the effect you want while > sticking to a terse markup language, it becomes much more feasible to > return to using inline event handlers. Also the fact that a lot of markup is generated on the server also makes it less interesting to stick the code in the markup. Code generating code is messy and error prone. Also, code in attributes tend to mainly be readable when the code is *really* short. In your example you end up calling out into an external process function. However it could well be less code to avoid the process() function entirely and just have all the processing inline. But that likely will require putting the whole thing outside of an attribute. Other reasons are that the scope chaining for code in attributes, and especially in attributes of form controls, makes the code more error prone. It means that your code risks breaking any time that we add new properties to elements. Finally increased interest in using CSP and preventing XSS has increased incentive to put code outside the markup. I'm certainly not opposed creating something with proxy-like syntax, at least if we check that that's something that developers are really asking for and that implementations are interested in implementing (this thread calls both into question). However I think .elements is still a bad API due to its live-ness and due to not including all form controls. And if we get rid of the liveness that makes it much more possible to use the type of API I drafted. We'd simply have getParticipants() return something that has proxy behavior. / Jonas
Re: Form submission participation (was Re: Goals for Shadow DOM review)
Hi, Ryosuke wrote: > What if we added "formparticipant" boolean content attribute and fired > "formdata" event during form submission to serialize data? > > This way, we can add more events like "validate" to support more > features of builtin form elements. Hmm, right, validation. In the model I have in my head, there are roughly two kinds of custom form participants: custom form controls (probably implemented with custom elements & other web components features) and "application state" (JS objects with no corresponding DOM presence but that nevertheless should be submittable). Suppose in the first case we add a nonconfigurable boolean property to Element. The engine inspects this property to determine validity, and it's the responsibility of the component to keep the property up to date. That way, we don't have to invoke userland JS when performing form validation or when resolving :valid/:invalid style rules. In the second case, I think we can just punt completely—form participants that aren't Elements don't participate in validation, only submission. Because it's the application's responsibility for maintaining its own state, there's no sensible visual location in the document to display a validation error, and no no-application-specific way for the user to resolve the issue. Thoughts? Ted
RE: Form submission participation (was Re: Goals for Shadow DOM review)
From: Ryosuke Niwa > What if we added "formparticipant" boolean content attribute and fired > "formdata" event during form submission to serialize data? I don't understand the virtue of this inverted model, where controls are responsible for listening to their containing form and reacting to it. The original proposal, of the form just asking the control for information via methods, seems much more sensible. It matches how I think of parent-child relationships.
Re: Form submission participation (was Re: Goals for Shadow DOM review)
On Feb 20, 2014, at 2:39 PM, Jonas Sicking wrote:
> On Thu, Feb 20, 2014 at 2:09 PM, Edward O'Connor wrote:
>> +public-webapps, -www-tag in replies to avoid cross-posting
>>
>> Hi,
>>
>> Domenic wrote, to www-tag:
>>
>>> [C]an shadow DOM be used to explain existing elements, like or
>>> , in terms of a lower-level primitive?
>>>
>>> As of now, it seems like it cannot, for two reasons:
>>>
>>> 1. Native elements have extra capabilities which are not granted by
>>> shadow DOM, or by custom elements. For example, they can participate
>>> in form submission.
>>
>> Authors need to be able to participate in form submission, but this is
>> independent of Custom Elements.
>>
>> Web applications often maintain state in JS objects that have no direct
>> DOM representation. Such applications may want such state to be
>> submittable.
>>
>> Existing form elements map one field name to many values. People often
>> build custom controls precisely because those controls hold more
>> complex values that would be better represented as many names to many
>> values. Subclassing existing form elements don't get you this.
>>
>> And inheriting from HTMLInputElement is insane (not because inheriting
>> is insane, but because HTMLInputElement is insane), so that's not really
>> how we want author-defined objects to become submittable.
>>
>> Given the above I don't think we should try to solve the "how authors
>> can participate in form submission" problem by enabling the subclassing
>> of existing form elements. Instead, we should define a protocol
>> implementable by any JS object, which allows that JS object to expose
>> names and values to the form validation and submission processes.
>>
>> Something like this:
>>
>> function Point(x, y) {
>>this.x = x;
>>this.y = y;
>> }
>> Point.prototype.formData = function() {
>>return {
>> "x": this.x,
>> "y": this.y
>>};
>> }
>>
>> var theForm = document.querySelector("#my-form");
>>
>> var p = new Point(4,2);
>>
>> theForm.addParticipant(p);
>> theForm.submit();
>>
>> This is obviously a super hand-wavy strawman and would need to be
>> fleshed out. Thoughts?
>
> Something like this seems awesome! I like that the .addParticipant
> function can enable random JS objects to participate in submission. A
> couple of comments though:
>
>
> I'm not sure if we should return a dictionary or an array. Keep in
> mind that a form control can have multiple values. This is something
> used by both and . Also keep in mind
> that order matters as many servers are sensitive to order.
>
> So we could either do `return { x: [5, 6, 7] }` where enumeration
> order determines submission order, or we could do `return [["x", 5],
> ["x", 6], ["x", 7]]`.
>
> Or, given that normally a single form control only has a single name
> and 0 to many values, we could do `return { name: "x", value: [5, 6,
> 7] }`.
>
>
> The other thing is that it would be great if elements that wanted to
> participate in submission didn't have to manually call addParticipant.
> This could be done by having the element attempt check for a
> .formData property on any descendant that was added, and add any
> elements that has such a property as a participant automatically.
>
> We could even make the built-in form controls like and
> have a .formData() function which returns data in whatever
> format we decide is the right one.
What if we added "formparticipant" boolean content attribute and fired
"formdata" event during form submission to serialize data?
This way, we can add more events like "validate" to support more features of
builtin form elements.
- R. Niwa
Re: Form submission participation (was Re: Goals for Shadow DOM review)
On Feb 21, 2014, at 11:04 AM, Ian Hickson wrote:
> On Thu, 20 Feb 2014, Jonas Sicking wrote:
>> On Thu, Feb 20, 2014 at 2:51 PM, Edward O'Connor wrote:
>>>
>>> Yeah, I think we just say that [form.elements] is the legacy feature
>>> that only exposes built-in controls. form.getParticipants() works for
>>> me.
>>
>> Agreed. [form.elements] is pretty crappy anyway in that it's live and
>> that it doesn't include elements for webcompat
>> reasons (stemming from an old Netscape bug :))
>
> I actually think form.elements is more important than form submission, as
> far as custom form controls go.
>
> Pages with custom form controls are highly likely, I would guess, to be
> interactive apps that don't have any unscripted form submission. I would
> expect lots of XHR, WebSockets, and the like. However, scripts are hugely
> simplified by form.elements. Instead of having to grab things by ID, you
> can just name them, for example. This is even more true for event handlers
> on form controls, which have the form in the scope chain. For example, one
> of the big reasons for adding was that it makes it easier to
> update text -- instead of:
>
> oninput="document.getElementById('a').textContent = process(value)"
>
> ...you can write:
>
> oninput="a.value = process(value)"
I'd guess most sophisticated webapps do not use attribute-based event handlers
(as opposed to addEventListener), so they would not get this convenient scoping
benefit. If you're looking at an out-of-line function, then your comparison is:
this.a.value = process(value)
this.querySelector("#a").value = process(value)
which is a less dramatic difference. Also, the short version gives you the risk
of namespace conflicts with the built-in methods and properties of form.
Regards,
Maciej
Re: Form submission participation (was Re: Goals for Shadow DOM review)
On Feb 20, 2014, at 2:51 PM, Edward O'Connor wrote: >> We could even make the built-in form controls like and >> have a .formData() function which returns data in whatever >> format we decide is the right one. > > Right. toFormData() or the like, parallel to toJSON(). Do we really want a getter on element here? Isn’t it better to model it as elements listening to “submit” event on the associated form element and calling addParticipate in the event listener? - R. Niwa
Re: Decoupling
On Feb 20, 2014, at 6:29 PM, Hajime Morrita wrote: > Firefox has already shipped
Re: Form submission participation (was Re: Goals for Shadow DOM review)
On Thu, 20 Feb 2014, Jonas Sicking wrote:
> On Thu, Feb 20, 2014 at 2:51 PM, Edward O'Connor wrote:
> >
> > Yeah, I think we just say that [form.elements] is the legacy feature
> > that only exposes built-in controls. form.getParticipants() works for
> > me.
>
> Agreed. [form.elements] is pretty crappy anyway in that it's live and
> that it doesn't include elements for webcompat
> reasons (stemming from an old Netscape bug :))
I actually think form.elements is more important than form submission, as
far as custom form controls go.
Pages with custom form controls are highly likely, I would guess, to be
interactive apps that don't have any unscripted form submission. I would
expect lots of XHR, WebSockets, and the like. However, scripts are hugely
simplified by form.elements. Instead of having to grab things by ID, you
can just name them, for example. This is even more true for event handlers
on form controls, which have the form in the scope chain. For example, one
of the big reasons for adding was that it makes it easier to
update text -- instead of:
oninput="document.getElementById('a').textContent = process(value)"
...you can write:
oninput="a.value = process(value)"
More concretely:
00:00 – 24:00
...or:
+
=
Similarly, in a script block you can get form controls by name from forms
gotten by name:
document.forms.main.elements.result.value = 'Hello World';
document.forms.npc.elements.char.value = getRandomName();
This gives you a much more intuitive way of figuring out what's going on.
You can tell what form the controls are from, and the name just fits into
the code without appearing to involve string manipulation, the way that
getElementById() or querySelector() would.
(The last four examples above are all from the HTML spec.)
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[Manifest] Study on installable web apps
(bcc'ing SysApps and WebApps) Hi, Over the last week, the WebMob IG did a somewhat large study of installable web apps based on iOS. In the hope that the findings help with standardization of the manifest, I'd like to share the findings and some recommendations with the WGs. If you would like to read the whole study, including methods, limitations, and data, see [1]. You can also file bugs there. Despite the issues outlined below, we must acknowledge that Apple has done exceptional work in pioneering the concept of "installable web apps" (and continue to make this stuff better and better with each release of iOS). This is not intended to be a criticism of iOS - just a reflection of how the technology is being used in the wild. ## Key findings The number of sites claiming to run as standalone is insignificant: of all sites we had access to, they represent 1.4% of the dataset (i.e., 1097 out of 78,155 claim to be "`apple-mobile-web-app-capable`"). So, despite this capability being available since 2009, and irrespective of iOS being the dominant mobile platform, few developers bother to create standalone web apps. Despite these 1097 sites claiming they can be used as standalone, what we found was that the majority of web apps (90%, or 324 out of 360) **can not be used as standalone**. Only a tiny fraction (10%, or 36 out of 360) are able to run as standalone - and 28% of those had significant limitations (described below). There is, in fact, a greater percentage (12%) of desktop sites masquerading as installable web apps than there are actual standalone applications. Another significant problem is that 85% (307 out of 360) of apps rely on a user's ability to follow hyperlinks. iOS standalone apps don't support following hyperlinks: unless a developer intervenes via JavaScript, the default action is to open links in Safari. The data effectively busts the myth of "single page apps": we found that almost no developers build single page apps in practice for this class of application. Of those 36 apps that were true standalone web apps (i.e., has an icon, is usable on a mobile device, can be navigated), 10 (28%) of those had issues where they either left the user stranded without being able to "go back" - or worst, suddenly navigated to the desktop version of the site. The only option for a user is to drop back to the home screen and open the application again. This causes iOS to load the page that was originally bookmarked. This itself has problems, in that if the user leaves a web app, its state is effectively lost - meaning the application can lose data. In other cases, a web application mostly worked but then it was not possible to perform some critical task within the application (e.g., a purchase). In such cases, the application returned the user back into Safari. Others, like [nest.com](http://nest.com), make a best effort at working as standalone, but throw the user back to the default web browser at random points. On the up-side, the majority of web apps (76%) where designed to work on a mobile phone, even if only 13% of those could actually be navigated. Icon usage, overall, was also fairly healthy - 56% of the web apps we tested included an icon. However, we discovered that at least some web apps included dummy icons from pre-purchased templates - meaning more than one web app included an icon that had nothing to do with the application itself and had the same icon as another site. Oddly, many web apps (5%, or 19) incorrectly claim that they can run as standalone - but contain a markup error in their HTML that prevents the application from actually doing so! Of those, 12 out of 19 (63%) even go as far as to include an icon. These icons are still useful when the app is added to the home screen or bookmarked - just the web apps won't run as standalone. For more details, see the "Other observations" and the "All questions" section in [1]. ## Recommendations to implementers/W3C >From our findings, this is what we would recommend implementers and the W3C >consider when standardizing this technology. * It has to be possible for users to follow hyperlinks in standalone applications. Even though iOS doesn't support this functionality, the data clearly shows developers rely on this core capability of the Web. * It needs to be possible to open some links in the system default browser: it doesn't make sense to open some links, like ads, within the application. * It has to be possible to open a browser window within the application: this is to allow OAuth style authentication (which are blocked from working in iframes). * It needs to be possible for the user to navigate "back". A significant number of a apps, unfortunately, leave users stranded without a way to "go back" in their browsing history. This is sometimes outside the developers control (e.g., an authentication screen at a different domain doesn't support going back). Ha
[Bug 24704] @contenteditable, new lines and new paragraphs.
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24704 Aryeh Gregor changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #2 from Aryeh Gregor --- The specification requires that hitting Enter (or equivalent) is the same as the insertParagraph command, and Shift-Enter (or equivalent) is the same as insertLineBreak: https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html#additional-requirements The insertParagraph command is specified here, with a rough summary in green at the top: https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html#the-insertparagraph-command The short story is: this has been discussed a lot, and there are three basic approaches taken by browser engines. The basic behavior that's currently specified (very simplified) is patterned after IE and Opera, and is: find the nearest ancestor that's a ///etc. and make a new one, if there is any; and if there isn't, make a new . So for instance, if you have foo and you hit Enter in the middle, it becomes foo or such. Likewise foo will become foo, and so on. If you start off with an empty editing host, or break out of a list or such, it will use , but this can be changed to via the defaultParagraphSeparator command. This has been discussed a lot, multiple times, and I'm unlikely to change the spec to require for Enter unless browser implementers want it, which is unlikely. A good thread to read if you're interested is: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-May/031577.html for Enter is the Firefox behavior at the time of this writing, but I rejected it because it causes a lot of subtle headaches and bugs. Particularly, it doesn't actually always create a line break: HTML like foobar displays identically to the same without the -- try it and see. So you have to write lots of magic to figure out when you need to insert extra s to make the do what you want. Moreover, having each paragraph wrapped in its own tag is programmatically easier. Sometimes you want code that affects an entire paragraph, and if it's in a it's very easy. With s it's much more annoying. As far as your example of -- this sort of thing is not well-supported right now, either in the spec or in browsers. is even worse. A ton of work would have to be done to get this sort of thing to behave right, and it's not realistically worth it, so I suggest sticking with for contenteditable for now. I hope this helps. As I said, this is very unlikely to change to what you requested, but if you have more questions *after* reading the mailing list thread I linked to, please feel free to reopen this bug. -- You are receiving this mail because: You are on the CC list for the bug.
