[Bug 22059] Composition dictionary should be changed
https://www.w3.org/Bugs/Public/show_bug.cgi?id=22059 Takayoshi Kochi ko...@google.com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #13 from Takayoshi Kochi ko...@google.com --- I would like to make clarification - The original proposal[1] says: on an element with the contentEditable flag set, then this is the starting offset relative to the target's textContent property (textContent is a linear view of all the text under an element) But the current MSDN document[2] (as of today, Dec. 13, 2013) doesn't mention about behavior when compositionStartOffset/End used in contenteditable. The way that a browser generates textContent from DOM tree and that a browser holds where an IME composition are not usually compatible - is there really a use case to get offsets within contenteditable? I personally suppose for contenteditable it is reasonable to return Range's before and after IME composition within contenteditable (to different attributes, of course) - but am not sure yet. What do you think? [1] https://dvcs.w3.org/hg/ime-api/raw-file/tip/proposals/IMEProposal.html#widl-InputMethodContext-compositionStartOffset [2] http://msdn.microsoft.com/en-us/library/ie/dn433247(v=vs.85).aspx -- You are receiving this mail because: You are on the CC list for the bug.
Re: [custom elements] Improving the name of document.register()
Also, http://www.html5rocks.com/en/tutorials/webcomponents/customelements/ and http://www.polymer-project.org/platform/custom-elements.html already talk about custom elements as a way of defining (and use) new (types of DOM) elements. I mean… even our current working draft says This specification describes the method for enabling the author to _define_ and use new types of DOM elements in a document. (http://w3c.github.io/webcomponents/spec/custom/) - R. Niwa On Dec 12, 2013, at 10:41 PM, Maciej Stachowiak m...@apple.com wrote: I like defineElement a lot too. I think it gets to the heart of this method's potential - the ability to define your own elements. - Maciej On Dec 11, 2013, at 6:46 PM, Dominic Cooney domin...@google.com wrote: On Thu, Dec 12, 2013 at 5:17 AM, pira...@gmail.com pira...@gmail.com wrote: I have seen registerProtocolHandler() and it's being discused registerServiceWorker(). I believe registerElementDefinition() or registerCustomElement() could help to keep going on this path. Send from my Samsung Galaxy Note II El 11/12/2013 21:10, Edward O'Connor eocon...@apple.com escribió: Hi, The name register is very generic and could mean practically anything. We need to adopt a name for document.register() that makes its purpose clear to authors looking to use custom elements or those reading someone else's code that makes use of custom elements. I support this proposal. Here are some ideas: document.defineElement() document.declareElement() document.registerElementDefinition() document.defineCustomElement() document.declareCustomElement() document.registerCustomElementDefinition() I like document.defineCustomElement() the most, but document.defineElement() also works for me if people think document.defineCustomElement() is too long. I think the method should be called registerElement, for these reasons: - It's more descriptive about the purpose of the method than just register. - It's not too verbose; it doesn't have any redundant part. - It's nicely parallel to registerProtocolHandler. If I had to pick from the list Ted suggested, I think defineElement is the best of that bunch and also an improvement over just register. It doesn't line up with registerProtocolHandler, but there's some poetry to defineElement/createElement. Ted P.S. Sorry for the bikeshedding. I really believe we can improve the name of this function to make its purpose clear. I searched for bugs on this and found none; I expect this was discussed but I can't find a mail thread about it. The naming of register is something that's been on my mind so thanks for bringing it up. Dominic
Re: [custom elements] Improving the name of document.register()
Thanks, Google folks, for considering a name to document.register. Though a small change, I think it will be a nice improvement to code clarity. Since we're bikeshedding, let me add a few more notes in favor of defineElement for consideration: 1) In programming languages, you would normally say you define or declare a function, class structure, variable, etc. I don't know of any language where you register a function or class. Defining a custom element seems parallel to these cases. It is true that one registers a COM object. At first glance, that may seem like an analogous operation, but I don't think it really is. COM registration is usually done out of band by a separate tool, not by the program itself at runtime. 2) registerElement sounds kind of like it would take an instance of Element and register it for some purpose. defineElement sounds more like it is introducing a new kind of element, rather than registering a concrete instance of an element.. 3) If we someday define a standardized declarative equivalent (note that I'm not necessarily saying we have to do so right now), defineElement has more natural analogs. For example, a define or definition element would convey the concept really well. But a register or registration or even register-element element would be a weird name. 4) The analogy to registerProtocolHandler is also not a great one, in my opinion. First, it has a different scope - it is on navigator and applies globally for the UI, rather than being on document and having scope limited to that document. Second, the true parallel to registerProtocolHandler would be registerElementDefinition. After all, it's not just called registerProtocol. That would be an odd name. But defineElement conveys the same idea as registerElementDefinition more concisely. The Web Components spec itself says Element registration is a process of adding an element definition to a registry. 5) Register with the parser is not a good description of what document.register does, either. It has an effect regardless of whether elements are created with the parser. The best description is what the custom elements spec itself calls it I feel that the preference for registerElement over defineElement may partly be inertia due to the old name being document.register. Think about it - is registerElement really the name you'd come up with, starting from a blank slate? I hope you will give more consideration to defineElement (which seems to be the most preferred candidate among the non-register-based names). Thanks, Maciej On Dec 12, 2013, at 10:09 PM, Dominic Cooney domin...@google.com wrote: On Fri, Dec 13, 2013 at 2:29 AM, Brian Kardell bkard...@gmail.com wrote: On Dec 11, 2013 11:48 PM, Ryosuke Niwa rn...@apple.com wrote: On Dec 11, 2013, at 6:46 PM, Dominic Cooney domin...@google.com wrote: ... El 11/12/2013 21:10, Edward O'Connor eocon...@apple.com escribió: Hi, The name register is very generic and could mean practically anything. We need to adopt a name for document.register() that makes its purpose clear to authors looking to use custom elements or those reading someone else's code that makes use of custom elements. I think the method should be called registerElement, for these reasons: - It's more descriptive about the purpose of the method than just register. - It's not too verbose; it doesn't have any redundant part. - It's nicely parallel to registerProtocolHandler. I'd still refer declareElement (or defineElement) since registerElement sounds as if we're registering an instance of element with something. Define and declare also match SGML/XML terminologies. - R. Niwa Define/declare seem a little confusing because we are in the imperative space where these have somewhat different connotations. It really does seem to me that conceptually we are registering (connecting the definition) with the parser or something. For whatever that comment is worth. While there's no consensus, I think this thread expresses a slightly stronger preference for registerElement than other proposals. I have filed this bug suggesting registerElement. https://www.w3.org/Bugs/Public/show_bug.cgi?id=24087 Dominic
Re: Passsword managers and autocomplete='off'
On Dec 12, 2013, at 11:20 AM, Joel Weinberger j...@chromium.org wrote: Hi all. For a while now, we have wanted on Chrome to ignore autocomplete='off' for password fields for the password manager. We believe that the current respect for autocomplete='off' for passwords is, in fact, harming the security of users by making browser password managers significantly less useful than they should be, thus discouraging their adoption, making it difficult for users to generate, store, and use more complex or (preferably) random passwords. Additionally, the added benefit of autocomplete='off' for security is questionable at best. We believe that our implementation of this ignore functionality actually falls within the letter of the web-forms standard. A user's password save for an autocomplete='off' field requires a user interaction to save (we do not do it automatically), which ultimately is not different than a copy/paste approach from the user. Additionally, we have taken precautions against password harvesting via XSS. We do not autofill into the DOM until the user has made a gesture (click, keypress, etc.) within the page, and we never autofill into iframe forms (we wait for a user to explicitly select their username from a dropdown). Part of the issue here is that autocomplete='off' is overloaded. It is simultaneously meant to denote a secure or sensitive field *or* that a field's completion will be handled by the application itself. Thus, we are not proposing to ignore autocomplete='off' for our form fill as there are many places where the application itself creates a suggestion box, and we have no desire to override that functionality. Rather, we care about the sensitive use, which in the case of password fields, is already denoted by the input type='password'. In the latest version of Chrome (currently in our Canary build), we have already implemented this feature. However, we will putting in behind a flag shortly so that it is not the default, but to still allow users to opt into this. We hope to make this the default for users in the not very distant future. What are this group's thoughts on this? Any particular concerns with this approach? While we believe that we are within the letter of the standards in our approach, we would love to see this made explicitly clear in the standards and hopefully see other browsers adopt this in the future, as we believe it is in the security interests of all users. Safari has similar behavior available as anon-default user preference: Allow AutoFill even for websites that request passwords not be saved. Even with this setting enabled, some user interaction is required both to save and to fill. We agree that on net, refusing to autofill passwords harms security. We did not make it the default, because website owners have objections to bypassing autofill=off as a default behavior. The primary types of objections are: (1) Public computer scenarios. Accidentally saving a password on a shared or public computer may endanger the user's account. (2) Casual walk-up attacks, for example temporary access to a friend's or relative's computer. AKA friendly fraud. At least some website operators (often for financial or shopping sites) are more worried about these threats than about the risk of users using lower quality or shared passwords passwords. This factor is magnified in Safari where we suggest autogenerated per-site random passwords, but only if we can autofill them. I do not know if we can collectively assuage the worries of sites that use autocomplete=off. So far, though, I'm not aware of any complaints about our non-default setting to bypass it. Regards, Maciej
Custom form elements (was Re: [webcomponents] Inheritance in Custom Elements (Was Proposal for Cross Origin Use Case and Declarative Syntax))
On Dec 7, 2013, at 4:38 PM, Dominic Cooney domin...@google.com wrote: Built-in HTML elements have lots of hooks to modify their behaviour (for example, HTMLVideoElement's autoplay attribute.) The analogy is extending a Java class which has private and public final members, but no protected or public non-final ones. If someone were to make proposals about adding more hooks to the web platform to enable more subtyping use cases (for example, a protocol for participating in form submission) I would look forward to working with them on those proposals. Let's say you have the ability to define a custom element inheriting from a form element, but completely replace its rendering and behavior with custom shadow DOM. Is that actually sufficient to participate correctly in form submission? I don't think it is. In particular, I don't see how a custom element could inherit from HTMLInputElement, fully support the interface, and correctly submit a value that is specified via a completely custom mechanism. Also, even if it worked, inheriting from HTMLInputElement is a particularly clunky approach to participating in form submission. To actually correctly support the interface, you need your component to support every input type. But that is way overkill if you only want to replace a single kind of input, or define a new type of your own. The more convenient approach would be to ignore type-switching and as a consequence make a subclass that does not respect the Liskov Substituton Principle and is therefore bad OO. I think giving custom elements a specific API for participating in form submission, to enable defining new kinds of form elements, would be a better approach to this problem and ultimately easier to use. It is also much more relevant as a way to explain how the way the Web platform works. Built-in form elements participate in form submission by having special hooks to participate in form submission, not by inheriting from other form elements. Regards, Maciej
Re: [webcomponents] Inheritance in Custom Elements (Was Proposal for Cross Origin Use Case and Declarative Syntax)
On Dec 10, 2013, at 12:24 PM, Elliott Sprehn espr...@chromium.org wrote: On Tue, Dec 10, 2013 at 8:00 AM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Dec 10, 2013 at 3:54 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 12/10/13 10:34 AM, Anne van Kesteren wrote: E.g. the dialog's close() method won't work as defined right now on a subclass of HTMLDialogElement. Why not? I assumed that actual ES6 subclassing, complete with invoking the right superclass @@create, would in fact produce an object for which this would work correctly. At least any situation that doesn't lead to that is a UA/spec bug. Well for one because the specification at the moment talks about a dialog element and does not consider the case where it may have been subclassed. The pending dialog stack is also for dialog elements only, not exposed in any way, etc. The way the platform is set up at the moment is very defensive and not very extensible. When extending native elements like that you use type extensions, so it'd be dialog is=my-subclass and the tagName is still DIALOG. Registering something that extends HTMLDialogElement but isn't a type extension of dialog does not work, in the same way that doing __proto__ = HTMLDivElement doesn't magically make you into a div today. The document.register method does not seem to support what you describe as currently spec'd, but does have an API doing the thing that won't actually work, i.e. registering my-subclass to be a subclass of HTMLDialogElement. Regards, Maciej
Re: [webcomponents] Auto-creating shadow DOM for custom elements
On Dec 9, 2013, at 11:13 AM, Scott Miles sjmi...@google.com wrote:
Domenic Denicola a few messages back gave a highly cogent explanation of the
exact line of thinking arrived at last time we went through all this
material.
I'm not wont to try to summarize it here, since he said it already better
there. Perhaps the short version is: nobody knows what the 'standard use
case' is yet.
In previous adjudications, the straw that broke that camel's back was with
respect to handling auto-generation with inheritance. Shadow-roots may need
to be generated for each entry in the inheritance chain. Having the system
perform this task takes it out of the control of the user's code, which
otherwise has ability to modulate calls to super-class methods and manage
this process.
class XFoo {
constructor_or_createdCallback: function() {
// my shadowRoot was auto-generated
this.doUsefulStuffLikeDatabinding(this.shadowRoot);
}
}
class XBar extends XFoo {
constructor_or_createdCallback: function() {
super(); // uh-oh, super call operates on wrong shadowRoot
}
}
If the shadow root is optionally automatically generated, it should probably be
passed to the createdCallback (or constructor) rather than made a property
named shadowRoot. That makes it possible to pass a different shadow root to
the base class than to the derived class, thus solving the problem.
Using an object property named shadowRoot would be a bad idea in any case
since it automatically breaks encapsulation. There needs to be a private way to
store the shadow root, either using ES6 symbols, or some new mechanism specific
to custom elements. As it is, there's no way for ES5 custom elements to have
private storage, which seems like a problem. They can't even use the closure
approach, because the constructor is not called and the methods are expected to
be on the prototype. (I guess you could create per-instance copies of the
methods closing over the private data in the created callback, but that would
preclude prototype monkeypatching of the sort built-in HTML elements allow.)
Regards,
Maciej
Re: [custom elements] Improving the name of document.register()
On Fri, Dec 13, 2013 at 5:44 PM, Kenneth Rohde Christiansen kenneth.christian...@gmail.com wrote: I also really like defineElement. I am not sure that it is easy to understand what it actually means to register an element, where as defining an element is pretty clear. Kenneth On Fri, Dec 13, 2013 at 9:40 AM, Maciej Stachowiak m...@apple.com wrote: Thanks, Google folks, for considering a name to document.register. Though a small change, I think it will be a nice improvement to code clarity. Since we're bikeshedding, let me add a few more notes in favor of defineElement for consideration: ... 2) registerElement sounds kind of like it would take an instance of Element and register it for some purpose. defineElement sounds more like it is introducing a new kind of element, rather than registering a concrete instance of an element.. I find all of Maciej's points persuasive, but particularly this one (#2). Given that Ted, Maciej, Ryosuke and Kenneth all expressed some degree of preference for defineElement over registerElement, it should be seriously considered. Brian, Scott, what do you think of defineElement? There were some doubts expressed about whether define reflects the imperative aspects of the API, but at least define arguably has a more imperative flavor than declare. I'd also like to hear what other vendors or developers think. Dominic
Re: [custom elements] Improving the name of document.register()
I found registerElement a good candidate and parallel to registerProtocolHandler, but after this comments I also think declareElement is a better alternative. +1 to it. Send from my Samsung Galaxy Note II El 13/12/2013 10:18, Dominic Cooney domin...@google.com escribió: On Fri, Dec 13, 2013 at 5:44 PM, Kenneth Rohde Christiansen kenneth.christian...@gmail.com wrote: I also really like defineElement. I am not sure that it is easy to understand what it actually means to register an element, where as defining an element is pretty clear. Kenneth On Fri, Dec 13, 2013 at 9:40 AM, Maciej Stachowiak m...@apple.com wrote: Thanks, Google folks, for considering a name to document.register. Though a small change, I think it will be a nice improvement to code clarity. Since we're bikeshedding, let me add a few more notes in favor of defineElement for consideration: ... 2) registerElement sounds kind of like it would take an instance of Element and register it for some purpose. defineElement sounds more like it is introducing a new kind of element, rather than registering a concrete instance of an element.. I find all of Maciej's points persuasive, but particularly this one (#2). Given that Ted, Maciej, Ryosuke and Kenneth all expressed some degree of preference for defineElement over registerElement, it should be seriously considered. Brian, Scott, what do you think of defineElement? There were some doubts expressed about whether define reflects the imperative aspects of the API, but at least define arguably has a more imperative flavor than declare. I'd also like to hear what other vendors or developers think. Dominic
Re: [webcomponents] Auto-creating shadow DOM for custom elements
On Dec 7, 2013, at 1:29 PM, Domenic Denicola dome...@domenicdenicola.com wrote: From: Brendan Eich [mailto:bren...@secure.meer.net] Requiring this kind of boilerplate out of the gave is not: this.createShadowRoot().appendChild(document.importNode(template.contents)); Wanting to avoid this kind of boilerplate is not a stab in the dark. Why can't we avoid it, even with separate specs that compose well? Part of composing well is not requiring excessive boilerplate. Part of the issue is that I don't think that's the boilerplate people will be using, uniformly. Adding a line to eliminate *that* boilerplate doesn't help all the other cases, e.g. ones without a shadow DOM but instead a normal DOM, or ones which don't use a template, or which don't use an imported template, or which use multiple nodes. There are lots of ways to create a fully-functioning custom element, and assuming that it will be done via a single imported template element put into a shadow DOM seems like a stab in the dark to me. In what way does that require using an imported template element specifically, as opposed to any template whatsoever? Note that importNode will DTRT whether the template comes from another document or not. Or even if I'm mistaken and it does not, you could specify that the template contents are cloned into the right document whether it was imported or not. Note also that using normal DOM instead of shadow DOM can be served by never using the optional feature (or by making a lightdom-template version if using custom elements with normal DOM becomes popular). Constructing shadow DOM programmatically can also be served by not using the optional feature, or by The other aspect of my critique was that scenario-solving this particular use case isn't very useful in light of the large number of other things people will be building out of our building blocks. Why assume this scenario is more common than, say, HTML imports + template elements? Why not add sugar for that? There's a lot of possible combinations that could benefit from some unifying sugar, but we just don't know which of them are actually useful yet. It's fine to allow those other things. It just seems like using all three of Custom Elements, Shadow DOM and Templates could be smoothed out without precluding those other options. It also seems like Polymer uses those three things together, so it seems unlikely that no one will do it. Using these three technologies together is very natural and pretending otherwise seems like an excessive level of agnosticism to me. BTW, I do think using HTML imports + template elements needs more sugar (there is no easy way afaik to instantiate a template defined in an imported document), but I am not sure it serves the same use cases. Regards, Maciej
[push-api] Discussion with TAG on December 19
One of the discussion topics for the TAG's December 19 call [Agenda] is the Push API [ED]. Members of the TAG have assembled comments in: https://github.com/w3ctag/spec-reviews/blob/master/2013/08/Push_API_initial_comments.md As well as the following thread: http://lists.w3.org/Archives/Public/www-tag/2013Dec/0028.html If this spec is of keen interest for you, please feel free to join the December 19 call (13:00 Boston time). Logistics are in the agenda page (join the W3C's #tagmem IRC channel at the start of the meeting to get the Zakim voice conference PIN). -Thanks, AB [Agenda] http://www.w3.org/wiki/TAG/planning/2013-12-19-TC [ED] http://dvcs.w3.org/hg/push/raw-file/default/index.html
Re: Call for Exclusions: DOM Parsing and Serialization
On Thu, Dec 12, 2013 at 6:31 PM, Charles McCathie Nevile cha...@yandex-team.ru wrote: It's unclear what you think we should be doing differently. Well, for instance, that when I point something out that was missed I am not directed to submit my feedback again, elsewhere. -- http://annevankesteren.nl/
Re: Allow javascript: URIs for registerProtocolHandler
On Wed, Nov 27, 2013 at 11:43 PM, Ian Hickson i...@hixie.ch wrote: On Wed, 18 Sep 2013, Anne van Kesteren wrote: Maybe. We'd lose the symmetry with registerContentHandler() unless we move its redirect-like logic to fetch as well, aside from the security implications. And cool feature is not a solid enough use case I think for the complexity it brings. The complexity is pretty low, no? (I agree that both kinds of registrations should work the same.) A problem would be that img src=data:... is no longer safe as it could execute a network request if the MIME type was text/vcard or some such. -- http://annevankesteren.nl/
Re: Allow javascript: URIs for registerProtocolHandler
On Fri, Dec 13, 2013 at 2:54 PM, Anne van Kesteren ann...@annevk.nl wrote: A problem would be that img src=data:... is no longer safe as it could execute a network request if the MIME type was text/vcard or some such. I also filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=24091 to further consider this. -- http://annevankesteren.nl/
Re: [custom elements] Improving the name of document.register()
On Dec 13, 2013 3:40 AM, Maciej Stachowiak m...@apple.com wrote: Thanks, Google folks, for considering a name to document.register. Though a small change, I think it will be a nice improvement to code clarity. Since we're bikeshedding, let me add a few more notes in favor of defineElement for consideration: 1) In programming languages, you would normally say you define or declare a function, class structure, variable, etc. I don't know of any language where you register a function or class. My earlier comment/concern about confusion and overloaded terms was about this exactly. The language we are in here is js and we define a class structure by subclassing, right? The element is defined, its just that that alone isn't enough - it has to be connected/plugged in to the larger system by way of a pattern - primarily the parser, right? 2) registerElement sounds kind of like it would take an instance of Element and register it for some purpose. defineElement sounds more like it is introducing a new kind of element, rather than registering a concrete instance of an element.. I don't disagree with that. all proposals are partially misleading/not quite crystal clear IMO. I don't think registerElement is the height of perfection either and perhaps reasonable people could disagree on which is clearer. At the end of the day I am inclined to not let perfect be the enemy of good. 3) If we someday define a standardized declarative equivalent (note that I'm not necessarily saying we have to do so right now), defineElement has more natural analogs. For example, a define or definition element would convey the concept really well. But a register or registration or even register-element element would be a weird name. Seems a similar problem here - you could be defining anything, plus HTML already has a dfn...What about element? That's already on the table after a lot of discussion I thought - is it not what you meant? 4) The analogy to registerProtocolHandler is also not a great one, in my opinion. First, it has a different scope - it is on navigator and applies globally for the UI, rather than being on document and having scope limited to that document. Second, the true parallel to registerProtocolHandler would be registerElementDefinition. After all, it's not just called registerProtocol. That would be an odd name. But defineElement conveys the same idea as registerElementDefinition more concisely. The Web Components spec itself says Element registration is a process of adding an element definition to a registry. The scope part seems not huge to me... But by the same kind of argument, you might just as easily make the case that what we are really lacking is a registry member or something not entirely unlike jQuery's plugins conceptually. 5) Register with the parser is not a good description of what document.register does, either. It has an effect regardless of whether elements are created with the parser. The best description is what the custom elements spec itself calls it Can you elaborate there? What effect? Lifecycle stuff via new? I feel that the preference for registerElement over defineElement may partly be inertia due to the old name being document.register. Think about it - is registerElement really the name you'd come up with, starting from a blank slate? For me, i think it still would be if i wound up with a document level method as opposed to some other approach like a registry object. But again, i am of the opinion that none of these is perfect and to some extent reasonable people can disagree.. I am largely not trying to convince anyone that one way is right. If it goes down as defineElement, the world still wins IMO. I hope you will give more consideration to defineElement (which seems to be the most preferred candidate among the non-register-based names). Thanks, Maciej On Dec 12, 2013, at 10:09 PM, Dominic Cooney domin...@google.com wrote: On Fri, Dec 13, 2013 at 2:29 AM, Brian Kardell bkard...@gmail.com wrote: On Dec 11, 2013 11:48 PM, Ryosuke Niwa rn...@apple.com wrote: On Dec 11, 2013, at 6:46 PM, Dominic Cooney domin...@google.com wrote: ... El 11/12/2013 21:10, Edward O'Connor eocon...@apple.com escribió: Hi, The name register is very generic and could mean practically anything. We need to adopt a name for document.register() that makes its purpose clear to authors looking to use custom elements or those reading someone else's code that makes use of custom elements. I think the method should be called registerElement, for these reasons: - It's more descriptive about the purpose of the method than just register. - It's not too verbose; it doesn't have any redundant part. - It's nicely parallel to registerProtocolHandler. I'd still refer declareElement (or defineElement) since registerElement sounds as if we're registering an instance of element with something. Define and declare also match SGML/XML
Re: [webcomponents] Auto-creating shadow DOM for custom elements
You cannot pass the shadow root to the constructor, because each class in
the chain can have it's own shadow root. This is the core of the problem.
On Fri, Dec 13, 2013 at 1:16 AM, Maciej Stachowiak m...@apple.com wrote:
On Dec 9, 2013, at 11:13 AM, Scott Miles sjmi...@google.com wrote:
Domenic Denicola a few messages back gave a highly cogent explanation of
the exact line of thinking arrived at last time we went through all this
material.
I'm not wont to try to summarize it here, since he said it already better
there. Perhaps the short version is: nobody knows what the 'standard use
case' is yet.
In previous adjudications, the straw that broke that camel's back was with
respect to handling auto-generation with inheritance. Shadow-roots may need
to be generated for each entry in the inheritance chain. Having the system
perform this task takes it out of the control of the user's code, which
otherwise has ability to modulate calls to super-class methods and manage
this process.
class XFoo {
constructor_or_createdCallback: function() {
// my shadowRoot was auto-generated
this.doUsefulStuffLikeDatabinding(this.shadowRoot);
}
}
class XBar extends XFoo {
constructor_or_createdCallback: function() {
super(); // uh-oh, super call operates on wrong shadowRoot
}
}
If the shadow root is optionally automatically generated, it should
probably be passed to the createdCallback (or constructor) rather than made
a property named shadowRoot. That makes it possible to pass a different
shadow root to the base class than to the derived class, thus solving the
problem.
Using an object property named shadowRoot would be a bad idea in any
case since it automatically breaks encapsulation. There needs to be a
private way to store the shadow root, either using ES6 symbols, or some new
mechanism specific to custom elements. As it is, there's no way for ES5
custom elements to have private storage, which seems like a problem. They
can't even use the closure approach, because the constructor is not called
and the methods are expected to be on the prototype. (I guess you could
create per-instance copies of the methods closing over the private data in
the created callback, but that would preclude prototype monkeypatching of
the sort built-in HTML elements allow.)
Regards,
Maciej
Re: File API: closed Blob objects
On Dec 13, 2013 5:05 AM, Anne van Kesteren ann...@annevk.nl wrote: On Thu, Dec 12, 2013 at 8:14 PM, Jonas Sicking jo...@sicking.cc wrote: On Dec 12, 2013 11:06 AM, Boris Zbarsky bzbar...@mit.edu wrote: Or form submission after fileInput.files[0].close() ? Hmm... maybe not actually. That would make things complicated once we start allowing things like input.files.push(blob). It is also problematic for FormData. What does FormData do if reading from a Blob fails due to IO error? / Jonas
Re: IndexedDB: Syntax for specifying persistent/temporary storage
Good writeup, Jonas--I think you've hit the major points. I think numeric priorities are both overkill and underpowered, depending upon their specific implementation. Without the promise we're currently making for Persistent storage [this will never be cleared unless you do it or the user explicitly requests it], numeric priorities are ultimately weaker than apps want. Unless we say that the top priority is the same as persistent, in which case we've added complexity without taking any away. The idea of Default is kind of appealing, and easy to migrate over to, but I'm not sure it's necessary. As Kinuko says, we can just unlock Persistent storage for apps on install, and let them migrate over whichever data needs it. This would work better if we supplied a tool to do an atomic migration, though--using the current APIs, apps would have to use 2x their storage during the transition, and browser developers might be able to implement it internally with a simple flag change or directory rename. I don't have a strong opinion there, but I lean toward just the two types rather than three. As for Alex's please clear up space event--it's not clear to me how to do that cleanly for apps that aren't currently loaded, which may need to talk to servers that aren't currently running, which the user may never plan to run again, or which require credentials to access their stored data, etc. On Wed, Dec 11, 2013 at 7:39 PM, Jonas Sicking jo...@sicking.cc wrote: Hi All, Thanks Jan for sending this. Now let me throw a giant wrench into this discussion :-) Unfortunately as we've been discussing webapps, manifests etc at mozilla I've slowly come to the realization that the temporary/persistent categorization isn't really fulfilling all the envisioned use cases. The background is that multiple platforms are now building the functionality to run normal websites outside of the browser. iOS was one of the first popular implementations of this. If you put a meta name=apple-mobile-web-app-capable content=yes in the markup of a page, and the user use bookmark to homescreen feature in iOS Safari, that almost turns the website into an app [1]. Google is currently working on implementing the same feature in Chrome for Android. At mozilla we created a proposal [2] for what is essentially a standardized version of the same idea. I think this approach is a really awesome use of the web and something that I'm very interested in supporting when designing these storage APIs. To support this use case, I think it needs to be possible for a website to first start as a website which the user only has a casual connection with, then gradually grow into something that the user essentially treats as a trusted app. Such a trusted app should have much more ability to store data without having to ask the user for permission, or without that data being suddenly deleted because we're low on disk space. In short, such an app should be treated more like a native app when it comes to storage. There are a few ways we can enable this use case. In the discussion below I'll use IndexedDB as an example of storage API, but it applies to all storage APIs equally. A) The temporary/persistent split almost enables this. We could say that when something that's a normal website stores data in temporary storage we count that data towards both per-origin and global quotas. If the global quota fills up, then we silently delete data from websites in an LRU fashion. If the user converts the website to an app by using bookmark to homescreen then we simply start treating the data stored in the temporary storage as persistent. I.e. we don't count it towards the global temporary-storage quota and we never delete it in order to make room for other websites. For persistent databases we would for normal websites put up a prompt (I'll leave out details like if this happens only when the quota API is used, or if can happen when the database is being written to). If persistent storage is used by a bookmarked app we simply would not prompt. In neither case would data stored in persistent storage ever be silently deleted in order to make room for other storage. The problem with this solution is that it doesn't give bookmarked apps the ability to create truly temporary data. Even data that a bookmarked app puts in the temporary storage is effectively treated as persistent and so not deleted if we start to run low on disk space. Temporary storage for apps is a feature that Android has, and that to some extent *nix OSs has had through use of /tmp. It definite is something that seems nice for constrained mobile devices. B) We could create a temporary/default/persistent split. I.e. we create three different storage categories. The default is what's used if no storage category is explicitly specified a IDB database is created. For normal webpages default is treated like temporary. I.e. it is counted towards
Re: Passsword managers and autocomplete='off'
On Thu, 12 Dec 2013, Joel Weinberger wrote: This is a feature (or anti-feature, depending on your perspective :-) that has been touted as good security for quite some time (in fact, the W3C spec specifically calls it out in that regard). Which spec are we talking about here? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [webcomponents] Auto-creating shadow DOM for custom elements
Why does each class in the chain need a shadow root?
It seems to me that each class just needs a root. If we model this
explicitly in the lifecycle with something like
'applyTemplateCallback(root)' then each inheritor is passed a dom element
(maybe it's in the shadow dom..maybe it isn't). The subclass then just adds
their visuals onto the root and then (optionally) calls to their base
class' implementation of applyTemplateCallback, passing whatever dom
element they want the super class to use as its root. The ultimate subclass
can be passed the actual shadow root automatically.
This allows subclasses to easily replace the super class' view or to
decorate it. If they only want to add behavior to an existing element
without changing the view, they just don't implement the callback at all.
On Fri, Dec 13, 2013 at 12:18 PM, Scott Miles sjmi...@google.com wrote:
You cannot pass the shadow root to the constructor, because each class in
the chain can have it's own shadow root. This is the core of the problem.
On Fri, Dec 13, 2013 at 1:16 AM, Maciej Stachowiak m...@apple.com wrote:
On Dec 9, 2013, at 11:13 AM, Scott Miles sjmi...@google.com wrote:
Domenic Denicola a few messages back gave a highly cogent explanation of
the exact line of thinking arrived at last time we went through all this
material.
I'm not wont to try to summarize it here, since he said it already better
there. Perhaps the short version is: nobody knows what the 'standard use
case' is yet.
In previous adjudications, the straw that broke that camel's back was
with respect to handling auto-generation with inheritance. Shadow-roots may
need to be generated for each entry in the inheritance chain. Having the
system perform this task takes it out of the control of the user's code,
which otherwise has ability to modulate calls to super-class methods and
manage this process.
class XFoo {
constructor_or_createdCallback: function() {
// my shadowRoot was auto-generated
this.doUsefulStuffLikeDatabinding(this.shadowRoot);
}
}
class XBar extends XFoo {
constructor_or_createdCallback: function() {
super(); // uh-oh, super call operates on wrong shadowRoot
}
}
If the shadow root is optionally automatically generated, it should
probably be passed to the createdCallback (or constructor) rather than made
a property named shadowRoot. That makes it possible to pass a different
shadow root to the base class than to the derived class, thus solving the
problem.
Using an object property named shadowRoot would be a bad idea in any
case since it automatically breaks encapsulation. There needs to be a
private way to store the shadow root, either using ES6 symbols, or some new
mechanism specific to custom elements. As it is, there's no way for ES5
custom elements to have private storage, which seems like a problem. They
can't even use the closure approach, because the constructor is not called
and the methods are expected to be on the prototype. (I guess you could
create per-instance copies of the methods closing over the private data in
the created callback, but that would preclude prototype monkeypatching of
the sort built-in HTML elements allow.)
Regards,
Maciej
--
Rob Eisenberg,
President - Blue Spire
www.durandaljs.com
Re: [webcomponents] Auto-creating shadow DOM for custom elements
On Fri, Dec 13, 2013 at 1:16 AM, Maciej Stachowiak m...@apple.com wrote: On Dec 9, 2013, at 11:13 AM, Scott Miles sjmi...@google.com wrote: ... If the shadow root is optionally automatically generated, it should probably be passed to the createdCallback (or constructor) rather than made a property named shadowRoot. That makes it possible to pass a different shadow root to the base class than to the derived class, thus solving the problem. Why generate it at all then? Since you're going to need to do super(this.createShadowRoot()) for each super call we only save the call to createShadowRoot() on the base class with a loss of flexibility or an increase in configuration options (ex. being able to turn off the auto creation). Instead we should just let authors make these decisions. Using an object property named shadowRoot would be a bad idea in any case since it automatically breaks encapsulation. There needs to be a private way to store the shadow root, either using ES6 symbols, or some new mechanism specific to custom elements. We discussed this many months ago on this list, but there's no way to create real encapsulation like that because authors will just override Element.prototype.createShadowRoot or Node.prototype.appendChild and hijack your ShadowRoot. Making it private is a lie, and leads to false security assumptions from authors. We had several teams here attempt to use ShadowRoot as a security boundary, which is just can't be, because you're sharing the same JS global prototypes. As it is, there's no way for ES5 custom elements to have private storage, which seems like a problem. They can't even use the closure approach, because the constructor is not called and the methods are expected to be on the prototype. (I guess you could create per-instance copies of the methods closing over the private data in the created callback, but that would preclude prototype monkeypatching of the sort built-in HTML elements allow.) I'm not sure what you mean. How would calling the constructor help you? Private storage can be had with ES6's SideTable (formerly WeakMap), making it inconvenient to get the ShadowRoot from an Element just gives false assumptions about how private it is. - E
