Re: Defining a constructor for Element and friends

[Boris Zbarsky]

On 1/11/15 2:33 PM, Domenic Denicola wrote:

"Terminology: In what follows I use 'own-instances of X' to mean objects where 
obj.constructor === X,


That doesn't make much sense to me as a useful test, since it's pretty 
simple to produce, say, an HTMLParagraphElement instance on the web that 
has whatever .constructor value you desire, right?  Unless the intent is 
to talk about this in some setup where no one has messed with any of the 
objects or something.


I guess the intent here is that we want obj to have been constructed via 
X in some sense?  Modulo whatever the story is for the things that have 
NamedConstructors.



as distance from 'instances of X' which means objects for which obj instanceof 
X."


OK.

Anyway, modulo exactly what this definition should be, let's talk about 
the proposed "the constructor of an element determines its set of 
internal slots" invariant.  I'm OK with that if we include "constructor 
arguments".  Otherwise, I don't see how it can make sense.  In 
particular, say someone does:


  var x = new Element("a", "http://www.w3.org/1999/xhtml";)

or whatever argument order we do.  Per invariant 1 in your document, 
this should get the internal slots of an HTMLAnchorElement, right?  Per 
invariant 2, x.constructor == Element, and in particular x.__proto__ == 
Element.prototype.  So suddenly we have an HTMLAnchorElement as an 
own-instance of "Element", which I think violates your invariant 3.


Moving on to invariant 4, is that "instances" in terms on instanceof 
(which can be almost tautologically true, given what Web IDL says about 
[[HasInstance]] on interface objects), or in terms of what the proto 
chain looks like, or something else?  In particular, the "x" defined 
above doesn't have HTMLElement.prototype on its proto chain, but is 
instanceof HTMLElement...



I'd like to understand what you mean by "interface is Element" here, exactly.


I'm just quoting Anne :). My interpretation is that the (object representing 
the) element is an own-instance of Element.


This _really_ requires pinning down what exactly own-instance means. 
Let's get our terminology in order.  ;)


The one piece of terminology that I think we have so far that I 
understand is what it means for an object to "implement an interface". 
At least Web IDL has a normative requirement on such a thing being 
defined (e.g. see http://heycam.github.io/webidl/#es-operations step 4 
of the behavior), presumably in terms of some sort of branding.


So it makes sense to me to talk about things implementing Element but 
not any interface that has Element as an inherited interface.  That 
would correspond to "is an Element but not any specific subclass of 
Element".  Could use a shorter way of saying it, for sure.


-Boris

Re: element.onresize

[Spirit]

But what if we can get notification only for some of elements (not all) 
via setting some properties or methods. This not solve performance isue?


Something like this:
el.resized = true
el.resized(true|false)
etc.
and only el will generate resize event.

Or fire resize only for elements that changedviauser interactions, or 
elements that matched to the resize property:

http://dev.w3.org/csswg/css-ui-3/#resize

New HTML firing resize event for  element (when video has been 
fetched or whenever the intrinsic width or intrinsic height of the video 
changes) so adding that possibility only for some element should not be 
performance problem.

Re: Custom element design with ES6 classes and Element constructors

[Boris Zbarsky]

On 1/12/15 7:24 PM, Domenic Denicola wrote:

One crazy idea for solving B is to make every DOM element (or at least, every one 
generated via parsing a hyphenated or is="" element) into a proxy whose target 
can switch from e.g. `new HTMLUnknownElement()` to `new MyEl()` after upgrading. Like 
WindowProxy, basically. I haven't explored this in much detail because proxies are scary.


Hey, we have implementation experience for this in Gecko, since that's 
_exactly_ what we do when you adopt an element into a different global: 
we replace the guts of the old object with a proxy to the new thing.  ;)


Some thoughts:

1)  This does NOT affect C++ references in Gecko, not least because the 
C++ object identity doesn't change in this case.  Updating those would 
be a PITA.  But you want to change the C++ object identity for this 
particular use case, so you could get into weird situations where if 
something that's not JS is holding a ref to your element it can now be 
pointing to the wrong element.  Unless things get changed so all C++ 
holds references to elements via their JS reflections, which is probably 
a nonstarter.


2)  There is a performance penalty for having a proxy, obviously.  For 
adoption this is not too horrible, since in practice that's not that 
common, but presumably upgrades would actually be somewhat common.


3)  You need a way for the brand checks Web IDL methods do to deal with 
these proxies.  Gecko already has a way for that to work, on a slower 
path, since we have these membrane proxies, but other UAs would need to 
grow something like that.


-Boris

Adopting a Custom Element into Another Document

[Ryosuke Niwa]

Hi,

Have you settled the question of what happens to a custom element that's 
adopted into another document?

As far as I tested, WebKit and Blink keep the old __proto__ while Gecko changes 
it to the adopted document's prototype.  There is a bug in DOM component about 
this:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=20567

