Polymer really wants Shadow DOM natively, and we think the `slot` proposal
can work, so maybe let's avoid blocking on design of an imperative API
(which we still should make in the long run).
As our entire stack is built on Web Components, the Polymer team is highly
motivated to assist browser
than `content-slot`, but
seems like that bikeshedding can wait until later. ;)
Scott
On Fri, May 15, 2015 at 5:24 PM, Tab Atkins Jr. jackalm...@gmail.com
wrote:
On Fri, May 15, 2015 at 4:58 PM, Scott Miles sjmi...@google.com wrote:
Polymer really wants Shadow DOM natively, and we think the `slot
I know this is probably the wrong place/time to say this, but fwiw, a
primary use case for imports is replacing:
script src=my-lib/my-lib.js/script
!-- the script above might have some HTML in it, encoded as a string,
comment, or other hack --
!-- the script above may load additional dependencies
? If this is the root cause,
maybe we attack it there.
Thanks,
Scott
On Sun, Oct 5, 2014 at 1:09 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Sat, Oct 4, 2014 at 7:00 PM, Scott Miles sjmi...@google.com wrote:
An issue is that a relative URL is only correct as long as the `img
An issue is that a relative URL is only correct as long as the `img` (for
example) is owned by the import. If you migrate the element to the main
document, the path is now relative to the wrong base, and users are
confused. One can do `img.src = img.src;` before migrating the node, and
that will
Some of the ways Polymer team uses imports are as follows:
- aggregating script src and/or link rel=stylesheet elements into
functional units
- aggregating imports themselves into units
- expressing dependencies (N modules can each import jquery2-import.html
and I only get one copy of jquery)
-
-button
Is sweet-button implemented via Polymer? X-tags? Vanilla JavaScript? User
doesn't need to know to use the resource.
Ideally, best-of-breed technology emerges and the option to standardize is
still available.
On Tue, May 20, 2014 at 11:56 PM, Scott Miles sjmi...@google.com wrote:
Some
I certainly support some kind of per-element media query, or resize event,
if the well-known performance issues around these ideas can be resolved,
but otherwise Custom Elements don't have a lot to say about this problem.
Typically, when using a plain JS API (and not a custom declarative
Yes, I agree with what R. Niwa says.
I believe there are many variations on what should happen during element
lifecycle, and the element itself is best positioned to make those choices.
`:unresolved` is special because it exists a-priori to the element having
any control.
Scott
On Wed, Mar
I'm hoping there are some constraints we can impose on imports to allow
them to contain inline scripts to exist under CSP.
Failing that, we already have a tool ('vulcanizer') which can separate
scripts out of imports (and to the reverse as well).
Whether an import uses inline or external scripts
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
I also agree with Ted.
I prefer 'registerElement' because I'm used to the concept of registration
wrt custom elements, but I'm not ginding any axe.
Scott
On Wed, 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
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
seems a specification that seems really pushed/rushed
Since my team (Polymer) has been working with imports in practice for a
year-and-a-half (100% public and open-source, btw) this seems a strange
conclusion. But this is only my perspective, I'm still a standards n00b I
suppose.
In any case, I
I love the idea of making HTML imports *not* block rendering as the
default behavior
So, for what it's worth, the Polymer team has the exact opposite desire. I
of course acknowledge use cases where imports are being used to enhance
existing pages, but the assertion that this is the primary use
the dependency in JS then why doesn't 'async'
(or 'sync') get us both what we want?
Scott
On Mon, Nov 18, 2013 at 2:58 PM, John J Barton
johnjbar...@johnjbarton.comwrote:
On Mon, Nov 18, 2013 at 2:33 PM, Scott Miles sjmi...@google.com wrote:
I love the idea of making HTML imports *not* block
Scott, is that because of what I said above (why polymer has the exact
opposite desire)?
Yes. Plus some salt from the KISS principle.
I feel like it is maybe valuable to think that we should worry about
how you express [dependencies] in JS
I guess I thought ES6 modules already went through
I've made similar comments on various threads, so sorry if you've heard
this song before, but here are some basic comments:
The HTMLImports we've been working with so far is not primarily about JS,
it's about HTML.
There are already various ways to modularize JS, including requirejs, other
libs,
I believe the primary issue here is 'synchronous with respect to
rendering'. Seems like you ignored this issue. See Brian's post.
Scott
On Mon, Nov 18, 2013 at 5:47 PM, John J Barton
johnjbar...@johnjbarton.comwrote:
On Mon, Nov 18, 2013 at 3:06 PM, Scott Miles sjmi...@google.com wrote
pollute the window object with $, with ES6 modules around the corner
The $ was just an example, the import could also happily define one or more
modules. This concept allows us to decouple scoping from imports.
Now, the import is only a vehicle, but it advances the state of the art by
also
they'll have to use a closure to capture the document that the template
lives in
Yes, this is true. But stamping of templates tends to be something custom
elements are really good at, so this paritcular use case doesn't come up
very often.
Out of curiosity, what have the Polymer guys been
On Mon, Oct 7, 2013 at 3:24 AM, James Graham ja...@hoppipolla.co.uk wrote:
On 06/10/13 17:25, Dimitri Glazkov wrote:
And, if the script is executed against the global/window object of
the main document, can and should you be able to access the imported
document?
You can and
We should ask Polymer people: they wrote a ton of code with Imports now
and I bet they have opinions.
The Polymer team has successfully adopted/evolved the modality Dimitri
describes. Imported documents work roughly as #includes, and
`currentScript.ownerDocument` is interrogated if one needs to
I'm one of the guinea people, for whatever biases that gives me. Fwiw and
IMO, Dimitri summarized our thinking better than our own brains did.
finally ruined encapsulation?
As I see it the main Web Components system is based on soft encapsulation.
Each boundary is in force by default, but each
would expose their
parts for styling, but were still black boxes for interaction
purposes. Has that changed?
On Mon, Sep 9, 2013 at 5:29 PM, Scott Miles sjmi...@google.com wrote:
finally ruined encapsulation?
As I see it the main Web Components system is based on soft
encapsulation.
Each
Custom elements have a closure to work in, as well as their own prototypes.
I don't believe ES6 modules add much in this regard (possibly I'm missing
something there).
Separate global scope is a bigger issue.
I believe there was general agreement to pursue (at some point) an otp-in
'isolated'
As long as there is a way to access the element from the script, I'm
good.
On Wed, May 15, 2013 at 11:31 AM, Dimitri Glazkov dglaz...@google.comwrote:
Despite little love from Scott for the mischievous walrus -- }); --
proliferation across the Web, are there any other cries of horror that
I
is a start. Is that
sufficient or should we add a document.currentElement?
On Wed, May 15, 2013 at 2:34 PM, Scott Miles sjmi...@google.com wrote:
As long as there is a way to access the element from the script, I'm
good.
On Wed, May 15, 2013 at 11:31 AM, Dimitri Glazkov dglaz
I can't think of any reason I would want to be able to mess with an import
link ex-post-facto and have it do anything. I would also expect any
registrations to be final and have no particular connection to the link tag
itself.
Now, this may be tangential, but users definitely need a way of
It's not clear to me why link rel=import can't be dynamic. As long as
the previous document isn't somehow banished, I don't see the problem
(admittedly, looking through a keyhole).
On Tue, May 14, 2013 at 2:21 PM, Simon Pieters sim...@opera.com wrote:
On Tue, 14 May 2013 23:13:13 +0200,
I really didn't mean to suggest any particular name, just that an
imperative form should be provided or every lib will roll their own.
On Tue, May 14, 2013 at 1:45 PM, Rick Waldron waldron.r...@gmail.comwrote:
On Tue, May 14, 2013 at 4:01 PM, Scott Miles sjmi...@google.com wrote:
I can't
I'm concerned that we can never ship this feature due to the performance
penalties it imposes.
Can you be more explicit about the penalty to which you refer? I understand
there are concerns about whether the features can be made fast, but I
wasn't aware of an overall penalty on code that is not
Note that the interesting restriction isn't that it shouldn't regress
performance
for the web-at-large.
No argument, but afaict, the implication of R. Niwa's statement was was in
fact that there was a penalty for these features merely existing.
The restriction is that it shouldn't be slow
want this to be a sticking point.
:DG
On Wed, May 1, 2013 at 12:46 PM, Scott Miles sjmi...@google.com wrote:
Note that the interesting restriction isn't that it shouldn't regress
performance for the web-at-large.
No argument, but afaict, the implication of R. Niwa's statement
to my statement to which you refer, I'm only saying that we
haven't had a discussion about the costs or the features. The discussion
jumped straight to mitigation.
On Wed, May 1, 2013 at 9:45 PM, Ryosuke Niwa rn...@apple.com wrote:
On May 1, 2013, at 12:46 PM, Scott Miles sjmi...@google.com wrote
Hello,
This is an interesting suggestion. Here are some notes:
Reducing to one insertion point doesn't, in itself, eliminate
distribution, getDistributedNodes(), etc
content select
I assume you mean one insertion point that always selects everything.
Also, fwiw,
shadow
we use for
It probably goes without saying, but, as far as I know this is the best
idea on the table so far.
Couple notes:
erhmahgerd: { writable: false, value: BOOKS! }
I don't know why we would use 'propery definitions' there. If you let me
pass in an object, I can define the properties however I like.
The key concept is that, to avoid timing issues, neither processing
element nor evaluating script[function-to-be-named-later]/script are
the terminal point for defining an element.
Rather, at some third quantum of time a combination of those things is
constructed, keyed on 'element name'.
Most
Again, 'readyCallback' exists because it's a Bad Idea to run user code
during parsing (tree construction). Ready-time is not the same as
construct-time.
This is the Pinocchio problem:
http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0728.html
Scott
On Mon, Apr 15, 2013 at 7:45 AM,
, 2013 9:04 AM, Scott Miles sjmi...@google.com wrote:
Again, 'readyCallback' exists because it's a Bad Idea to run user code
during parsing (tree construction). Ready-time is not the same as
construct-time.
This is the Pinocchio problem:
http://lists.w3.org/Archives/Public/public-webapps
, 2013 at 9:44 AM, Scott Miles sjmi...@google.com wrote:
Why do the constructors of component instances run during component
loading?
I'm not sure what you are referring to. What does 'component loading' mean?
Why not use standard events rather than callbacks?
This was discussed quite a bit
');
xfoo.doImportantThing();
On Mon, Apr 15, 2013 at 9:46 AM, Scott Miles sjmi...@google.com wrote:
The callbacks are convenient because (1) there is no question of 'who
registers a listener' (2) I can simply call my 'super' callback (or not) to
get inherited behavior.
One minute later
instance, and then we upgrade them in a second pass.
On Mon, Apr 15, 2013 at 9:54 AM, John J Barton
johnjbar...@johnjbarton.comwrote:
On Mon, Apr 15, 2013 at 9:44 AM, Scott Miles sjmi...@google.com wrote:
Why do the constructors of component instances run during component
loading?
I'm
...@johnjbarton.com
wrote:
On Mon, Apr 15, 2013 at 11:29 AM, Scott Miles sjmi...@google.com wrote:
Thank you for your patience. :)
ditto.
? user's instance code? Do you mean: Running component instance
initialization during document construction is Bad?
My 'x-foo' has an 'init
cheating, since this issue isn't
specific to your prototype)
On Mon, Apr 15, 2013 at 12:39 PM, Scott Miles sjmi...@google.com wrote:
Sorry for beating this horse, because I don't like 'prototype' element
anymore than anybody else, but I can't help thinking if there was a way to
express
that doesn't cause hives (see
what I did there?).
Scott
On Mon, Apr 15, 2013 at 2:23 PM, John J Barton
johnjbar...@johnjbarton.comwrote:
On Mon, Apr 15, 2013 at 2:01 PM, Scott Miles sjmi...@google.com wrote:
What happens if the construction/initialization of the custom element
calls one
the challenge with creating a normal constructor
Forgive me if my language is imprecise, but the basic notion is that in
general one cannot create a constructor that creates a DOM node because
(most? all?) browsers make under the hood mappings to internal code (C++
for Blink and Webkit). For
in one form or another, but as I mentioned,
were determined to be non-starters for Gecko. I don't think we've heard
anything from IE team.
On Sun, Apr 14, 2013 at 11:28 AM, Allen Wirfs-Brock
al...@wirfs-brock.comwrote:
On Apr 13, 2013, at 9:13 PM, Scott Miles wrote:
I think if an element needs
Re: subclassing builtins, the problem we have is stated here:
http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0266.html
On Sun, Apr 14, 2013 at 11:52 AM, Allen Wirfs-Brock
al...@wirfs-brock.comwrote:
On Apr 14, 2013, at 10:49 AM, Scott Miles wrote:
the challenge
- please, do not imperil this.
After reading Scott Miles' post here
http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0209.html,
I have a better understanding of problem caused by these generated
HTML*Element constructors: they aren't constructable. No amount of ES6
subclass support
-duping then the author has to take care to
specifically avoid duplication in various cases. Therefore, it cannot be an
optimization, in the sense that it's not optional. It has to be required by
the spec or you cannot rely on it.
On Wed, Apr 10, 2013 at 11:56 AM, Scott Miles sjmi...@google.com
, treating (non intrinsic) Shadow DOM as outerHTML solves this problem
IMO.
Scott
On Wed, Apr 10, 2013 at 10:11 AM, Brian Kardell bkard...@gmail.com wrote:
On Mon, Mar 18, 2013 at 5:05 PM, Scott Miles sjmi...@google.com wrote:
I'm already on the record with A, but I have a question about
at 11:27 AM, Brian Kardell bkard...@gmail.com wrote:
On Apr 10, 2013 1:24 PM, Scott Miles sjmi...@google.com wrote:
So, what you quoted are thoughts I already deprecated mysefl in this
thread. :)
If you read a bit further, see that I realized that shadow-root is
really part of the 'outer
...@google.comwrote:
On Tue, Apr 9, 2013 at 11:42 AM, Scott Miles sjmi...@google.com wrote:
Duplicate fetching is not observable, but duplicate parsing and duplicate
copies are observable.
Preventing duplicate parsing and duplicate copies allows us to use
'imports'
without a secondary
a...@chromium.org wrote:
Maybe I'm missing something but we clearly don't want to include
shadowroot in the general innerHTML getter case. If I implement
input[type=range] using custom elements + shadow DOM I don't want innerHTML
to show the internal guts.
On Wed, Apr 10, 2013 at 2:30 PM, Scott Miles
Thank you for distilling all that down into digestible content (yum,
distillates).
A couple of notes:
The 'magic script' problem has been difficult to reconcile with template,
so there is willingness to continue to use element, but ideally without
nesting template. In other words, perhaps
, Scott Miles sjmi...@google.com wrote:
I think we all agree that node.innerHTML should not reveal node's
ShadowDOM, ever.
What I am arguing is that, if we have shadow-root element that you can
use to install shadow DOM into an arbitrary node, like this:
div
shadow-root
Decoration
No, strictly ergonomic. Less nesting and less characters (less nesting is
more important IMO).
I would also argue that there is less cognitive load on the author then the
more explicit factoring, but I believe this is subjective.
Scott
On Wed, Apr 10, 2013 at 12:36 PM, Rafael Weinstein
I made an attempt to describe how these things can be non-lossy here:
https://gist.github.com/sjmiles/5358120
On Wed, Apr 10, 2013 at 12:19 PM, Scott Miles sjmi...@google.com wrote:
input/video would have intrinsic Shadow DOM, so it would not ever be part
of outerHTML.
I don't have
:
For the record I'm opposed to what you are proposoing. I don't like that
you lose the symmetry between innerHTML and outerHTML.
On Wed, Apr 10, 2013 at 4:34 PM, Scott Miles sjmi...@google.com wrote:
I made an attempt to describe how these things can be non-lossy here:
https://gist.github.com
a problem which is either identified, or related to
web components. Did I miss earlier discussion about this?
On Wed, Apr 10, 2013 at 12:40 PM, Scott Miles sjmi...@google.com
wrote:
No, strictly ergonomic. Less nesting and less characters (less nesting
is
more important IMO).
I would
how that specific script tag knows what its this value is
I think I'm probably not answering your question, but I believe the notion
was that that script tag is handled specially by element, so it's a
script* which only ever executes in the 'scope' of element.
On Wed, Apr 10, 2013 at 2:54 PM,
and) mark up the shadowroot as if it were a child node.
If we decide that's a bad idea, the so be it, but I suggest that's a
separate argument from my claim that there can be a clean lossless mental
model for shadowroot markup.
On Wed, Apr 10, 2013 at 2:04 PM, Scott Miles sjmi...@google.com wrote
dglaz...@google.comwrote:
The trick here is to figure out whether de-duping is observable by the
author (other than as a performance gain). If it's not, it's a
performance optimization by a user agent. If it is, it's a spec
feature.
:DG
On Tue, Apr 9, 2013 at 10:53 AM, Scott Miles sjmi
When writing polyfills for HTMLImports/CustomElements, we included a
de-duping mechanism, so that the same document/script/stylesheet is not (1)
fetched twice from the network and (2) not parsed twice.
But these features are not in specification, and are not trivial as design
decisions.
WDYT?
did hear from Scott Miles that some work
had already been done, and that the custom element shim now already
supports an attributeChangedCallback function to do just this thing, but
that's a bit broader level than specific get/set behaviour on attributes.
Consider my gist to be some thinking out
far, the developers I've introduced to this subject
understood implicitly that they could build widgets with this stuff, all
the while I used the term 'components'.
Cheers,
- A
On Tue, Mar 26, 2013 at 10:58 PM, Scott Miles sjmi...@google.com wrote:
Forgive me if I'm perseverating, but do
This is great stuff Mike, thanks for making it available. I think we are
all #facepalm at the notion of self-documenting component files, very
clever.
making things that use components and custom elements is proving
extremely fun =)
Music to my ears.
Scott
On Tue, Mar 26, 2013 at 11:48 AM,
Fwiw, my main concern is that for my team and for lots of other people I
communicate with, 'component' is basically synonymous with 'custom
element'. In that context, 'component' referring to
chunk-of-web-resources-loaded-via-link is problematic, even if it's not
wrong, per se.
We never
what
is implied by it.
- Angelina
On Tue, Mar 26, 2013 at 4:19 PM, Scott Miles sjmi...@google.com wrote:
Fwiw, my main concern is that for my team and for lots of other people I
communicate with, 'component' is basically synonymous with 'custom
element'. In that context, 'component
Sorry for the late response, this is one of those bad cases where agreement
was expressed as silence.
This is a thorny problem, but my initial reaction is that you threaded the
needle appropriately. I don't see how we avoid some lossiness in this
situation.
Scott
On Mon, Mar 18, 2013 at 1:48
// almost what we want except we have to capture new XFoo on the
left-hand-side
XFoo = document.register(x-foo, XFoo);
On Wed, Mar 20, 2013 at 10:35 AM, Scott Miles sjmi...@google.com wrote:
The answer depends a bit on the particular implementation of
HTMLElementElement (aka element) that you
I'm already on the record with A, but I have a question about 'lossiness'.
With my web developer hat on, I wonder why I can't say:
div id=foo
shadowroot
shadow stuff
/shadowroot
light stuff
/div
and then have the value of #foo.innerHTML still be
shadowroot
shadow stuff
Ok, well obviously, there are times when you don't want the shadowroot to
be in innerHTML, so I was correct that I was grossly over simplifying. I
guess this is where the second kind of innHTML accessor comes in. Sorry!
It's still A though. :)
On Mon, Mar 18, 2013 at 2:05 PM, Scott Miles sjmi
consistent to itself.
On Mon, Mar 18, 2013 at 2:08 PM, Scott Miles sjmi...@google.com wrote:
Ok, well obviously, there are times when you don't want the shadowroot
to be in innerHTML, so I was correct that I was grossly over simplifying. I
guess this is where the second kind of innHTML accessor comes
Developers will absolutely concat components together, often the entire
apps worth. They will also use them separately. This flexibility is one of
the great strengths of this simple concept.
As Dimitri mentioned, Web Components solves a great many of the loader
issues (both at development and
My issue is that the target of this link will not in general be an atomic
thing like a 'component' or a 'module'. It's a carrier for resources and
links to other resources. IMO this is one of the great strengths of this
proposal.
For this reason, when it was rel=components (plural) there was no
at 12:16 PM, Dimitri Glazkov dglaz...@chromium.org
wrote:
On Thu, Mar 7, 2013 at 2:35 PM, Scott Miles sjmi...@google.com wrote:
Currently, if I document.register something, it's my job to supply a
complete prototype.
For HTMLElementElement on the other hand, I supply a tag name to
extend
I also want to keep ES6 classes in mind. Presumably in declarative form I
declare my class as if it extends nothing. Will 'super' still work in that
case?
Scott
On Fri, Mar 8, 2013 at 11:40 AM, Scott Miles sjmi...@google.com wrote:
Mostly it's cognitive dissonance. It will be easy to trip
IMO, there is no benefit to 'real' constructors other than technical
purity, which is no joke, but I hate to use that as a club to beat users
with.
This is strictly anecdotal, but I've played tricks with 'constructor'
before (in old Dojo) and there was much hand-wringing about it, but to my
Fwiw, I'm still following this thread, but so far Scott G. has been saying
everything I would say (good on ya, brother :P).
My understanding is that you have to explicitly ask to walk into the
shadow, so this wouldn't happen accidentally. Can someone please confirm or
deny this?
Confirmed. The
Agree. Seems like Dimitri and Anne decided that these targets are
'document', did they not?
Scott
On Fri, Mar 8, 2013 at 1:12 PM, Bronislav Klučka
bronislav.klu...@bauglir.com wrote:
hi
let's apply KISS here
how about just
rel=document
or
rel=htmldocument
Brona
On 8.3.2013 22:05,
Currently, if I document.register something, it's my job to supply a
complete prototype.
For HTMLElementElement on the other hand, I supply a tag name to extend,
and the prototype containing the extensions, and the system works out the
complete prototype.
However, this ability of
I favor #2. It's much simpler. Simple is good.
Fwiw, I'm filtering these things through the idea that someday we will be
able to do:
document.register(x-foo, XFoo);
That's the ultimate goal IMO, and when I channel Alex Russell (without
permission). =P
Scott
On Wed, Mar 6, 2013 at 1:55 PM,
I agree with Tab 100% on this.
You cannot accidentally stumble into ShadowDOM. You have to actively take
that step.
For one thing, I suggest that most of the time, the component code is
shipping w/your application, you are not depending on some resource that
will simply be upgraded out from
I
posed included monkey-patchers that require the update, not simply
monkey-patchers.
On Mon, Feb 25, 2013 at 10:37 AM, Bronislav Klučka
bronislav.klu...@bauglir.com wrote:
On 25.2.2013 19:15, Scott Miles wrote:
I agree with Tab 100% on this.
You cannot accidentally stumble
can
find (yet).
On Mon, Feb 25, 2013 at 10:52 AM, Scott Miles sjmi...@google.com wrote:
Don't we have a situation where people can simply take your source and
change it regardless (barring legal imperatives, which are orthogonal in my
view)?
Given Boris' arguments, Big Marketshare can simply
On Mon, Feb 25, 2013 at 11:30 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 2/25/13 1:52 PM, Scott Miles wrote:
Given Boris' arguments, Big Marketshare can simply always mess up his
project and blame me and it's my fault.
Scott,
That's how it often works in the court of public opinion
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
a constructor. We had a rule that you get
one kind of node for 'custom' elements and another for extensions of known
elements. But now it's more complicated.
Scott
On Wed, Feb 20, 2013 at 10:39 AM, Dimitri Glazkov dglaz...@google.comwrote:
On Wed, Feb 20, 2013 at 10:34 AM, Scott Miles sjmi...@google.com
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
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.
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
/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
MyButton = document.register(‘x-button’, {
prototype: MyButton.prototype,
lifecycle: {
created: MyButton
}
});
What's the benefit of allowing this syntax? I don't immediately see why you
couldn't just do it the other way.
On Thu, Feb 14, 2013 at 2:21 PM, Rick Waldron
, Feb 14, 2013 at 2:45 PM, Dimitri Glazkov dglaz...@google.comwrote:
On Thu, Feb 14, 2013 at 2:40 PM, Scott Miles sjmi...@google.com wrote:
In all constructions the *actual* calling of HTMLButtonElement is done by
the browser.
No, this is not correct. It's the exact opposite
On Thu, Feb 14, 2013 at 2:48 PM, Dimitri Glazkov dglaz...@google.comwrote:
On Thu, Feb 14, 2013 at 2:23 PM, Scott Miles sjmi...@google.com wrote:
MyButton = document.register(‘x-button’, {
prototype: MyButton.prototype,
lifecycle: {
created: MyButton
}
});
What's
a different method.
Yes, it's not ideal, but then there is only one way to write it.
On Thu, Feb 14, 2013 at 3:16 PM, Dimitri Glazkov dglaz...@google.comwrote:
On Thu, Feb 14, 2013 at 2:53 PM, Scott Miles sjmi...@google.com wrote:
Well, yes, here ya go: (o). But I must be missing something
, Feb 14, 2013 at 3:16 PM, Dimitri Glazkov dglaz...@google.comwrote:
On Thu, Feb 14, 2013 at 2:53 PM, Scott Miles sjmi...@google.com wrote:
Well, yes, here ya go: (o). But I must be missing something. You
wouldn't
propose two APIs if they were equivalent, and I don't see how
a custom element
without having to load a helper library first to make the nasty syntax go
away, which seems less than ideal. I donno, I'm not 100% either way.
Scott
On Fri, Feb 8, 2013 at 7:46 AM, Erik Arvidsson a...@chromium.org wrote:
On Thu, Feb 7, 2013 at 11:51 PM, Scott Miles sjmi
1 - 100 of 120 matches
Mail list logo
