https://www.w3.org/Bugs/Public/show_bug.cgi?id=22059
Takayoshi Kochi ko...@google.com changed:
What|Removed |Added
Status|RESOLVED|REOPENED
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
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
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
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
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
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
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
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
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
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:
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.
--
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
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
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
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:
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
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
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
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
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
21 matches
Mail list logo
