Intent to ship: 2nd argument of document.createElement should be an object

[Anton Obzhirov]

Contact emails
domi...@chromium.org, a.obz...@samsung.com

Spec
https://dom.spec.whatwg.org/#dom-document-createelement

Summary
This intent covers the support of the dictionary as a 2nd argument of document.createElement.

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes

Interoperability and Compatibility Risk
The feature is landed in Firefox. document.createElement string second argument will be supported with deprecation warning.

OWP launch tracking bug
crbug.com/585096

Entry on the feature dashboard
https://www.chromestatus.com/features/5094346349084672

BR, Anton

[PhistucK]

And I thought the second Object parameter will be an attribute bag...

It is worth to mention that it is used by custom elements (the is member).

☆PhistucK

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Anton Obzhirov]

Sorry for misleading title, I’ve updated the feature description.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Dominic Cooney]

Yes, the second parameter is a Dictionary. As Anton has it now, Blink will switch from string (which comes from an old draft of the custom elements spec) to (string or dictionary) with deprecation warnings when you pass string; and eventually we'll switch to dictionary.

Thanks for working on this, Anton. I know Anne vk et al were concerned Blink act on this quickly.

Dominic

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Philip Jägenstedt]

LGTM1 to support ElementCreationOptions as the second argument.

There is no use counter for the current DOMString argument, do you have any other ways of estimating its usage? If it's currently unknown, I would suggest handling its deprecation and removal separately from this intent, with a separate chromestatus entry.

Finally, can you convert crbug.com/637353 into OWP launch bug?

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Jochen Eisinger]

lgtm2

[Rick Byers]

LGTM3

+1 to Philip's suggestion that breaking changes be done separately unless there is already compelling data that the compat risk is very low.

lgtm2

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Elliott Sprehn]

On Wed, Oct 5, 2016 at 6:21 AM, PhistucK <phis...@gmail.com> wrote:

And I thought the second Object parameter will be an attribute bag...

We could still do that someday as:

.createElement(tagName, {

  attributes: ...,

});

Or by adding something to constructors. I think there's not consensus yet about the exact ergonomics of this feature if we were to ship it, but we can still do it someday if we wanted.

[PhistucK]

Yes, but not now. Since I did not have any context, I just presumed that was the case and then got hit by a custom element (huh). :(

☆PhistucK

[Anton Obzhirov]

Hi guys,

Since Rick and Philip suggested to handle the deprecation changes separately should I submit Intent to Deprecate?
There is no intent to remove it yet and the change still supports the string argument.
I guess once there is enough data to estimate the usage it can be removed.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Philip Jägenstedt]

I'd suggest waiting with deprecation until you're ready to commit to a removal date. Otherwise, there is a risk that usage turns out to be higher than you'd hoped and the deprecation message has to be removed, perhaps by standardizing on (ElementCreationOptions or DOMString).

One such unfortunate deprecation is CSSStyleSheetInsertRuleOptionalArg, where some developers may have wasted their time, just commented on the spec bug.

[Dominic Cooney]

Given that there's a standard way forward (use the element creation options dictionary) I think we should deprecate the string argument now.

Anton's patch adds the use counter so we can count it for removal, which will have a separate intent.

Dominic

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Philip Jägenstedt]

Do we have any information from which to guess usage of the existing API? For example, it could be bounded by another use counter or an httparchive search shows very little usage. https://codereview.chromium.org/2334223005/ claims that "second argument string will stop being supported soon", but if we can really be confident of that we should decide on a removal date now.

Are there downsides to shipping ElementCreationOptions before the date of the DOMString argument is known? Would it be better to stay with DOMString than to risk ending up with (ElementCreationOptions or DOMString)? If so it might be best to measure usage first, before making any changes to behavior.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Dominic Cooney]

On Tue, Oct 11, 2016 at 10:22 PM, Philip Jägenstedt <foo...@chromium.org> wrote:

Do we have any information from which to guess usage of the existing API?

