tive. For
sure, I'd at least like a shorter attribute name 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.
wrote:
> On Fri, May 15, 2015 at 4:58 PM, Scott Miles wrote:
> > Polymer really wants S
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 imp
I know this is probably the wrong place/time to say this, but fwiw, a
primary use case for imports is replacing:
Having the imported stylesheets apply to the main document is a big part of
the value here. If the stylesheets are for some other purpose, it's easy to
put them in a , but the re
n is major hassle.
I'm not sure what you mean, can you elaborate? 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 wrote:
> On Sat, Oct 4, 2014 at 7:00 PM, Scott Miles wrote:
> > An issue is that a rela
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 fr
cript? 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 wrote:
> Some of the ways Polymer team uses imports are as follows:
>
> - aggregating
Some of the ways Polymer team uses imports are as follows:
- aggregating
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
markup
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 26,
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 wrote:
>
> On Dec 9, 2013, at 11:13 AM, Scott Miles wrote:
>
> Domen
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 wrote:
> On Thu, Dec 12, 2013 at 5:17 AM, pira...@gmail.com wrote:
>
>> I have seen registe
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
>> We don't think decoupling custom elements and shadow DOM completely is
useful given that most important and natural use cases of custom elements
involve the use of shadow DOM.
Separating concerns is always useful, especially when it involves
contentious standards.
I also would like to point ou
> 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 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
wrote:
>
>
>
> On Mon, Nov 18, 2013 at 3:06 PM, Scott Miles wrote:
>
>>
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, a
>> 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 throug
begs the question, which
is: if we allow "Expressing 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
wrote:
>
>
>
> On Mon, Nov 18, 2013 at 2:33 PM, Scott
>> 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
> 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 deli
>> 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 u
On Mon, Oct 7, 2013 at 3:24 AM, James Graham 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 you should.
> 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
blood-curling
> >
> document.querySelector('x-nurk').shadowRoot.querySelector('#woot').shadowRoot.querySelector('#zorp')
> > chains of hell -- a problem that these new combinators would solve.
> >
> > Think of them simply general combinato
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 e
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' mod
ipt is a start. Is that
> sufficient or should we add a document.currentElement?
>
>
> On Wed, May 15, 2013 at 2:34 PM, Scott Miles wrote:
>
>> As long as there is a way to access the from the
As long as there is a way to access the from the
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 wrote:
>
>
>
> On Tue, May 14, 2013 at 4:01 PM, Scott Miles wrote:
>
>> I can't t
It's not clear to me why 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 wrote:
> On Tue, 14 May 2013 23:13:13 +0200, Dimitri Glazkov
> wrote:
>
> On Tue
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 loading
isagree with you
here.
With respect 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 wrote:
> On May 1, 2013, at 1
don't want this to be a sticking point.
>
> :DG<
>
> On Wed, May 1, 2013 at 12:46 PM, Scott Miles wrote:
> >>> Note that the interesting restriction isn't that it "shouldn't regress
> >>> performance for the web-at-large".
> >
&g
>> 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
> 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
Hello,
This is an interesting suggestion. Here are some notes:
Reducing to one insertion point doesn't, in itself, eliminate
>> distribution, getDistributedNodes(), etc
>>
I assume you mean "one insertion point that always selects everything".
Also, fwiw,
>>
we use for inheritance.
And
>
The key concept is that, to avoid timing issues, neither processing
nor evaluating [function-to-be-named-later] 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 of the rest is syntax,
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 lik
document.register and that doesn't cause hives (see
what I did there?).
Scott
On Mon, Apr 15, 2013 at 2:23 PM, John J Barton
wrote:
>
>
>
> On Mon, Apr 15, 2013 at 2:01 PM, Scott Miles wrote:
>
>> >> What happens if the construction/initialization of the cu
ustom element declared in mark-up? (I'm cheating, since this issue isn't
> specific to your )
>
>
> On Mon, Apr 15, 2013 at 12:39 PM, Scott Miles 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 a prototype without
hn J Barton wrote:
>
>
>
> On Mon, Apr 15, 2013 at 11:29 AM, Scott Miles wrote:
>
>> Thank you for your patience. :)
>>
> ditto.
>
>>
>>
>
>> > ? user's instance code? Do you mean: Running component instance
>> initialization d
>
>
> On Mon, Apr 15, 2013 at 9:44 AM, Scott Miles 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?
>&
'x-foo');
xfoo.doImportantThing();
On Mon, Apr 15, 2013 at 9:46 AM, Scott Miles 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 inherite
et me do some research.
On Mon, Apr 15, 2013 at 9:44 AM, Scott Miles 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
than callbacks?
>
> Thanks,
> jjb
> On Apr 15, 2013 9:04 AM, "Scott Miles" 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-
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,
me
>> before #4 is practical.*
>>
>> Yes, it will be along time, especially for IE9 and 10 (read: never),
>> which are support targets for custom element polyfills. Reliance on
>> anything that is optional or future should be avoided for the custom
>> element base case.
al or future should be avoided for the custom element base case.
> Right now the polyfills for document.register(), and a few of the
> declarative proposals, can give developers these awesome APIs today -
> please, do not imperil this.
>
>
>
> On Sun, Apr 14, 2013 at 12:22 PM, S
I almost forgot, there is a secondary problem with 'normal constructors',
see here:
http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0728.html
Sorry in advance, lol.
On Sun, Apr 14, 2013 at 12:22 PM, Scott Miles wrote:
> errata: XFooPrototype =
tends HTMLElement {
// any constructor here will be ignored
readyCallback() { // we invented this for constructor-like semantics
super();
}
}
// capture the real constructor if you care
[XFoo =] document.register('x-foo', XFooThunk);
On Sun, Apr 14, 2013 at 12:07 PM, Allen
errata: XFooPrototype = Object.create(HTMLElement.prototype, {
On Sun, Apr 14, 2013 at 12:21 PM, Scott Miles wrote:
> >> Alex Russell have been advocating that WebIDL should be allow
> constructor-like interfaces
>
> Absolutely agree. But these are horns of this dilemma.
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
wrote:
>
> On Apr 14, 2013, at 10:49 AM, Scott Miles wrote:
>
> >> the challenge with
y in.
>> 2, 3, 4
I believe have been suggested 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
wrote:
>
> On Apr 13, 2013, at 9:13 PM
>> 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
gt; argument for opting out of de-duping.
>
>
If there is no automatic de-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
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 wrote:
> Well ok, that's
> 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 , so it's a
allowing
> > custom elements to stamp out light DOM is a new semantic, that isn't
> > obviously solving 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
t 1:53 PM, Erik Arvidsson wrote:
> 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 wrote:
>
>> I made an attempt to describe how t
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 wrote:
> input/video would have intrinsic Shadow DOM, so it would not ever be part
> of outerHTML.
>
> I don't have
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 wrote:
;node' (assuming all
dependencies exist).
On Wed, Apr 10, 2013 at 12:15 PM, Erik Arvidsson wrote:
> Once again, how would this work for input/video?
>
> Are you suggesting that `createShadowRoot` behaves different than when you
> create the shadow root using markup?
>
>
>
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 ,
so there is willingness to continue to use , but ideally without
nesting . In other words, perhaps can be a subtype of
.
Where
#x27;t want to include
> 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 wrote:
>
>> I don't see any
Glazkov wrote:
> On Tue, Apr 9, 2013 at 11:42 AM, Scott Miles 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&#
0, 2013 at 11:27 AM, Brian Kardell wrote:
>
> On Apr 10, 2013 1:24 PM, "Scott Miles" 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 is
>
ack to itself.
Again, treating (non intrinsic) Shadow DOM as outerHTML solves this problem
IMO.
Scott
On Wed, Apr 10, 2013 at 10:11 AM, Brian Kardell wrote:
> On Mon, Mar 18, 2013 at 5:05 PM, Scott Miles wrote:
> > I'm already on the record with A, but I have a question about
>
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?
Sc
AM, Dimitri Glazkov wrote:
> 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<
>
>
e creating your own custom audio element, and
setting the src should reload the data and start autoplaying or something),
you want to be able to specify the getter/setter and events that will
occur. I didn't see anything in the webcomponents/custom element specs that
would currently allow for th
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,
x27;components' to describe things so far. Let's not worry about
> the synonyms. So 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
vocative enough for even a novice to understand what
> is implied by it.
>
> - Angelina
>
>
> On Tue, Mar 26, 2013 at 4:19 PM, Scott Miles wrote:
>
>> Fwiw, my main concern is that for my team and for lots of other people I
>> communicate with, 'component'
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 complained
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 AM
In our work, we adopt a composition rule that a node knows about it's own
children and can have expectations of them, but can make no assumptions
about it's parent or siblings. As a coding model we've found it to be
deterministic enough to build sane constructions. For example, you can use
methods/
lement.prototype);
XFoo.prototype.readyCallback = XFoo; // tricky! pretend we are using our
ctor
// 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 wrote:
> The answ
27;s really part of it's outer-ness.
It's part of what makes A, it's not part of A's content.
Now I can send A's innerHTML to B with no problem. Or roundtrip A's content
with no problem.
I realize I've broken several standard laws, but in any event it seems
cons
Ok, well obviously, there are times when you don't want the 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 wro
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:
shadow stuff
light stuff
and then have the value of #foo.innerHTML still be
shadow stuff
lightstuff
I understand that for DOM, there
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 prod
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
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
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.
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
knowle
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 wrote:
> Mostly it's cognitive dissonance. It will be easy to trip ov
;
>
> On Fri, Mar 8, 2013 at 12:16 PM, Dimitri Glazkov
> wrote:
> > On Thu, Mar 7, 2013 at 2:35 PM, Scott Miles wrote:
> >> Currently, if I document.register something, it's my job to supply a
> >> complete prototype.
> >>
> >> For HTMLElement
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 HTMLElementEleme
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, D
On Mon, Feb 25, 2013 at 11:30 AM, Boris Zbarsky 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
on, but it's not in any spec that we can
find (yet).
On Mon, Feb 25, 2013 at 10:52 AM, Scott Miles 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)?
>
> Give
union of them. I
should not have qualified that difference. To be clear, the intersection 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>
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 under
+1
S
On Wed, Feb 20, 2013 at 4:04 PM, Dimitri Glazkov wrote:
> Folks,
>
> As of https://dvcs.w3.org/hg/webcomponents/rev/505225bb4a7b, the
> custom elements spec no longer has the extra plumbing for
> automatically creating all shadow trees along its inheritance chain.
> This responsibility now
will get from 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 wrote:
> On Wed, Feb 20, 2013 at 10:34 AM, Scott
ms 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 Mil
to inherit from it in the prototype
> creation/registration phase, is that not true?
> On Feb 19, 2013 8:26 PM, "Scott Miles" wrote:
>
>> Question: if I do
>>
>> FancyHeaderPrototype = Object.create(HTMLElement.prototype);
>> document.register('fanc
hough, 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 wrote:
>
>> >> I'd be a much happier camper if I d
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 , people
complain because the tag names do not match.
document.createElement('button').setAttribute('is', '
1 - 100 of 135 matches
Mail list logo