- R. Niwa

Re: Custom element design with ES6 classes and Element constructors

[Boris Zbarsky]

On 1/12/15 12:20 PM, Tab Atkins Jr. wrote:

Proto munging isn't even that big of a deal.


That really depends.

For example, dynamically changing __proto__ on something somewhat 
permanently deoptimizes that object in at least some JS engines. 
Whether that's a big deal depends on what you do with your objects.


-Boris

Re: Custom element design with ES6 classes and Element constructors

[Boris Zbarsky]

On 1/11/15 3:13 PM, Domenic Denicola wrote:

So, at least as a thought experiment: what if we got rid of all the local name checks 
in implementations and the spec. I think then `` could work, as long as 
it was done *after* `document.registerElement` calls.


Yes.


However, I don't understand how to make it work for upgraded elements at all, i.e., in the case 
where `` is parsed, and then later `document.registerElement("my-q", 
MyQ)` happens. You'd have to somehow graft the internal slots onto all MyQ instances after the 
fact


Yep.  It's no fun.


Is there any way around this you could imagine?


Not without making the set of internal slots mutable.

Note that in some implementations (e.g. a self-hosted implementation 
using WeakMaps for internal slots) this might not be so difficult.  But 
in general it does constrain implementation strategies quite significantly.



I know how seriously you were considering my suggestion to rewrite them all ;)


I've pretty seriously considered it on and off


The story is still pretty unsatisfactory, however. Consider the case where your document consists of 
``, and then later you do `class MyEl extends HTMLElement {}; 
document.registerElement("my-el", MyEl)`. (Note how I don't save the return value of 
document.registerElement.) When the parser encountered ``, it called `new 
HTMLUnknownElement(...)`, allocating a HTMLUnknownElement. The current design says to `__proto__`-munge the 
element after the fact, i.e. `document.body.firstChild.__proto__ = MyEl.prototype`. But it never calls the 
`MyEl` constructor!


Yeah, I'm not a fan of this part either.


- It means that the code `class MyEl extends HTMLElement {}` is largely a lie.


I think this part of the spec was largely written before ES6 class stuff 
stabilized, fwiw.  Which is not hard, since it's still not stabilized.  ;)



- It means that what you get when doing `new MyEl()` is different from what you got when 
parsing-then-upgrading ``.


This seems pretty undesirable.


(The same problems apply with , by the way. It needs to be upgraded 
from HTMLQuoteElement to QQ, but we can only `__proto__`-munge, not call the constructor.)


