I implemented custom elements in Chrome (twice.) This looks reasonable to
me.
The exact timing of createdCallback and constructor running, and errors
around element creation, are different. If authors stick to the
restrictions of custom elements "v1" they should be fine, because th
elementClass {
// constructor() is used in v1 Custom Elements instead of
// createdCallback() as in v0.
constructor() {
super()
// If the following is true, then we know the user should
be using
// `document.registerElement
w it is forward parsable... But they haven't had a way to be useful.
Custom elements, make them useful, but put them in a compelling box that
allow us to add anything that isn't dasherized. That was a long long long
way in the making, I can't honestly see it being undone in an even stricter
fashi
h 'data-' so we can
> define easily new standard attribute names ('aria-*' or everything
> except for 'data-*'.)
We already have a similar restriction - custom elements names must
*contain* a dash.
~TJ
It would be good to restrict custom element's name to start with like
'x-' for the future standards. User-defined custom attributes; data
attributes are also restricted its name to start with 'data-' so we can
define easily new standard attribute names ('aria-*' or everything
except for
On Fri, Apr 22, 2016 at 8:24 PM, Anne van Kesteren wrote:
> On Sat, Apr 23, 2016 at 3:08 AM, /#!/JoePea wrote:
> > I really believe that we should be allowed to name our elements with any
> > name we wish, and that they should override native elements (that
On Sat, Apr 23, 2016 at 3:08 AM, /#!/JoePea wrote:
> I really believe that we should be allowed to name our elements with any
> name we wish, and that they should override native elements (that is future
> proof), and that overriding should be on some type of encapsulated basis
;> > That means we lose the lingua franca that HTML provides; two
>> > independent libraries can't ever depend on the core HTML elements,
>> > because the other library might have overridden some of them.
>>
>> Based on my idea of registering elements on a
r library might have overridden some of them.
>
> Based on my idea of registering elements on a per-shadow-root basis
> (
> https://discourse.wicg.io/t/proposal-register-custom-elements-onto-shadowdom-roots/1440
> ),
> then libraries could use any native or custom elements that the
ased on my idea of registering elements on a per-shadow-root basis
(https://discourse.wicg.io/t/proposal-register-custom-elements-onto-shadowdom-roots/1440),
then libraries could use any native or custom elements that they want
within their shadow roots. Shadow roots would provide encapsulation,
and elemen
On Wed, Apr 13, 2016 at 12:33 PM, /#!/JoePea <trus...@gmail.com> wrote:
> What if custom Elements simply override existing ones then?
>
> ```js
> shadowRoot.registerElement('div', MyElement)
> ```
That means we lose the lingua franca that HTML provides; two
independent librar
What if custom Elements simply override existing ones then?
```js
shadowRoot.registerElement('div', MyElement)
```
If overriding native elements was documented, it'd be fine. By
default, a blank document or shadow root has no elements registered,
so would use the native DIV. But, why not let
I personal don't mind the hyphenation requirement for custom elements. Tab
Atkins brings up a great point about ensuring that new elements will be
able to be added to spec without worry of name conflicts with existing
custom elements on the page. It's much more future proof, in my opinion.
On Wed
On Wed, Apr 13, 2016 at 11:12 AM, /#!/JoePea <trus...@gmail.com> wrote:
> I personally don't like this limitation. I think Custom Elements would
> be better if we could create elements that have
> , with the possible exception that we can't override the
> native elements.
I personally don't like this limitation. I think Custom Elements would
be better if we could create elements that have
, with the possible exception that we can't override the
native elements.
Based on my previous email about registering elements on shadow roots,
I think being able to choose
.
TLDR - ShadowDOM could be the encapsulation of HTML to Custom Elements
as JSX is the encapsulation of HTML to React Components (in a morphed
way, as obviously the mechanics are different).
Here's what a small component might look like:
```js
// --- HandyForm.js
import AwesomeButton from './AwesomeB
> On Apr 11, 2016, at 2:29 PM, /#!/JoePea <trus...@gmail.com> wrote:
>
> What if custom elements can be registered on a shadow-root basis, so
> that the author of a Custom Element (one that isn't registered by
> default) can register a bunch of elements that it's shadow roo
as it is with React (due to React's
aforementioned encapsulation and use of the JavaScript scopefor it's
"HTML elements"), maybe the Custom Element API can take advantage of
ShadowDOM instead of documents?
What if custom elements can be registered on a shadow-root basis, so
that the author o
Thanks Ryosuke! That's looking a lot better.
/#!/JoePea
On Mon, Apr 11, 2016 at 10:28 AM, Ryosuke Niwa <rn...@apple.com> wrote:
> That's exactly what we're doing. The latest spec uses ES6 class constructor
> to define custom elements. See an example below this section in DOM sp
.
Custom elements' `` is completely unlike that. In that case, `x-foo` is
a tag name, and a full participant in the DOM tree structure. It affects CSS
selector matching, APIs like querySelector and getElementsByTagName, and more.
It's not just a div.
As Ryosuke notes, it's very hard to imagine how
> On Apr 11, 2016, at 9:02 AM, /#!/JoePea <trus...@gmail.com> wrote:
>
> Is it possible to take an approach more similar to React where Custom
> Elements aren't registered in a global pool? What if two libraries we'd like
> to use define elements of the same name,
That's exactly what we're doing. The latest spec uses ES6 class constructor to
define custom elements. See an example below this section in DOM spec:
https://dom.spec.whatwg.org/#concept-element-custom-element-state
- R. Niwa
> On Apr 10, 2016, at 7:58 PM, /#!/JoePea <trus...@gmail.com&
Hello,
Is it possible to take an approach more similar to React where Custom
Elements aren't registered in a global pool? What if two libraries we'd
like to use define elements of the same name, and we wish to import these
via `import` and not modify the source code of our dependencies?
I don't
Hello Brian
The purpose of the motor-scene and motor-node elements is that they will be
easy to apply 3D transforms to (and WebGL soon), with easing for example. I
suppose a better approach for augmenting and existing DOM could be to
simply apply the transforms via selectors instead of trying to
On Sun, Apr 10, 2016 at 11:11 PM, /#!/JoePea wrote:
> The is="" attribute lets one specify that some element is actually an
> extended version of that element.
>
> But, in order for this to work, the Custom Element definition has to
> deliberately extend that same basic
The is="" attribute lets one specify that some element is actually an
extended version of that element.
But, in order for this to work, the Custom Element definition has to
deliberately extend that same basic element type or else it won't
work.
It'd be nice if a Custom Element definition could
From: Philippe Le Hegaret [mailto:p...@w3.org]
> But I hope you realize that coming in the W3C community, working with them
> for while, and then take things away to continue the work elsewhere is
> received as not working in good faith with the W3C community. This is not a
> judgment of
much enjoyed
working with the W3C community on the w3c/webcomponents issue tracker, and think the
collaboration there has been a success. It was a very helpful "incubation
phase" for custom elements.
I do believe that the W3C community enjoyed working with you as well. I
cer
munity on the w3c/webcomponents issue tracker,
and think the collaboration there has been a success. It was a very helpful
"incubation phase" for custom elements.
Now that the incubation is largely complete, they can graduate to the HTML and
DOM Standards, like was done with before.
I in
On Wed, Apr 6, 2016 at 9:17 PM, Léonie Watson <t...@tink.uk> wrote:
> Which means we're looking for someone (or more than one someone) to edit
> Custom Elements. Web Components are a key part of the Web Platform, so it's
> an interesting time to be part of the group working on
Hello WP,
We're looking for a new editor for the Custom Elements spec [1].
Dimitri Glazkov has stepped down as editor and will be greatly missed in the
role. Thank you for all your hard work Dimitri, you helped make Custom
Elements happen and it's very much appreciated.
Domenic Denicola briefly
> On Feb 26, 2016, at 3:36 PM, Elliott Sprehn wrote:
>
>
>
> On Fri, Feb 26, 2016 at 3:31 PM, Ryosuke Niwa wrote:
>>
>> > On Feb 26, 2016, at 3:22 PM, Elliott Sprehn wrote:
>> >
>> >
>> >
>> > On Fri, Feb 26, 2016 at 3:09 PM,
On Fri, Feb 26, 2016 at 3:31 PM, Ryosuke Niwa wrote:
>
> > On Feb 26, 2016, at 3:22 PM, Elliott Sprehn
> wrote:
> >
> >
> >
> > On Fri, Feb 26, 2016 at 3:09 PM, Ryosuke Niwa wrote:
> >>
> >> > On Feb 24, 2016, at 9:06 PM, Elliott Sprehn
> On Feb 26, 2016, at 3:22 PM, Elliott Sprehn wrote:
>
>
>
> On Fri, Feb 26, 2016 at 3:09 PM, Ryosuke Niwa wrote:
>>
>> > On Feb 24, 2016, at 9:06 PM, Elliott Sprehn wrote:
>> >
>> > Can you give a code example of how this
On Fri, Feb 26, 2016 at 3:09 PM, Ryosuke Niwa wrote:
>
> > On Feb 24, 2016, at 9:06 PM, Elliott Sprehn
> wrote:
> >
> > Can you give a code example of how this happens?
>
> For example, execCommand('Delete') would result in sequentially deleting
> nodes as
> On Feb 24, 2016, at 9:06 PM, Elliott Sprehn wrote:
>
> Can you give a code example of how this happens?
For example, execCommand('Delete') would result in sequentially deleting nodes
as needed.
During this compound operation, unload events may fire on iframes that got
;rn...@apple.com> wrote:
> >> Hi,
> >>
> >> We propose to change the lifecycle callback to be fired both before
> invoking author scripts (e.g. for dispatching events) and before returning
> to author scripts.
> >>
> >> Without this change, event li
; author scripts (e.g. for dispatching events) and before returning to author
>> scripts.
>>
>> Without this change, event listeners that call custom elements' methods
>> would end up seeing inconsistent states during compound DOM operation such
>> as Range.extractC
his change, event listeners that call custom elements' methods would
> end up seeing inconsistent states during compound DOM operation such as
> Range.extractContents and editing operations, and we would like to avoid that
> as much as possible.
These are the events we wanted to try and de
> On Feb 22, 2016, at 10:46 PM, Ryosuke Niwa wrote:
>
> Here are steps to construct a custom element as agreed during Jan F2F as I
> promised to write down [1] [2]:
There's a very appealing alternative to this, which doesn't involve having a
element construction stack per
er element definition to allow
construction of other custom elements inside a custom element's constructor.
Without such a stack per element definition, we would end up walking through
entries in the stack to find the "right" entry. Implementors are free to take
such an approach to minim
Hi,
We propose to change the lifecycle callback to be fired both before invoking
author scripts (e.g. for dispatching events) and before returning to author
scripts.
Without this change, event listeners that call custom elements' methods would
end up seeing inconsistent states during compound
Available at
https://www.w3.org/2016/01/25-webapps-minutes.html
Text version:
Web Platform - Custom Elements
25 Jan 2016
See also: [2]IRC log
[2] http://www.w3.org/2016/01/25-webapps-irc
Attendees
Present
Domenic_Denicola, Takayoshi_Kochi, LÃ
Hi all,
Here's WebKit team's feedback for custom elements.
== Constructor vs createdCallback ==
We would like to use constructor instead of created callback.
https://github.com/w3c/webcomponents/issues/139
At the meeting, we should discuss what happens when a constructor throws during
Random comments inline (other people from Mozilla may have different opinions)
On 01/24/2016 10:01 AM, Ryosuke Niwa wrote:
Hi all,
Here's WebKit team's feedback for custom elements.
== Constructor vs createdCallback ==
We would like to use constructor instead of created callback
:rn...@apple.com>>:
> >>
> >> > On Dec 8, 2015, at 2:55 AM, Chaals McCathie Nevile
> >> > <cha...@yandex-team.ru <mailto:cha...@yandex-team.ru>> wrote:
> >> >
> >> > On Mon, 07 Dec 2015 13:39:25 +1000, Chaals McCathie N
On Wed, 06 Jan 2016 11:59:55 +0100, Takayoshi Kochi (河内 隆仁)
wrote:
On Wed, Jan 6, 2016 at 7:00 PM, Ryosuke Niwa wrote:
> On Jan 6, 2016, at 12:05 AM, Takayoshi Kochi (河内 隆仁)
>
> Is there any option to attend this remotely (telcon or
AM, Chaals McCathie Nevile <cha...@yandex-team.ru>
>> > wrote:
>> >
>> > On Mon, 07 Dec 2015 13:39:25 +1000, Chaals McCathie Nevile
>> > <cha...@yandex-team.ru> wrote:
>> >
>> >> we are trying to shift the date of the Custom Eleme
015年12月9日(水) 10:26 Ryosuke Niwa <rn...@apple.com>:
> >>
> >> > On Dec 8, 2015, at 2:55 AM, Chaals McCathie Nevile <
> cha...@yandex-team.ru> wrote:
> >> >
> >> > On Mon, 07 Dec 2015 13:39:25 +1000, Chaals McCathie Nevile <
> cha...@
1000, Chaals McCathie Nevile <
> cha...@yandex-team.ru> wrote:
> >
> >> we are trying to shift the date of the Custom Elements meeting to *25*
> Jan, from the previously proposed date of 29th.
> >>
> >> We are currently looking for a host in the Bay area - o
xactly web components makes it easy enough to have mutually agreeing
> "enough" implementations of things. For example, I currently have a few
> custom elements for which I have both a "native" definition and an angular
> directive so that designers I know who write HTM
On Wed, Nov 25, 2015 at 3:16 PM, Domenic Denicola <d...@domenic.me> wrote:
> A bit ago Jan put together an initial draft of the "contentious bits" for
> custom elements, in preparation for our January F2F. Today I went through and
> expanded on the issues he put
On Thu, Dec 10, 2015 at 3:23 PM, Anne van Kesteren <ann...@annevk.nl> wrote:
> On Wed, Nov 25, 2015 at 3:16 PM, Domenic Denicola <d...@domenic.me> wrote:
> > A bit ago Jan put together an initial draft of the "contentious bits"
> for custom elements, in prepar
On Mon, 07 Dec 2015 13:39:25 +1000, Chaals McCathie Nevile
<cha...@yandex-team.ru> wrote:
we are trying to shift the date of the Custom Elements meeting to *25*
Jan, from the previously proposed date of 29th.
We are currently looking for a host in the Bay area - offers grat
> On Dec 8, 2015, at 2:55 AM, Chaals McCathie Nevile <cha...@yandex-team.ru>
> wrote:
>
> On Mon, 07 Dec 2015 13:39:25 +1000, Chaals McCathie Nevile
> <cha...@yandex-team.ru> wrote:
>
>> we are trying to shift the date of the Custom Elements meeting
Dear all,
we are trying to shift the date of the Custom Elements meeting to *25*
Jan, from the previously proposed date of 29th.
We are currently looking for a host in the Bay area - offers gratefully
received.
If you plan to attend, please add your name to the meeting page:
<ht
s bits" for
> custom elements, in preparation for our January F2F. Today I went through
> and expanded on the issues he put together, with the result at
> https://github.com/w3c/webcomponents/wiki/Custom-Elements:-Contentious-Bits.
> It morphed into a kind of agenda for the meeting, cont
On Sat, Oct 24, 2015 at 4:02 PM, Ryosuke Niwa <rn...@apple.com> wrote:
>
> > On Oct 24, 2015, at 9:55 AM, Elliott Sprehn <espr...@chromium.org>
> wrote:
> >
> > I've been thinking about ways to make custom elements violate the
> consistency principle l
> On Oct 24, 2015, at 9:55 AM, Elliott Sprehn <espr...@chromium.org> wrote:
>
> I've been thinking about ways to make custom elements violate the consistency
> principle less often and had a pretty awesome idea recently.
>
> Unfortunately I won't be at TPAC, but I'd l
I've been thinking about ways to make custom elements violate the
consistency principle less often and had a pretty awesome idea recently.
Unfortunately I won't be at TPAC, but I'd like to discuss this idea in
person. Can we setup a custom element discussion later in the year?
The current
From: Maciej Stachowiak [mailto:m...@apple.com]
On Aug 17, 2015, at 3:19 PM, Domenic Denicola d...@domenic.me wrote:
- Parser-created custom elements and upgraded custom elements will
have their constructor and attributeChange callbacks called at a time when all
their children
-blzlm_skvYTCFFrks=Fqq6RL3oe2zmH8pGykh6XfqVC6LYMZILABlqZPRGG74e=
I’ve written up in some detail what I consider to be the current
state-of-the-art in custom elements proposals. That is, if we take the
current spec, and modify it in ways that everyone agrees are good ideas, we
end up
Thank you for writing this up. Would be interesting to hear what
Maciej and Ryosuke think.
On Tue, Aug 18, 2015 at 12:19 AM, Domenic Denicola d...@domenic.me wrote:
- Use symbols instead of strings for custom element callbacks.
So the way this is done is that they are publicly available on the
In
https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Constructor-Dmitry.md
I’ve written up in some detail what I consider to be the current
state-of-the-art in custom elements proposals. That is, if we take the current
spec, and modify it in ways that everyone agrees are good ideas
From: Maciej Stachowiak [mailto:m...@apple.com]
Does that sound right to you?
If so, it is not much more appealing than prototype swizzling to us, since
our biggest concern is allowing natural use of ES6 classes.
Got it, thanks. So it really does sound like it comes down to
class XFoo
A while back we sent a consolidated pile of feedback on the Web Components
family of specs. In preparation for tomorrow's F2F, here is an update on our
positions. We've also changed the bugzilla links to point to relevant github
issues instead.
We're only covering Custom Elements (the main
Thanks very much for your feedback Maciej! I know we'll be talking a lot more
tomorrow, but one point in particular confused me:
From: Maciej Stachowiak [mailto:m...@apple.com]
4. Specifically, we don't really like the Optional Upgrades, Optional
Constructors proposal (seems like it's the
On Jul 20, 2015, at 10:29 PM, Domenic Denicola d...@domenic.me wrote:
Thanks very much for your feedback Maciej! I know we'll be talking a lot more
tomorrow, but one point in particular confused me:
From: Maciej Stachowiak [mailto:m...@apple.com]
4. Specifically, we don't really like
on Custom Elements and Shadow DOM
A while back we sent a consolidated pile of feedback on the Web Components
family of specs. In preparation for tomorrow's F2F, here is an update on our
positions. We've also changed the bugzilla links to point to relevant github
issues instead.
We're only
If the main draw of wanting custom constructors is to be able to interface with
other custom elements that may not have been upgraded, maybe we could skip the
custom constructor and all of its attached concerns altogether by adding some
sort of 'elementUpgraded' event to the document
On Fri, Jul 17, 2015 at 4:15 PM, Domenic Denicola d...@domenic.me wrote:
From: Anne van Kesteren [mailto:ann...@annevk.nl]
It fails atomically, based on the definition of innerHTML.
What if that 512 KiB of HTML contains img src=foo.png? Following
definitions, I assume we fire off the network
From: Anne van Kesteren [mailto:ann...@annevk.nl]
// What about
document.body.innerHTML = [512 KiB of normal HTML] x-foo/x-foo;
// ? does the HTML make it in, or does the operation fail atomically, or
something else?
It fails atomically, based on the definition of innerHTML.
What if
On Fri, Jul 17, 2015 at 5:47 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 7/17/15 10:38 AM, Anne van Kesteren wrote:
If I look at update the image data step 6 it seems it might be
fetched at a later point?
Yes, but in practice the fetch will go ahead, no? There's nothing to
prevent it from
On Thu, Jul 16, 2015 at 10:36 PM, Domenic Denicola d...@domenic.me wrote:
I have a related question: what happens if the constructor throws?
Right, this is the kind of thing we need to figure out.
!DOCTYPE html
script
use strict;
window.throwingMode = true;
class XFoo extends
On 7/17/15 12:05 PM, Anne van Kesteren wrote:
True, but either way this doesn't seem like a problem. You can create
a DocumentFragment, insert a new img, and then let it be GC'd,
today.
Sure. In practice it won't get GC'd until the load completes, which is
sucky, but that's life.
-Boris
On 7/17/15 10:38 AM, Anne van Kesteren wrote:
If I look at update the image data step 6 it seems it might be
fetched at a later point?
Yes, but in practice the fetch will go ahead, no? There's nothing to
prevent it from happening, so it's going to happen once you reach a
stable state...
the custom elements previous design with the use of
constructors. Basically, I think it should still be a two-stage creation model:
1. Native [internal] element is created with appropriate tag name,
attributes, etc.
2. JS constructor is called and provided the instance (as 'this')
#1
to rationalize the custom elements previous design with the use of
constructors. Basically, I think it should still be a two-stage creation
model:
1. Native [internal] element is created with appropriate tag name,
attributes, etc.
2. JS constructor is called and provided the instance
On 7/17/15 2:03 PM, Travis Leithead wrote:
Something magical happens here. The use of super() is supposed to call
the constructor of the HTMLElement class—but that’s not a normal JS
class. It doesn’t have a defined constructor() method
Sure, but neither does Array. What super() actually does
Hi all,
Over the last few days I’ve worked on two new potential ideas for custom
elements, hoping to shake things up with new possibilities. These are both
largely geared around how we react to the key custom elements question [1].
https://github.com/w3c/webcomponents/blob/gh-pages/proposals
On Jul 17, 2015, at 1:14 PM, Travis Leithead travis.leith...@microsoft.com
wrote:
From: Domenic Denicola [mailto:d...@domenic.me]
window.XFoo = document.registerElement(‘x-foo’, XFooStartup);
Why is XFoo different from XFooStartup? If I define a method in XFooStartup,
does it exist
From: Travis Leithead [mailto:travis.leith...@microsoft.com]
if super() is absolutely required for a constructor in a class
that extends something, is there a requirement about when in the
constructor method it be invoked? Must it always be the first call? Can it be
later on, say at the end
From: Domenic Denicola [mailto:d...@domenic.me]
From: Travis Leithead [mailto:travis.leith...@microsoft.com]
Something magical happens here. The use of super() is supposed to call the
constructor of the HTMLElement class—but that’s not a normal JS class. It
doesn’t have a defined
On 07/16/2015 08:30 AM, Domenic Denicola wrote:
From: Travis Leithead [mailto:travis.leith...@microsoft.com]
I've discussed this issue with some of Edge's key parser developers.
Awesome; thank you for doing that!
I believe to be the most straightforward approach that most closely matches
On Thu, Jul 16, 2015 at 6:49 PM, Domenic Denicola d...@domenic.me wrote:
Even if it can be specced/implemented, should it? I.e., why would this be OK
where MutationEvents are not?
Apart from the verbosity and performance issues with mutation events,
I think the main problem with mutation
On Thu, Jul 16, 2015 at 6:03 PM, Domenic Denicola d...@domenic.me wrote:
Ah OK, thanks. Is there any way to get a consensus from Mozilla as a whole,
preferably ahead of the F2F?
I think the problem is that nobody has yet tried to figure out what
invariants that would break and how we could
From: Anne van Kesteren [mailto:ann...@annevk.nl]
I think the problem is that nobody has yet tried to figure out what invariants
that would break and how we could solve them. I'm not too worried about
the parser as it already has script synchronization, but cloneNode(), ranges,
and editing,
From: Olli Pettay [mailto:o...@pettay.fi]
That is too strongly said, at least if you refer to my email (where I
expressed
my opinions, but as usually, others from Mozilla may have different opinions).
I said I'd prefer if we could avoid that [Running author code during
cloneNode(true)].
to implement.
Right, but that's not actually possible with custom constructors. In
particular, you need to insert the elements into the tree *after* calling out
to author code that constructs them. What you mention is more like the
currently-specced custom elements lifecycle callback approach
-
From: Domenic Denicola [mailto:d...@domenic.me]
Sent: Wednesday, July 15, 2015 20:45
To: public-webapps
Subject: The key custom elements question: custom constructors?
Hi all,
Ahead of next week's F2F, I'm trying to pull together some clarifying and
stage-setting materials, proposals
On Thu, Jul 16, 2015 at 9:49 AM, Domenic Denicola d...@domenic.me wrote:
From: Anne van Kesteren [mailto:ann...@annevk.nl]
I think the problem is that nobody has yet tried to figure out what
invariants
that would break and how we could solve them. I'm not too worried about
the parser as it
is more like the
currently-specced custom elements lifecycle callback approach.
Or am I misunderstanding?
No, that is a good point. The constructor callback does indeed need to
happen between an element is created and the element is inserted.
I think though that in this case it might be possible
-pattern that he'd like to avoid. He is a strong supporter of
the proto-swizzle technique that happens later with retro-active upgrades to
previously-seen custom elements. I am sympathetic to this concern, but have my
own reservations about the proto-swizzle technique.
-Original Message-
From
custom elements to have custom constructors, then those must run in
order to create properly-allocated instances of those elements;
there is simply no other way to create those objects. You can shuffle the
timing around a bit: e.g., while cloning a tree, you could either run the
constructors
clone documents, which
print preview on linux and Windows and printing use)
If one needs a special DOM tree for printing, beforeprint event should be
used to modify the DOM.
Sure, but you'd lose some stuff, e.g. canvas, and presumably custom
elements if they require copying some state, due
,
actually. Private state is allocated for DOM wrappers in Chromium today
(like Gecko), including Custom Elements; it's not a problem. DOM wrapper
creation is controlled by the UA, which can arrange for allocating the
slots.
Sure, but this assumes elements will be backed by something other than
and Windows and printing use)
If one needs a special DOM tree for printing, beforeprint event should be
used to modify the DOM.
Sure, but you'd lose some stuff, e.g. canvas, and presumably custom
elements if they require copying some state, due to the cloning.
(Unless it's doing more than just
(like Gecko), including Custom Elements; it's not a problem. DOM wrapper
creation is controlled by the UA, which can arrange for allocating the
slots.
Sure, but this assumes elements will be backed by something other than
JavaScript forever. Or at the very least that custom elements will
always
existing elements in terms of Custom Elements, you need
private state.
- Progressive Enhancement. The author can write more things in markup and
present them while loading definitions asynchronously. Unlike progressive
enhancement by finding and replacing nodes in the tree, prototype swizzling
guess that depends on what you want to enable. If you want to
recreate existing elements in terms of Custom Elements, you need
private state.
Yes. I am trying to interpret this in the context of the esdiscuss thread
you linked. I'm not sure I understand the problem with private state,
actually
1 - 100 of 645 matches
Mail list logo