document.registerElement is probably the best upper bound https://www.chromestatus.com/metrics/feature/timeline/popularity/457

It's a generous upper bound though because only some of those pages will register type extensions *and* use createElement with two arguments.

 

For example, it could be bounded by another use counter or an httparchive search shows very little usage. https://codereview.chromium.org/2334223005/ claims that "second argument string will stop being supported soon", but if we can really be confident of that we should decide on a removal date now.

Are there downsides to shipping ElementCreationOptions before the date of the DOMString argument is known?

Users instantiate more type extensions/customized built-in elements with createElement, driving up use of the API we want to deprecate.

 

Would it be better to stay with DOMString than to risk ending up with (ElementCreationOptions or DOMString)?

It would be good to get input from other vendors in this decision, because I think this kind of amounts to asking them to implement the DOMString version of the API instead/as well.

 

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Rick Byers]

On Tue, Oct 11, 2016 at 10:07 AM, Dominic Cooney <domi...@chromium.org> wrote:

On Tue, Oct 11, 2016 at 10:22 PM, Philip Jägenstedt <foo...@chromium.org> wrote:

Do we have any information from which to guess usage of the existing API?

document.registerElement is probably the best upper bound https://www.chromestatus.com/metrics/feature/timeline/popularity/457

It's a generous upper bound though because only some of those pages will register type extensions *and* use createElement with two arguments.

IMHO we shouldn't be adding any new deprecation messages without first having data indicating that usage is low enough that removal will probably be OK (and so we can pick a target milestone for removal).  There are a ton of things we'd love to get developers to stop using, it's just too tempting to pollute the console with wishful thinking, drowning out the signal (and damaging our credibility) for things that are actually on a concrete path to removal.

However if you expect the usage is going to be low enough in this case, then there are things we can do that'll still have the timeframe you're hoping for (deprecation in M56, removal in M57/M58).  For example, merge the UseCounter back to M55, collect some data from dev channel and assuming usage is low, do a deprecate/remove for M56 based on this data.  Once 55 hits beta/stable we just double check to verify the data is roughly in line with what we saw in dev (worst case and it's somehow radically higher, we can always revert the deprecation from M56 and revisit).

[Philip Jägenstedt]

FWIW, I tried to see if httparchive would help, but a search for createElement( with comma before closing ) had >250k results, any real cases seemingly hidden among libraries like React. Manual analysis could perhaps extract out some signal, but it's a lot of work, so use counters seem the better option, especially if the expectation is that there isn't much usage.

I don't know when this first shipped, but it was added to Document.idl in 2013, and was presumably part of some spec and tutorials, so maybe >0.1% usage of this wouldn't be too surprising?

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Dominic Cooney]

Thanks all for your input and advice. Philip, Domenic and I chatted offline. I agree it's useful to have use counter data for the string argument, so let's add the use counter to createElement(..., string) and use that to inform the deprecation plan. Let's *not* add the deprecation message right now.

There's some extra context I should have shared: createElement(..., string) usage is driven by the implementation of an old draft of the custom elements spec, so deprecating and removing these things is related. I'm researching how much use is from old versions of libraries like Polymer and how their feature detection would respond if we remove these. I don't have any data to share yet, though.

Dominic

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Philip Jägenstedt]

This is a trickier situation than I realized before our chat today. For example, it's not a given that createElement('foo', 'thing') will in fact be equivalent to createElement('foo', { is: 'thing' }), which I had assumed. There's a v0 and v1 of custom elements, and to standardize (ElementCreationOptions or DOMString) might not make sense without also standardizing other parts of v0, which isn't merely a question of syntax.

I should clarify that we don't have to know that removal will be smooth in order to deprecate, but we should be fairly confident that we'll go through with it and when. We may find ourselves in a situation where breaking stuff is the only path to interop. Let's hope this isn't such a situation, but we'll see, looking forward to more details.

(Maybe searching for 'registerElement' in httparchive will be more useful than what I tried.)

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.