Hmm.  So given the current direction whereby ES6 constructors may not 
even be [[Call]]-able at all, I'm not sure we have any great options 
here.  :(  Basically, ES6 is moving toward coupling allocation and 
initialization but the upgrade scenario can't really be expressed by 
coupled alloc+init if it preserves object identity, right?



I was hopeful that ES6 would give us a way out of this, but after thinking things 
through, I don't see any improvement at all. In particular it seems you're always going 
to have to have `var C2 = document.registerElement("my-el", C1)` giving `C2 !== 
C1`.


This part is not immediately obvious to me.  Why does that have to be true?

-Boris

Re: Shadow tree style isolation primitive

[Hayato Ito]

"Intent to remove 

Re: Shadow tree style isolation primitive

[Marc Fawzi]

Can someone shed light at why Scoped Style Element was removed from Chrome
experimental features?

http://caniuse.com/#feat=style-scoped

In suggesting @isolate declaration, I meant it would go inside a scoped
style element. If there are nested scope style elements and each have
@isolate then it means that the styles don't bleed from parent with scoped
style to child with scoped style if child has @isolate

The big question is why was scoped style element removed from Chrome 37's
experimental flags?

Just curious.



On Mon, Jan 12, 2015 at 6:27 PM, Ryosuke Niwa  wrote:

>
> > On Jan 12, 2015, at 6:11 PM, Tab Atkins Jr. 
> wrote:
> >
> > On Mon, Jan 12, 2015 at 5:59 PM, Ryosuke Niwa  wrote:
> >>> On Jan 12, 2015, at 5:41 PM, Tab Atkins Jr. 
> wrote:
> >>> [ryosuke, your mail client keeps producing flattened replies. maybe
> >>> send as plain-text, not HTML?]
> >>
> >> Weird.  I'm not seeing that at all on my end.
> >
> > It's sending HTML-quoted stuff, which doesn't survive the flattening
> > to plain-text that I and a lot of others do.  Plain-text is more
> > interoperable.
> >
> >>> The style defined for  *in 's setup code* (that is, in a
> >>> 

Re: [Selection] Should selection.getRangeAt return a clone or a reference?

[Boris Zbarsky]

On 1/12/15 1:56 PM, Olivier Forget wrote:

Unfortunately
multiple range selections are not a "nice to have". All "real" editors
(MS Word, Google Docs, etc..) support selecting multiple ranges


Precisely.  This is why Gecko ended up supporting it: it was needed for 
the editor that was part of the Mozilla suite back in the day


Of course I've made this point before; it just got ignored.  :(

-Boris

Re: Shadow tree style isolation primitive

[Ryosuke Niwa]

> On Jan 12, 2015, at 6:11 PM, Tab Atkins Jr.  wrote:
> 
> On Mon, Jan 12, 2015 at 5:59 PM, Ryosuke Niwa  wrote:
>>> On Jan 12, 2015, at 5:41 PM, Tab Atkins Jr.  wrote:
>>> [ryosuke, your mail client keeps producing flattened replies. maybe
>>> send as plain-text, not HTML?]
>> 
>> Weird.  I'm not seeing that at all on my end.
> 
> It's sending HTML-quoted stuff, which doesn't survive the flattening
> to plain-text that I and a lot of others do.  Plain-text is more
> interoperable.
> 
>>> The style defined for  *in 's setup code* (that is, in a
>>> 

Re: Shadow tree style isolation primitive

[Tab Atkins Jr.]

On Mon, Jan 12, 2015 at 5:59 PM, Ryosuke Niwa  wrote:
>> On Jan 12, 2015, at 5:41 PM, Tab Atkins Jr.  wrote:
>> [ryosuke, your mail client keeps producing flattened replies. maybe
>> send as plain-text, not HTML?]
>
> Weird.  I'm not seeing that at all on my end.

It's sending HTML-quoted stuff, which doesn't survive the flattening
to plain-text that I and a lot of others do.  Plain-text is more
interoperable.

>> The style defined for  *in 's setup code* (that is, in a
>> 

Re: Shadow tree style isolation primitive

[Ryosuke Niwa]

> On Jan 12, 2015, at 5:41 PM, Tab Atkins Jr.  wrote:
> 
> [ryosuke, your mail client keeps producing flattened replies. maybe
> send as plain-text, not HTML?]

Weird.  I'm not seeing that at all on my end.

> The style defined for  *in 's setup code* (that is, in a
> 

Re: Shadow tree style isolation primitive

[Tab Atkins Jr.]

[ryosuke, your mail client keeps producing flattened replies. maybe
send as plain-text, not HTML?]

On Mon, Jan 12, 2015 at 5:23 PM, Ryosuke Niwa  wrote:
> On Jan 12, 2015, at 4:59 PM, Tab Atkins Jr.  wrote:
>> On Mon, Jan 12, 2015 at 4:18 PM, Ryosuke Niwa  wrote:
>>> On Jan 12, 2015, at 4:10 PM, Tab Atkins Jr.  wrote:
 ? I didn't mention DOM APIs.  I'm referring back to the example you're
 replying to - if you use a  element inside your  component,
 and you know that  has isolation styles, you have to specifically
 call that out inside your  styling so that it (a) is shielded
 from your foo styles, and (b) is able to pick up the global definition
 for bar styles.  This is relatively clumsy.  Some of the other
 solutions attach the "I want to be isolated" information to the
 element itself more directly, so you don't have to worry about what
 you put inside of yourself.
>>>
>>> This is no more clumsy than defining an insertion points in shadow DOM.  Or
>>> am I misunderstanding you?
>>
>> Yeah.  In Shadow DOM, you can just *use* the  element, without
>> having to think about it.
>
> I don't know what you mean by one doesn't have to think about it.  The style
> applied on  won't propagate into the shadow DOM by default [1] unless
> we use /deep/ or >>> [2]

The style defined for  *in 's setup code* (that is, in a

Re: Custom element design with ES6 classes and Element constructors

[Ryosuke Niwa]

> On Jan 12, 2015, at 5:14 PM, Domenic Denicola  wrote:
> 
> From: Ryosuke Niwa [mailto:rn...@apple.com] 
> 
>> There's no brilliant solution here.  I'm suggesting to introduce something 
>> akin to sync script element.
> 
>> In this particular example, my-el will remain HTMLUnknownElement since it 
>> had already appeared when the script element to load the module is parsed.  
>> A more interesting example would be the one where the script element to load 
>> my-module.js appears before my-el.  In that case, the instantiation of my-el 
>> is delayed until my-module.js is loaded.
> 
> I am still trying to tease out what "the instantiation of my-el is delayed" 
> means.

I mean that the parse would stop processing nodes at that point.  I expect that 
many people will be unhappy with this approach since it would have the same 
ramification as a "sync" script element (without "defer" or "async" attributes).

> What would happen in my example where the my-module.js appears before my-el? 
> I'm guessing from your response above, it would need to be 

Re: Shadow tree style isolation primitive

[Ryosuke Niwa]

> On Jan 12, 2015, at 4:59 PM, Tab Atkins Jr.  wrote:
> 
> [oof, somehow your latest response flattened all of the quotes]
> 
> On Mon, Jan 12, 2015 at 4:18 PM, Ryosuke Niwa  wrote:
>> On Jan 12, 2015, at 4:10 PM, Tab Atkins Jr.  wrote:
>>> ? I didn't mention DOM APIs.  I'm referring back to the example you're
>>> replying to - if you use a  element inside your  component,
>>> and you know that  has isolation styles, you have to specifically
>>> call that out inside your  styling so that it (a) is shielded
>>> from your foo styles, and (b) is able to pick up the global definition
>>> for bar styles.  This is relatively clumsy.  Some of the other
>>> solutions attach the "I want to be isolated" information to the
>>> element itself more directly, so you don't have to worry about what
>>> you put inside of yourself.
>> 
>> This is no more clumsy than defining an insertion points in shadow DOM.  Or
>> am I misunderstanding you?
> 
> Yeah.  In Shadow DOM, you can just *use* the  element, without
> having to think about it.

I don't know what you mean by one doesn't have to think about it.  The style 
applied on  won't propagate into the shadow DOM by default [1] unless we 
use /deep/ or >>> [2]

>>> I listed a number of APIs in the text you're responding to, all of
>>> which may or may not want to pay attention to style isolation,
>>> depending on the use-case.  I'm not saying you necessarily need DOM
>>> isolation for any given use-case.  I'm saying that there are a lot of
>>> APIs that query or walk the DOM, and whether they should pay attention
>>> to a "style isolation" boundary is a question without clear answers.
>> 
>> I don't understand what you mean here.  As far as I know, there are only two
>> sensible options here:
>> 
>> Style isolation implies DOM subtree isolation in all DOM APIs
>> Style isolation doesn't affect DOM APIs at all
>> 
>> Shadow DOM does 1.  I'm suggesting that we need a mechanism to do 2.  It's
>> not terrible if we introduced @isolate to do 1 and also provided shadow DOM
>> to do 1.  In that world, shadow DOM is a syntax sugar around @isolate in the
>> CSS land with DOM API implications.
> 
> I mean, those are two possible options.  They're not the only ones.
> For example, you could say that all selectors pay attention to the
> isolation boundary, so qSA is affected.  That's *a* consistent answer,
> and could be very reasonable - people often use qSA to do
> styling-related things, and having it respect the style boundaries
> makes sense there.
> 
> I'm saying there are multiple places you can draw the line.  I think
> there's a nice defensible spot at the point you end up with when you
> do DOM isolation - everything that cares about the DOM tree (which
> includes CSS selectors, defined in terms of the DOM tree) gets locked
> out by default.  Anywhere else has arguments for it, but I don't think
> any of them are particularly more compelling than any other.

What are other sensible alternatives?  I agree there are other options but they 
aren't sensible as far as I'm concerned.

[1] http://jsfiddle.net/seyL1vqn/ 
[2] http://jsfiddle.net/seyL1vqn/1/ 

- R. Niwa

Re: Shadow tree style isolation primitive

[Tab Atkins Jr.]

On Mon, Jan 12, 2015 at 4:45 PM, Ryosuke Niwa  wrote:
> I understand your use case but please also understand that some authors
> don't want to write a few dozen lines of JavaScript to create a shadow DOM,
> and hundreds of lines of code or load a framework to decoratively isolate
> CSS rules in their pages.

I agree that having a *simpler* way to define the shadow boundaries
could potentially make sense.  It wouldn't be a matter of splitting
apart more primitives, but instead of defining new sugar on top of the
existing stuff, to have a simple declarative mechanism for "make this
element push all of its contents into a shadow tree", potentially also
with some simple way to define styles for elements of that type.

I'm not saying the current status quo is 100% ideal, just that I think
the lines it draws are theoretically pretty useful.

Previously I said that it was a problem if the isolation selector
could pierce isolations - I think that's true of *general* selectors,
because, for example, classes are often reused for different meanings
in different parts of the page.  But if we restrict it to *element
names*, it's probably more okay; those are more identity-based, which
is part of why we're using them for components in the first place.
Imagine that the markup could look something like:

```

  
  /* Or whatever, just need some declarative mechanism for custom
element names. */


  ...

...

p { color: red; } /* only affects the p.two element, as p.one is
inside the x-foo's isolation */
x-foo::shadow p { color: blue; } /* does target the p.one element,
standard shadow-dom styling rules */
@in-shadow-of x-foo {
  p { color: green; }
  /* treated as a style *inside* the shadow dom, for short selectors
and normal specificity rules */
  /* thus, this targets p.one */
  /* interacts with the previous `x-foo::shadow p` rule in
already-defined shadow-dom way. */
  /* this style is also shared between the various x-foo elements that
may be on the page */
  /* to style a single specific one, append a