RE: [editing] Is this the right list to discuss editing?
± From: annevankeste...@gmail.com ± Sent: Monday, February 18, 2013 11:16 PM ± ± On Tue, Feb 19, 2013 at 4:14 AM, Alex Mogilevsky alex...@microsoft.com wrote: ± I am working on editing in IE, have issues of various scale that could ± benefit from a discussion in standards environment. Short of creating ± a new working group (which might be a good idea, but is pretty ± involved), is this the right forum to carry on a conversation? If not, any other ± suggestions? ± ± I believe it still is, yes. (Although the draft does lack an editor and I believe one ± of the persons actively working on this stuff at Google moved elsewhere within ± that company.) Good to know, thanks Anne! Now if this is the right place and a few people with interest in the topic start paying attention again, we could have a conversation...
Re: [editing] Is this the right list to discuss editing?
On 19/02/2013 05:56 , Travis Leithead wrote: Alex, work on Editing APIs was ongoing in the Community Group (http://www.w3.org/community/editing/) though their draft is just under a year old. My recall is a bit rusty on that one, but I think that the situation was that: • WebApps is not chartered to publish this, so a CG was created. • But having the discussion on the CG list seemed like a bad idea since everyone is here, so the mailing list for discussion was decided to be public-webapps. I actually pinged Aryeh about this a week or two ago, but I haven't heard back. I'd be happy to take over as editor for this spec, it's a feature I've wanted to have work right forever. In order to make that happen (assuming that Aryeh agrees, or doesn't speak up), I propose the following: • Since I'm financed to work on HTML, transition this to an HTML extension spec (this probably only requires a few changes to the header). • The discussion can stay here (wherever people prefer that I'm already subscribed to — I really don't care). • The spec gets published through the HTML WG, since I believe it's actually viably in scope there already. All of the above assumes you're all happy with it, and the HTML people too. I reckon it could work though. -- Robin Berjon - http://berjon.com/ - @robinberjon
Re: [editing] Is this the right list to discuss editing?
On 02/19/2013 10:17 AM, Robin Berjon wrote: On 19/02/2013 05:56 , Travis Leithead wrote: Alex, work on Editing APIs was ongoing in the Community Group (http://www.w3.org/community/editing/) though their draft is just under a year old. My recall is a bit rusty on that one, but I think that the situation was that: • WebApps is not chartered to publish this, so a CG was created. • But having the discussion on the CG list seemed like a bad idea since everyone is here, so the mailing list for discussion was decided to be public-webapps. I actually pinged Aryeh about this a week or two ago, but I haven't heard back. I'd be happy to take over as editor for this spec, it's a feature I've wanted to have work right forever. FWIW, Aryeh is currently studying full time and doesn't follow web standards discussions regularly. In order to make that happen (assuming that Aryeh agrees, or doesn't speak up), I propose the following: • Since I'm financed to work on HTML, transition this to an HTML extension spec (this probably only requires a few changes to the header). • The discussion can stay here (wherever people prefer that I'm already subscribed to — I really don't care). • The spec gets published through the HTML WG, since I believe it's actually viably in scope there already. All of the above assumes you're all happy with it, and the HTML people too. I reckon it could work though. Of course, I object to publishing this freely licensed specification in a working group that will insist on imposing a more restrictive copyright on it. HTH Ms2ger
Re: [editing] Is this the right list to discuss editing?
WebApps' last discussion about `group scope` and the HTML Editing spec was September 2011 [1]. At that time, WebApps agreed the Editing CG may use public-webapps since WebApps' charter then permitted WebApps to directly take on APIs that were removed from the HTML5 spec. Robin volunteered to help with the editing and he prefers the HTMLWG be responsible for Technical Reports publishing. That works for me. Re the discussion list, I am mostly indifferent. It would be OK with me if public-webapps continues to be the spec's discussion list (provided Robin and the editors track the provenance of contributions). I also agree we should discuss our preferences with the HTMLWG. -AB [1] http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1617.html On 2/19/13 4:17 AM, ext Robin Berjon wrote: On 19/02/2013 05:56 , Travis Leithead wrote: Alex, work on Editing APIs was ongoing in the Community Group (http://www.w3.org/community/editing/) though their draft is just under a year old. My recall is a bit rusty on that one, but I think that the situation was that: • WebApps is not chartered to publish this, so a CG was created. • But having the discussion on the CG list seemed like a bad idea since everyone is here, so the mailing list for discussion was decided to be public-webapps. I actually pinged Aryeh about this a week or two ago, but I haven't heard back. I'd be happy to take over as editor for this spec, it's a feature I've wanted to have work right forever. In order to make that happen (assuming that Aryeh agrees, or doesn't speak up), I propose the following: • Since I'm financed to work on HTML, transition this to an HTML extension spec (this probably only requires a few changes to the header). • The discussion can stay here (wherever people prefer that I'm already subscribed to — I really don't care). • The spec gets published through the HTML WG, since I believe it's actually viably in scope there already. All of the above assumes you're all happy with it, and the HTML people too. I reckon it could work though.
[Bug 17046] Implement redirect audit functionality for XHR
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17046 Anne ann...@annevk.nl changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Anne ann...@annevk.nl --- *** This bug has been marked as a duplicate of bug 12607 *** -- You are receiving this mail because: You are on the CC list for the bug.
Re: FYI: JSON mailing list and BoF
cc John Neumann On Tue, Feb 19, 2013 at 11:48 AM, Oliver Hunt oli...@apple.com wrote: JSON is deliberately minimal and deliberately unversioned. What are you expecting this working group to do? Also, given that JSON is essentially a subset of ECMAScript literal syntax, I'm unsure why this isn't being handled by TC39 It's more then a subset, it's specified in Ecma-262 Edition 5.1, which is ISO/IEC 16262:2011[0]. Rick [0] http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=55755 --Oliver On Feb 18, 2013, at 4:19 PM, Bjoern Hoehrmann derhoe...@gmx.net wrote: * Joe Hildebrand (jhildebr) wrote: We're planning on doing a BoF in Orlando to discuss starting up a JSON working group. The BoF is currently planned for Monday afternoon at 1300 in Carribean 6. A very preliminary version of a charter can be found here: http://trac.tools.ietf.org/wg/appsawg/trac/wiki/JSON But obviously we'll need to build consensus on what it should actually contain. Please discuss on the j...@ietf.org mailing list: https://www.ietf.org/mailman/listinfo/json (http://www.ietf.org/mail-archive/web/apps-discuss/current/msg08912.html ) -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
[xhr] Appending a charset after an author added content-type
Hi, Nicolas Chambrier (he's not registered to the list, please keep him in the CC in your replies) and I came across that case recently: 1) create an XHR object (POST in case it matters) 2) set the Content-Type header explicitly (it changes, but we noticed it with something like application/vnd.ooz.user.v1+json) 3) .send() (what is sent is a JSON valid string) Firefox adds a ; charset=UTF-8 after the manually set content-type value. Chrome does not. I'd like to report a bug, but I'm not sure where I should report it to :-s My understanding of the spec is that the charset shouldn't be added, because: 1) the Content-Type header is in author request header 2) the value is a valid MIME-type (tell me if I'm wrong on this) 3) it does not have a charset parameter (so, the condition of step 4 doesn't apply in my opinion). Who should I file a bug against? David
Re: [xhr] Appending a charset after an author added content-type
On Tue, Feb 19, 2013 at 5:51 PM, David Bruant bruan...@gmail.com wrote: My understanding of the spec is that the charset shouldn't be added, because: 1) the Content-Type header is in author request header 2) the value is a valid MIME-type (tell me if I'm wrong on this) 3) it does not have a charset parameter (so, the condition of step 4 doesn't apply in my opinion). Who should I file a bug against? Firefox. http://xhr.spec.whatwg.org/#the-send%28%29-method is pretty clear that we only correct charset parameters. Even if application/vnd.ooz.user.v1+json was invalid we still should not muddle with it. -- http://annevankesteren.nl/
Re: [xhr] Appending a charset after an author added content-type
On 2/19/13 1:40 PM, Anne van Kesteren wrote: On Tue, Feb 19, 2013 at 5:51 PM, David Bruant bruan...@gmail.com wrote: My understanding of the spec is that the charset shouldn't be added, because: 1) the Content-Type header is in author request header 2) the value is a valid MIME-type (tell me if I'm wrong on this) 3) it does not have a charset parameter (so, the condition of step 4 doesn't apply in my opinion). Who should I file a bug against? Firefox. http://xhr.spec.whatwg.org/#the-send%28%29-method is pretty clear that we only correct charset parameters. Even if application/vnd.ooz.user.v1+json was invalid we still should not muddle with it. Note that Firefox adds the charset even if it wasn't set by the page because web developers were asking for it to aid server-side processing... The alternative is that the server has no idea what to do with the data. :( -Boris
Re: [xhr] Appending a charset after an author added content-type
On Tue, Feb 19, 2013 at 6:44 PM, Boris Zbarsky bzbar...@mit.edu wrote: Note that Firefox adds the charset even if it wasn't set by the page because web developers were asking for it to aid server-side processing... The alternative is that the server has no idea what to do with the data. :( Does that include cases though where the page did set a Content-Type through setRequestHeader()? Because technically what Firefox does violates HTTP semantics as not every MIME type allows for a charset parameter. -- http://annevankesteren.nl/
Re: [xhr] Appending a charset after an author added content-type
On 2013-02-19 19:51, Anne van Kesteren wrote: On Tue, Feb 19, 2013 at 6:44 PM, Boris Zbarsky bzbar...@mit.edu wrote: Note that Firefox adds the charset even if it wasn't set by the page because web developers were asking for it to aid server-side processing... The alternative is that the server has no idea what to do with the data. :( Does that include cases though where the page did set a Content-Type through setRequestHeader()? Because technically what Firefox does violates HTTP semantics as not every MIME type allows for a charset parameter. Right. If other UAs don't do this, FF should avoid it as well. Which reminds me about the funny requirement to rewrite charset parameters in place; this really needs test cases; if it's still only Firefox doing it it should be nuked from the spec. Best regards, Julian
[shadow-dom] Counters and list item counting
Currently in Webkit list item counting is done on the render tree, but we are looking at making it use the DOM instead so that ordered lists work properly in regions. This raises an interesting question about if they should use the composed shadow tree, or the original tree. ex. x-widget ol li li /ol /x-widget inside x-widget: div content select=li:last-child /div What's the count on that projected list item? This also raises questions of how counters interact with shadows. Should counters work on the project DOM or the original DOM? We're leaning towards the original DOM since otherwise counters become difficult to work with when they're reprojected deeper and deeper down a component hierarchy. - E
Re: [xhr] Appending a charset after an author added content-type
On 2/19/13 1:51 PM, Anne van Kesteren wrote: Does that include cases though where the page did set a Content-Type through setRequestHeader()? That's a good question. I don't remember anymore; I'd have to go read the relevant bugs. Because technically what Firefox does violates HTTP semantics as not every MIME type allows for a charset parameter. Indeed. Not sure how worthwhile it is to restrict this sort of thing to text/plain. -Boris
Re: [shadow-dom] Counters and list item counting
On 2/19/13 2:20 PM, Elliott Sprehn wrote: Currently in Webkit list item counting is done on the render tree, but we are looking at making it use the DOM instead so that ordered lists work properly in regions. Why wouldn't they work properly even if done on the render tree? Note that if you do list item counting on the DOM, how are you planning to implement http://www.w3.org/TR/CSS21/generate.html#undisplayed-counters ? -Boris
Re: [shadow-dom] Counters and list item counting
On Tue, Feb 19, 2013 at 11:38 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 2/19/13 2:20 PM, Elliott Sprehn wrote: Currently in Webkit list item counting is done on the render tree, but we are looking at making it use the DOM instead so that ordered lists work properly in regions. Why wouldn't they work properly even if done on the render tree? Note that if you do list item counting on the DOM, how are you planning to implement http://www.w3.org/TR/CSS21/generate.html#undisplayed-counters ? There's some layer-breaching intrinsic to this. You do have to examine your styles to see if you generate a box. I wouldn't want it to rely on the box tree, though, as that means things like 'order' would affect list item numbering, not to mention the effects that Elliot brings up. ~TJ
Re: [shadow-dom] Counters and list item counting
On 2/19/13 2:43 PM, Tab Atkins Jr. wrote: There's some layer-breaching intrinsic to this. You do have to examine your styles to see if you generate a box. Well, your styles and the styles of all your ancestors in the flattened tree, yes? I wouldn't want it to rely on the box tree, though, as that means things like 'order' would affect list item numbering Mmm... Does 'order' affect z-ordering? not to mention the effects that Elliot brings up. I'm not clear on what those effects are, actually. What are they? -Boris
Re: [shadow-dom] Counters and list item counting
On Tue, Feb 19, 2013 at 11:49 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 2/19/13 2:43 PM, Tab Atkins Jr. wrote: There's some layer-breaching intrinsic to this. You do have to examine your styles to see if you generate a box. Well, your styles and the styles of all your ancestors in the flattened tree, yes? Yes. I wouldn't want it to rely on the box tree, though, as that means things like 'order' would affect list item numbering Mmm... Does 'order' affect z-ordering? Yes: http://dev.w3.org/csswg/css3-flexbox/#order-property This also affects the painting order [CSS21], exactly as if the elements were reordered in the document. not to mention the effects that Elliot brings up. I'm not clear on what those effects are, actually. What are they? For example, if you intend for the component to contain a ul, but pull the lis into your shadow tree without their ul wrapper, they'll increment whatever element establishes a list-item counter scope that's an ancestor of the component (or, if they're scoped to the shadow tree, as it's a pseudo-document, they'll establish a new counter on the shadow root). If you pull out *some* of the lis but not all, they'll be renumbered in the shadow tree from what you expected them to have in the light tree - for example, if you pull all the evens into one container and all the odds into another, they'll both renumber into a dense numbering from 1 to n/2 instead (or, if the containers didn't establish a counter scope for them, they'll number consecutively, rather than alternating). If the content in the light DOM uses any custom counter rather than a well-known one like list-item (for example, a chapter counter), you're completely screwed, as you're pretty much guaranteed to not establish the counter they expect, so the numbering will get messed up again. Basically, any expectation made by counters in the light DOM is probably bad to break due to shadow DOM reordering. ~TJ
Re: [shadow-dom] Counters and list item counting
On 2/19/13 3:02 PM, Tab Atkins Jr. wrote: For example, if you intend for the component to contain a ul Oh, effects with components in particular. Yeah, ignoring the rearrangement done by components for purposes of counters makes sense to me. -Boris
Re: [webcomponents] Making the shadow root an Element
On Mon, Feb 18, 2013 at 12:06 PM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Feb 18, 2013 at 1:48 AM, Anne van Kesteren ann...@annevk.nl wrote: On Sat, Feb 16, 2013 at 5:23 PM, Dimitri Glazkov dglaz...@google.com wrote: We were thinking of adding innerHTML to DocumentFragments anyway... right, Anne? Well I thought so, but that plan didn't work out at the end of the day. https://www.w3.org/Bugs/Public/show_bug.cgi?id=14694#c7 So given that consensus still putting it on ShadowRoot strikes me like a bad idea (as I think I've said somewhere in a bug). The same goes for various other members of ShadowRoot. I don't think there's a consensus really. JS authors were very vocal about needing this ability. Does anyone have a link to the strong case against adding explicit API for DF.innerHTML from Hixie that that comment refers to? Unfortunately that comment referred to an IRC discussion that took place last June on #whatwg. IIRC, Hixie's position was that adding more explicit API for innerHTML is a moral hazard because it encourages an anti-pattern. (Also IIRC), Anne and Henri both sided with Hixie at the time and the DF.innerHTML got left in a ditch. It's also worth pointing out that if it was decided to have innerHTML on DF and on ShadowRoot, they would likely have subtly different semantics: -DF.innerHTML would parse exactly the way template.innerHTML does (using the 'implied context parsing). -SR.innerHTML would use its host as the context element and the output would be as if the input *had been* applied to host.innerHTML, then lifted out and attached to the SR. (I believe the later currently the case for ShadowRoot). / Jonas
Re: [webcomponents] Making the shadow root an Element
On 02/19/2013 10:24 PM, Rafael Weinstein wrote: On Mon, Feb 18, 2013 at 12:06 PM, Jonas Sicking jo...@sicking.cc mailto:jo...@sicking.cc wrote: On Mon, Feb 18, 2013 at 1:48 AM, Anne van Kesteren ann...@annevk.nl mailto:ann...@annevk.nl wrote: On Sat, Feb 16, 2013 at 5:23 PM, Dimitri Glazkov dglaz...@google.com mailto:dglaz...@google.com wrote: We were thinking of adding innerHTML to DocumentFragments anyway... right, Anne? Well I thought so, but that plan didn't work out at the end of the day. https://www.w3.org/Bugs/Public/show_bug.cgi?id=14694#c7 So given that consensus still putting it on ShadowRoot strikes me like a bad idea (as I think I've said somewhere in a bug). The same goes for various other members of ShadowRoot. I don't think there's a consensus really. JS authors were very vocal about needing this ability. Does anyone have a link to the strong case against adding explicit API for DF.innerHTML from Hixie that that comment refers to? Unfortunately that comment referred to an IRC discussion that took place last June on #whatwg. We do have logs for #whatwg. See the topic of that channel. IIRC, Hixie's position was that adding more explicit API for innerHTML is a moral hazard because it encourages an anti-pattern. (Also IIRC), Anne and Henri both sided with Hixie at the time and the DF.innerHTML got left in a ditch. It's also worth pointing out that if it was decided to have innerHTML on DF and on ShadowRoot, they would likely have subtly different semantics: -DF.innerHTML would parse exactly the way template.innerHTML does (using the 'implied context parsing). -SR.innerHTML would use its host as the context element and the output would be as if the input *had been* applied to host.innerHTML, then lifted out and attached to the SR. (I believe the later currently the case for ShadowRoot). / Jonas
Re: Custom elements ES6/ES5 syntax compromise, was: document.register and ES6
I'd be a much happier camper if I didn't have to think about handling
different return values.
I agree, and If it were up to me, there would be just one API for
document.register.
However, the argument given for dividing the API is that it is improper to
have a function return a value that is only important on some platforms. If
that's the winning argument, then isn't it pathological to make the 'non
constructor-returning API' return a constructor?
On Mon, Feb 18, 2013 at 12:59 PM, Daniel Buchner dan...@mozilla.com wrote:
I agree with your approach on staging the two specs for this, but the last
part about returning a constructor in one circumstance and undefined in the
other is something developers would rather not deal with (in my
observation). If I'm a downstream consumer or library author who's going to
wrap this function (or any function for that matter), I'd be a much happier
camper if I didn't have to think about handling different return values. Is
there a clear harm in returning a constructor reliably that would make us
want to diverge from an expected and reliable return value? It seems to me
that the unexpected return value will be far more annoying than a little
less mental separation between the two invocation setups.
Daniel J. Buchner
Product Manager, Developer Ecosystem
Mozilla Corporation
On Mon, Feb 18, 2013 at 12:47 PM, Dimitri Glazkov dglaz...@google.comwrote:
On Fri, Feb 15, 2013 at 8:42 AM, Daniel Buchner dan...@mozilla.com
wrote:
I'm not sure I buy the idea that two ways of doing the same thing does
not
seem like a good approach - the web platform's imperative and
declarative
duality is, by nature, two-way. Having two methods or an option that
takes
multiple input types is not an empirical negative, you may argue it is
an
ugly pattern, but that is largely subjective.
For what it's worth, I totally agree with Anne that two-prong API is a
huge wart and I feel shame for proposing it. But I would rather feel
shame than waiting for Godot.
Is this an accurate summary of what we're looking at for possible
solutions?
If so, can we at least get a decision on whether or not _this_ route is
acceptable?
FOO_CONSTRUCTOR = document.register(‘x-foo’, {
prototype: ELEMENT_PROTOTYPE,
lifecycle: {
created: CALLBACK
}
});
I will spec this first.
FOO_CONSTRUCTOR = document.register(‘x-foo’, {
constructor: FOO_CONSTRUCTOR
});
When we have implementers who can handle it, I'll spec that.
Eventually, we'll work to deprecate the first approach.
One thing that Scott suggested recently is that the second API variant
always returns undefined, to better separate the two APIs and their
usage patterns.
:DG
Re: Custom elements ES6/ES5 syntax compromise, was: document.register and ES6
What is the harm in returning the same constructor that is being input for
this form of invocation? The output constructor is simply a pass-through of
the input constructor, right?
FOO_CONSTRUCTOR = document.register(‘x-foo’, {
constructor: FOO_CONSTRUCTOR
});
I guess this isn't a big deal though, I'll certainly defer to you all on
the best course :)
Daniel J. Buchner
Product Manager, Developer Ecosystem
Mozilla Corporation
On Tue, Feb 19, 2013 at 12:51 PM, Scott Miles sjmi...@google.com wrote:
I'd be a much happier camper if I didn't have to think about handling
different return values.
I agree, and If it were up to me, there would be just one API for
document.register.
However, the argument given for dividing the API is that it is improper to
have a function return a value that is only important on some platforms. If
that's the winning argument, then isn't it pathological to make the 'non
constructor-returning API' return a constructor?
On Mon, Feb 18, 2013 at 12:59 PM, Daniel Buchner dan...@mozilla.comwrote:
I agree with your approach on staging the two specs for this, but the
last part about returning a constructor in one circumstance and undefined
in the other is something developers would rather not deal with (in my
observation). If I'm a downstream consumer or library author who's going to
wrap this function (or any function for that matter), I'd be a much happier
camper if I didn't have to think about handling different return values. Is
there a clear harm in returning a constructor reliably that would make us
want to diverge from an expected and reliable return value? It seems to me
that the unexpected return value will be far more annoying than a little
less mental separation between the two invocation setups.
Daniel J. Buchner
Product Manager, Developer Ecosystem
Mozilla Corporation
On Mon, Feb 18, 2013 at 12:47 PM, Dimitri Glazkov dglaz...@google.comwrote:
On Fri, Feb 15, 2013 at 8:42 AM, Daniel Buchner dan...@mozilla.com
wrote:
I'm not sure I buy the idea that two ways of doing the same thing
does not
seem like a good approach - the web platform's imperative and
declarative
duality is, by nature, two-way. Having two methods or an option that
takes
multiple input types is not an empirical negative, you may argue it is
an
ugly pattern, but that is largely subjective.
For what it's worth, I totally agree with Anne that two-prong API is a
huge wart and I feel shame for proposing it. But I would rather feel
shame than waiting for Godot.
Is this an accurate summary of what we're looking at for possible
solutions?
If so, can we at least get a decision on whether or not _this_ route is
acceptable?
FOO_CONSTRUCTOR = document.register(‘x-foo’, {
prototype: ELEMENT_PROTOTYPE,
lifecycle: {
created: CALLBACK
}
});
I will spec this first.
FOO_CONSTRUCTOR = document.register(‘x-foo’, {
constructor: FOO_CONSTRUCTOR
});
When we have implementers who can handle it, I'll spec that.
Eventually, we'll work to deprecate the first approach.
One thing that Scott suggested recently is that the second API variant
always returns undefined, to better separate the two APIs and their
usage patterns.
:DG
[Bug 18558] [IndexedDB] Define error seen when key generator maximum value is reached
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18558 Eliot Graff eliot...@microsoft.com changed: What|Removed |Added Status|NEW |RESOLVED CC||eliot...@microsoft.com Resolution|--- |FIXED --- Comment #6 from Eliot Graff eliot...@microsoft.com --- Added the following: In 3.1.13 (7th bullet) ... When the current number of a key generator reaches above the value 2^53 (9007199254740992) any attempts to use the key generator to generate a new key will result in a ConstraintError. It's still possible to insert records into the object store by specifying an explicit key, however the only way to use a key generator again for the object store is to delete the object store and create a new one. In Section 5.1, Object Store Storage Operation ... 2. If store uses a key generator and key is undefined, set key to the next generated key. If store also uses in-line keys, then set the property in value pointed to by store's key path to the new value for key, as shown in the steps to assign a key to a value using a key path. If the current number of a key generator reaches above the value 2^53 (9007199254740992) any attempt to use the key generator to generate a new key fails with a ConstraintError. Commit #382 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 18656] objectStore.delete should raise InvalidStateError if object store is deleted
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18656 Eliot Graff eliot...@microsoft.com changed: What|Removed |Added Status|NEW |RESOLVED CC||eliot...@microsoft.com Resolution|--- |FIXED --- Comment #1 from Eliot Graff eliot...@microsoft.com --- Added InvalidStateError to: IDBObjectStore.delete() and IDBObjectStoreSync.delete() Commit #383 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 20833] Incomplete sentence in draft WD-IndexedDB-20120524
https://www.w3.org/Bugs/Public/show_bug.cgi?id=20833 Joshua Bell jsb...@chromium.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Joshua Bell jsb...@chromium.org --- This was fixed in https://dvcs.w3.org/hg/IndexedDB/rev/dc239a31b0d4 -- You are receiving this mail because: You are on the CC list for the bug.
Re: [webcomponents]: Building HTML elements with custom elements
I think you captured it well, thank you for distillation.
Perhaps one other COST of the localName issue is the question of
document.createElement.
document.createElement('x-button') creates button is='x-button', people
complain because the tag names do not match.
document.createElement('button').setAttribute('is', 'x-button'), doesn't
work this way, is is not a standard attribute (according to me)
document.createElement('button', 'x-button'), now I cannot encode my tag in
a single variable (i.e. document.createElement(someTag))
document.createElement('button/x-button'), I just made this up, but maybe
it would work.
Scott
On Tue, Feb 19, 2013 at 3:52 PM, Dimitri Glazkov dglaz...@chromium.orgwrote:
Hi folks!
Since the very early ages of Web Components, one of the use cases was
implementing built-in HTML elements
(
http://www.w3.org/2008/webapps/wiki/Component_Model_Use_Cases#Built-in_HTML_Elements
).
So, I spent a bit of time today trying to understand how our progress
with custom elements aligns with that cooky idea of explaining the
magic in Web platform with existing primitives.
Here are the three things where we've found problems and ended up with
compromises. I don't think any of those are critically bad, but it's
worth enumerating them here:
1) For custom elements, the [[Construct]] internal method creates a
platform object (https://www.w3.org/Bugs/Public/show_bug.cgi?id=20831)
and eventually, this [[Construct]] special behavior disappears --
that's when an HTML element becomes nothing more than just a JS
object.
PROBLEM: This is a lot of work for at least one JS engine to support
overriding [[Construct]] method, and can't happen within a reasonable
timeframe.
COMPROMISE: Specify an API that produces a generated constructor
(which creates a proper platform object), then later introduce the API
that simply changes the [[Construct]] method, then deprecate the
generated constructor API.
COST: We may never get to the deprecation part, stuck with two
slightly different API patterns for document.register.
2) Custom element constructor runs at the time of parsing HTML, as the
tree is constructed.
PROBLEM: Several implementers let me know that allowing to run JS
while parsing HTML is not something they can accommodate in a
reasonable timeframe.
COMPROMISE: Turn constructor into a callback, which runs in a
microtask at some later time (like upon encountering /script).
COST: Constructing an element when building a tree != createElement.
Also, there's an observable difference between the callback and the
constructor. Since the constructor runs before element is inserted
into a tree, it will not have any children or the parent. At the time
the callback is invoked, the element will already be in the tree--and
thus have children and the parent.
3) Since the elements could derive from other existing elements, the
localName should not be used for determining custom element's type
(https://www.w3.org/Bugs/Public/show_bug.cgi?id=20913)
PROBLEM: The localName checks are everywhere, from C++ code to
extensions, to author code, and a lot of things will break if a custom
element that is, for example, an HTMLButtonElement does not have
localName of button. Addressing this issue head on seems
intractable.
COMPROMISE: Only allow custom tag syntax for elements that do not
inherit from existing HTML or SVG elements.
COST: Existing HTML elements are forever stuck in type-extension
world (
https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/index.html#dfn-type-extension
),
which seems like another bit of magic.
I think I got them all, but I could have missed things. Please look
over and make noise if stuff looks wrong.
:DG
Re: [webcomponents]: Building HTML elements with custom elements
Adding Blake and William, the Mozilla folks working on this. I
apologize for not thinking of you guys earlier :)
On Tue, Feb 19, 2013 at 7:01 PM, Scott Miles sjmi...@google.com wrote:
I think you captured it well, thank you for distillation.
Perhaps one other COST of the localName issue is the question of
document.createElement.
document.createElement('x-button') creates button is='x-button', people
complain because the tag names do not match.
document.createElement('button').setAttribute('is', 'x-button'), doesn't
work this way, is is not a standard attribute (according to me)
document.createElement('button', 'x-button'), now I cannot encode my tag in
a single variable (i.e. document.createElement(someTag))
document.createElement('button/x-button'), I just made this up, but maybe it
would work.
Scott
On Tue, Feb 19, 2013 at 3:52 PM, Dimitri Glazkov dglaz...@chromium.org
wrote:
Hi folks!
Since the very early ages of Web Components, one of the use cases was
implementing built-in HTML elements
(http://www.w3.org/2008/webapps/wiki/Component_Model_Use_Cases#Built-in_HTML_Elements).
So, I spent a bit of time today trying to understand how our progress
with custom elements aligns with that cooky idea of explaining the
magic in Web platform with existing primitives.
Here are the three things where we've found problems and ended up with
compromises. I don't think any of those are critically bad, but it's
worth enumerating them here:
1) For custom elements, the [[Construct]] internal method creates a
platform object (https://www.w3.org/Bugs/Public/show_bug.cgi?id=20831)
and eventually, this [[Construct]] special behavior disappears --
that's when an HTML element becomes nothing more than just a JS
object.
PROBLEM: This is a lot of work for at least one JS engine to support
overriding [[Construct]] method, and can't happen within a reasonable
timeframe.
COMPROMISE: Specify an API that produces a generated constructor
(which creates a proper platform object), then later introduce the API
that simply changes the [[Construct]] method, then deprecate the
generated constructor API.
COST: We may never get to the deprecation part, stuck with two
slightly different API patterns for document.register.
2) Custom element constructor runs at the time of parsing HTML, as the
tree is constructed.
PROBLEM: Several implementers let me know that allowing to run JS
while parsing HTML is not something they can accommodate in a
reasonable timeframe.
COMPROMISE: Turn constructor into a callback, which runs in a
microtask at some later time (like upon encountering /script).
COST: Constructing an element when building a tree != createElement.
Also, there's an observable difference between the callback and the
constructor. Since the constructor runs before element is inserted
into a tree, it will not have any children or the parent. At the time
the callback is invoked, the element will already be in the tree--and
thus have children and the parent.
3) Since the elements could derive from other existing elements, the
localName should not be used for determining custom element's type
(https://www.w3.org/Bugs/Public/show_bug.cgi?id=20913)
PROBLEM: The localName checks are everywhere, from C++ code to
extensions, to author code, and a lot of things will break if a custom
element that is, for example, an HTMLButtonElement does not have
localName of button. Addressing this issue head on seems
intractable.
COMPROMISE: Only allow custom tag syntax for elements that do not
inherit from existing HTML or SVG elements.
COST: Existing HTML elements are forever stuck in type-extension
world
(https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/index.html#dfn-type-extension),
which seems like another bit of magic.
I think I got them all, but I could have missed things. Please look
over and make noise if stuff looks wrong.
:DG
Re: Custom elements ES6/ES5 syntax compromise, was: document.register and ES6
Question: if I do
FancyHeaderPrototype = Object.create(HTMLElement.prototype);
document.register('fancy-header', {
prototype: FancyHeaderPrototype
...
In this case, I intend to extend header. I expect my custom elements to
look like header is=fancy-header, but how does the system know what
localName to use? I believe the notion was that the localName would be
inferred from the prototype, but there are various semantic tags that share
prototypes, so it seems ambiguous in these cases.
S
On Tue, Feb 19, 2013 at 1:01 PM, Daniel Buchner dan...@mozilla.com wrote:
What is the harm in returning the same constructor that is being input for
this form of invocation? The output constructor is simply a pass-through of
the input constructor, right?
FOO_CONSTRUCTOR = document.register(‘x-foo’, {
constructor: FOO_CONSTRUCTOR
});
I guess this isn't a big deal though, I'll certainly defer to you all on
the best course :)
Daniel J. Buchner
Product Manager, Developer Ecosystem
Mozilla Corporation
On Tue, Feb 19, 2013 at 12:51 PM, Scott Miles sjmi...@google.com wrote:
I'd be a much happier camper if I didn't have to think about handling
different return values.
I agree, and If it were up to me, there would be just one API for
document.register.
However, the argument given for dividing the API is that it is improper
to have a function return a value that is only important on some platforms.
If
that's the winning argument, then isn't it pathological to make the 'non
constructor-returning API' return a constructor?
On Mon, Feb 18, 2013 at 12:59 PM, Daniel Buchner dan...@mozilla.comwrote:
I agree with your approach on staging the two specs for this, but the
last part about returning a constructor in one circumstance and undefined
in the other is something developers would rather not deal with (in my
observation). If I'm a downstream consumer or library author who's going to
wrap this function (or any function for that matter), I'd be a much happier
camper if I didn't have to think about handling different return values. Is
there a clear harm in returning a constructor reliably that would make us
want to diverge from an expected and reliable return value? It seems to me
that the unexpected return value will be far more annoying than a little
less mental separation between the two invocation setups.
Daniel J. Buchner
Product Manager, Developer Ecosystem
Mozilla Corporation
On Mon, Feb 18, 2013 at 12:47 PM, Dimitri Glazkov
dglaz...@google.comwrote:
On Fri, Feb 15, 2013 at 8:42 AM, Daniel Buchner dan...@mozilla.com
wrote:
I'm not sure I buy the idea that two ways of doing the same thing
does not
seem like a good approach - the web platform's imperative and
declarative
duality is, by nature, two-way. Having two methods or an option that
takes
multiple input types is not an empirical negative, you may argue it
is an
ugly pattern, but that is largely subjective.
For what it's worth, I totally agree with Anne that two-prong API is a
huge wart and I feel shame for proposing it. But I would rather feel
shame than waiting for Godot.
Is this an accurate summary of what we're looking at for possible
solutions?
If so, can we at least get a decision on whether or not _this_ route
is
acceptable?
FOO_CONSTRUCTOR = document.register(‘x-foo’, {
prototype: ELEMENT_PROTOTYPE,
lifecycle: {
created: CALLBACK
}
});
I will spec this first.
FOO_CONSTRUCTOR = document.register(‘x-foo’, {
constructor: FOO_CONSTRUCTOR
});
When we have implementers who can handle it, I'll spec that.
Eventually, we'll work to deprecate the first approach.
One thing that Scott suggested recently is that the second API variant
always returns undefined, to better separate the two APIs and their
usage patterns.
:DG
Re: Custom elements ES6/ES5 syntax compromise, was: document.register and ES6
Wait a sec, perhaps I've missed something, but in your example you never
extend the actual native header element, was that on purpose? I was under
the impression you still needed to inherit from it in the prototype
creation/registration phase, is that not true?
On Feb 19, 2013 8:26 PM, Scott Miles sjmi...@google.com wrote:
Question: if I do
FancyHeaderPrototype = Object.create(HTMLElement.prototype);
document.register('fancy-header', {
prototype: FancyHeaderPrototype
...
In this case, I intend to extend header. I expect my custom elements to
look like header is=fancy-header, but how does the system know what
localName to use? I believe the notion was that the localName would be
inferred from the prototype, but there are various semantic tags that share
prototypes, so it seems ambiguous in these cases.
S
On Tue, Feb 19, 2013 at 1:01 PM, Daniel Buchner dan...@mozilla.comwrote:
What is the harm in returning the same constructor that is being input
for this form of invocation? The output constructor is simply a
pass-through of the input constructor, right?
FOO_CONSTRUCTOR = document.register(‘x-foo’, {
constructor: FOO_CONSTRUCTOR
});
I guess this isn't a big deal though, I'll certainly defer to you all on
the best course :)
Daniel J. Buchner
Product Manager, Developer Ecosystem
Mozilla Corporation
On Tue, Feb 19, 2013 at 12:51 PM, Scott Miles sjmi...@google.com wrote:
I'd be a much happier camper if I didn't have to think about handling
different return values.
I agree, and If it were up to me, there would be just one API for
document.register.
However, the argument given for dividing the API is that it is improper
to have a function return a value that is only important on some platforms.
If
that's the winning argument, then isn't it pathological to make the 'non
constructor-returning API' return a constructor?
On Mon, Feb 18, 2013 at 12:59 PM, Daniel Buchner dan...@mozilla.comwrote:
I agree with your approach on staging the two specs for this, but the
last part about returning a constructor in one circumstance and undefined
in the other is something developers would rather not deal with (in my
observation). If I'm a downstream consumer or library author who's going to
wrap this function (or any function for that matter), I'd be a much happier
camper if I didn't have to think about handling different return values. Is
there a clear harm in returning a constructor reliably that would make us
want to diverge from an expected and reliable return value? It seems to me
that the unexpected return value will be far more annoying than a little
less mental separation between the two invocation setups.
Daniel J. Buchner
Product Manager, Developer Ecosystem
Mozilla Corporation
On Mon, Feb 18, 2013 at 12:47 PM, Dimitri Glazkov
dglaz...@google.comwrote:
On Fri, Feb 15, 2013 at 8:42 AM, Daniel Buchner dan...@mozilla.com
wrote:
I'm not sure I buy the idea that two ways of doing the same thing
does not
seem like a good approach - the web platform's imperative and
declarative
duality is, by nature, two-way. Having two methods or an option that
takes
multiple input types is not an empirical negative, you may argue it
is an
ugly pattern, but that is largely subjective.
For what it's worth, I totally agree with Anne that two-prong API is a
huge wart and I feel shame for proposing it. But I would rather feel
shame than waiting for Godot.
Is this an accurate summary of what we're looking at for possible
solutions?
If so, can we at least get a decision on whether or not _this_ route
is
acceptable?
FOO_CONSTRUCTOR = document.register(‘x-foo’, {
prototype: ELEMENT_PROTOTYPE,
lifecycle: {
created: CALLBACK
}
});
I will spec this first.
FOO_CONSTRUCTOR = document.register(‘x-foo’, {
constructor: FOO_CONSTRUCTOR
});
When we have implementers who can handle it, I'll spec that.
Eventually, we'll work to deprecate the first approach.
One thing that Scott suggested recently is that the second API variant
always returns undefined, to better separate the two APIs and their
usage patterns.
:DG
[webcomponents]: Custom HTML elements
If someone wants to use custom elements in HTML then is the
following possible in principle?
Let's assume that I want to use checkboxLabel/checkbox element.
1. Parsing:
When parsing document containing this the parser
creates DOM element with the tagName checkbox.
The element is created as an instance of class:
interface CustomElement: Element {}
2. Script binding:
Script may register custom extenders - classes that extend default set of
methods/properties of native CustomElement implementation. For example:
document.behaviors[checkbox] = {
attached: function() { ...the behavior gets attached to the DOM element
`this` here is the element ... }
mousedown: function(event) { ... }
...
someMethod: function(params) { ... }
get someProp: function() { ... }
set someProp: function(val) { ... }
};
The initialization of document.behaviors collection should be made
presumably before onload/documentready DOM event.
2a.
Before generating onload/documentready event the UA shall
assign (extend) behaviors in document.behaviors collection
and call elem.attached() method (if any) passing the element
in 'this' envariable.
3. In principle this method:
document.behaviors[checkbox]
can accept not only tag names but selectors too. For example:
document.behaviors[button[type=checkbox]] = ...;
4. Any DOM modifications (adding new elements, removing)
is made with respect of the document.behaviors collection so
if new element with tag checkbox is created it gets attached()
call for it. In principle the attached() method plays role of constructor
in the behaviors realm.
It could be also detached() method that is invoked before DOM element
removal, kind of dtor in other words.
Does this sound feasible/reasonable to do in conventional UA?
--
Mentioned mechanism works in my Sciter engine pretty well.
The only difference is that instead of document.behaviors I am using
custom 'prototype' CSS property:
checkbox {
display: inline-block;
prototype: CheckBox url(code/controls.tis);
}
and if code/controls.tis script has declaration
class CheckBox: Behavior {
function attached() {...}
function mousedown() {...}
property someProp(v) {...}
}
the element will get CheckBox prototype (class here).
(Sciter uses tis script[1])
[1]
http://www.codeproject.com/Articles/33662/TIScript-language-a-gentle-extension-of-JavaScript
--
Andrew Fedoniouk.
http://terrainformatica.com
Re: Custom elements ES6/ES5 syntax compromise, was: document.register and ES6
Perhaps I'm making a mistake, but there is no specific prototype for the
native header element. 'header', 'footer', 'section', e.g., are all
HTMLElement, so all I can do is
FancyHeaderPrototype = Object.create(HTMLElement.prototype);
Afaict, the 'headerness' cannot be expressed this way.
On Tue, Feb 19, 2013 at 8:34 PM, Daniel Buchner dan...@mozilla.com wrote:
Wait a sec, perhaps I've missed something, but in your example you never
extend the actual native header element, was that on purpose? I was under
the impression you still needed to inherit from it in the prototype
creation/registration phase, is that not true?
On Feb 19, 2013 8:26 PM, Scott Miles sjmi...@google.com wrote:
Question: if I do
FancyHeaderPrototype = Object.create(HTMLElement.prototype);
document.register('fancy-header', {
prototype: FancyHeaderPrototype
...
In this case, I intend to extend header. I expect my custom elements to
look like header is=fancy-header, but how does the system know what
localName to use? I believe the notion was that the localName would be
inferred from the prototype, but there are various semantic tags that share
prototypes, so it seems ambiguous in these cases.
S
On Tue, Feb 19, 2013 at 1:01 PM, Daniel Buchner dan...@mozilla.comwrote:
What is the harm in returning the same constructor that is being input
for this form of invocation? The output constructor is simply a
pass-through of the input constructor, right?
FOO_CONSTRUCTOR = document.register(‘x-foo’, {
constructor: FOO_CONSTRUCTOR
});
I guess this isn't a big deal though, I'll certainly defer to you all on
the best course :)
Daniel J. Buchner
Product Manager, Developer Ecosystem
Mozilla Corporation
On Tue, Feb 19, 2013 at 12:51 PM, Scott Miles sjmi...@google.comwrote:
I'd be a much happier camper if I didn't have to think about
handling different return values.
I agree, and If it were up to me, there would be just one API for
document.register.
However, the argument given for dividing the API is that it is improper
to have a function return a value that is only important on some
platforms. If
that's the winning argument, then isn't it pathological to make the 'non
constructor-returning API' return a constructor?
On Mon, Feb 18, 2013 at 12:59 PM, Daniel Buchner dan...@mozilla.comwrote:
I agree with your approach on staging the two specs for this, but the
last part about returning a constructor in one circumstance and undefined
in the other is something developers would rather not deal with (in my
observation). If I'm a downstream consumer or library author who's going
to
wrap this function (or any function for that matter), I'd be a much
happier
camper if I didn't have to think about handling different return values.
Is
there a clear harm in returning a constructor reliably that would make us
want to diverge from an expected and reliable return value? It seems to me
that the unexpected return value will be far more annoying than a little
less mental separation between the two invocation setups.
Daniel J. Buchner
Product Manager, Developer Ecosystem
Mozilla Corporation
On Mon, Feb 18, 2013 at 12:47 PM, Dimitri Glazkov dglaz...@google.com
wrote:
On Fri, Feb 15, 2013 at 8:42 AM, Daniel Buchner dan...@mozilla.com
wrote:
I'm not sure I buy the idea that two ways of doing the same thing
does not
seem like a good approach - the web platform's imperative and
declarative
duality is, by nature, two-way. Having two methods or an option
that takes
multiple input types is not an empirical negative, you may argue it
is an
ugly pattern, but that is largely subjective.
For what it's worth, I totally agree with Anne that two-prong API is a
huge wart and I feel shame for proposing it. But I would rather feel
shame than waiting for Godot.
Is this an accurate summary of what we're looking at for possible
solutions?
If so, can we at least get a decision on whether or not _this_
route is
acceptable?
FOO_CONSTRUCTOR = document.register(‘x-foo’, {
prototype: ELEMENT_PROTOTYPE,
lifecycle: {
created: CALLBACK
}
});
I will spec this first.
FOO_CONSTRUCTOR = document.register(‘x-foo’, {
constructor: FOO_CONSTRUCTOR
});
When we have implementers who can handle it, I'll spec that.
Eventually, we'll work to deprecate the first approach.
One thing that Scott suggested recently is that the second API variant
always returns undefined, to better separate the two APIs and their
usage patterns.
:DG
Re: Custom elements ES6/ES5 syntax compromise, was: document.register and ES6
Nope, you're 100% right, I saw *header *and thought HTML*Heading*Element
for some reason - so this seems like a valid concern. What are the
mitigation/solution options we can present to developers for this case?
Daniel J. Buchner
Product Manager, Developer Ecosystem
Mozilla Corporation
On Tue, Feb 19, 2013 at 9:17 PM, Scott Miles sjmi...@google.com wrote:
Perhaps I'm making a mistake, but there is no specific prototype for the
native header element. 'header', 'footer', 'section', e.g., are all
HTMLElement, so all I can do is
FancyHeaderPrototype = Object.create(HTMLElement.prototype);
Afaict, the 'headerness' cannot be expressed this way.
On Tue, Feb 19, 2013 at 8:34 PM, Daniel Buchner dan...@mozilla.comwrote:
Wait a sec, perhaps I've missed something, but in your example you never
extend the actual native header element, was that on purpose? I was under
the impression you still needed to inherit from it in the prototype
creation/registration phase, is that not true?
On Feb 19, 2013 8:26 PM, Scott Miles sjmi...@google.com wrote:
Question: if I do
FancyHeaderPrototype = Object.create(HTMLElement.prototype);
document.register('fancy-header', {
prototype: FancyHeaderPrototype
...
In this case, I intend to extend header. I expect my custom elements
to look like header is=fancy-header, but how does the system know what
localName to use? I believe the notion was that the localName would be
inferred from the prototype, but there are various semantic tags that share
prototypes, so it seems ambiguous in these cases.
S
On Tue, Feb 19, 2013 at 1:01 PM, Daniel Buchner dan...@mozilla.comwrote:
What is the harm in returning the same constructor that is being input
for this form of invocation? The output constructor is simply a
pass-through of the input constructor, right?
FOO_CONSTRUCTOR = document.register(‘x-foo’, {
constructor: FOO_CONSTRUCTOR
});
I guess this isn't a big deal though, I'll certainly defer to you all
on the best course :)
Daniel J. Buchner
Product Manager, Developer Ecosystem
Mozilla Corporation
On Tue, Feb 19, 2013 at 12:51 PM, Scott Miles sjmi...@google.comwrote:
I'd be a much happier camper if I didn't have to think about
handling different return values.
I agree, and If it were up to me, there would be just one API for
document.register.
However, the argument given for dividing the API is that it is
improper to have a function return a value that is only important on some
platforms. If that's the winning argument, then isn't it pathological
to make the 'non constructor-returning API' return a constructor?
On Mon, Feb 18, 2013 at 12:59 PM, Daniel Buchner
dan...@mozilla.comwrote:
I agree with your approach on staging the two specs for this, but the
last part about returning a constructor in one circumstance and undefined
in the other is something developers would rather not deal with (in my
observation). If I'm a downstream consumer or library author who's going
to
wrap this function (or any function for that matter), I'd be a much
happier
camper if I didn't have to think about handling different return values.
Is
there a clear harm in returning a constructor reliably that would make us
want to diverge from an expected and reliable return value? It seems to
me
that the unexpected return value will be far more annoying than a little
less mental separation between the two invocation setups.
Daniel J. Buchner
Product Manager, Developer Ecosystem
Mozilla Corporation
On Mon, Feb 18, 2013 at 12:47 PM, Dimitri Glazkov
dglaz...@google.com wrote:
On Fri, Feb 15, 2013 at 8:42 AM, Daniel Buchner dan...@mozilla.com
wrote:
I'm not sure I buy the idea that two ways of doing the same thing
does not
seem like a good approach - the web platform's imperative and
declarative
duality is, by nature, two-way. Having two methods or an option
that takes
multiple input types is not an empirical negative, you may argue
it is an
ugly pattern, but that is largely subjective.
For what it's worth, I totally agree with Anne that two-prong API is
a
huge wart and I feel shame for proposing it. But I would rather feel
shame than waiting for Godot.
Is this an accurate summary of what we're looking at for possible
solutions?
If so, can we at least get a decision on whether or not _this_
route is
acceptable?
FOO_CONSTRUCTOR = document.register(‘x-foo’, {
prototype: ELEMENT_PROTOTYPE,
lifecycle: {
created: CALLBACK
}
});
I will spec this first.
FOO_CONSTRUCTOR = document.register(‘x-foo’, {
constructor: FOO_CONSTRUCTOR
});
When we have implementers who can handle it, I'll spec that.
Eventually, we'll work to deprecate the first approach.
One thing that Scott suggested recently is that the second API
variant
always returns undefined, to better separate the two APIs and their
usage patterns.
:DG
Re: [webcomponents] Making the shadow root an Element
On Tue, Feb 19, 2013 at 12:24 PM, Rafael Weinstein rafa...@google.com wrote: On Mon, Feb 18, 2013 at 12:06 PM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Feb 18, 2013 at 1:48 AM, Anne van Kesteren ann...@annevk.nl wrote: On Sat, Feb 16, 2013 at 5:23 PM, Dimitri Glazkov dglaz...@google.com wrote: We were thinking of adding innerHTML to DocumentFragments anyway... right, Anne? Well I thought so, but that plan didn't work out at the end of the day. https://www.w3.org/Bugs/Public/show_bug.cgi?id=14694#c7 So given that consensus still putting it on ShadowRoot strikes me like a bad idea (as I think I've said somewhere in a bug). The same goes for various other members of ShadowRoot. I don't think there's a consensus really. JS authors were very vocal about needing this ability. Does anyone have a link to the strong case against adding explicit API for DF.innerHTML from Hixie that that comment refers to? Unfortunately that comment referred to an IRC discussion that took place last June on #whatwg. IIRC, Hixie's position was that adding more explicit API for innerHTML is a moral hazard because it encourages an anti-pattern. (Also IIRC), Anne and Henri both sided with Hixie at the time and the DF.innerHTML got left in a ditch. The discouraging that we're currently doing doesn't seem terribly effective. Developers seem to just grab/create a random element and set .innerHTML on that. So I think the current state of affairs is just doing a disservice to everyone, including ourselves. / Jonas
