On Jan 13, 2015, at 11:43 AM, Domenic Denicola d...@domenic.me wrote:
I imagine this has all been discussed before, but why do __proto__-munging
when adopting cross document? That seems bizarre, and causes exactly these
problems. When you put an object in a Map from another realm, it
* Domenic Denicola wrote:
From: Bjoern Hoehrmann [mailto:derhoe...@gmx.net]
I know that this a major concern to you, but my impression is that few
if any other people regard that as anything more than nice to have,
especially if you equate explaining with having a public API for it.
How do
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27829
Bug ID: 27829
Summary: [Shadow]: Update ShadowRoot to have elementsFromPoint
and caretPositionFromPoint
Product: WebAppsWG
Version: unspecified
Hardware: PC
From: Bjoern Hoehrmann [mailto:derhoe...@gmx.net]
I know that this a major concern to you, but my impression is that few if any
other people regard that as anything more than nice to have, especially if
you equate explaining with having a public API for it.
How do you propose having a
* Domenic Denicola wrote:
That kind of breaks the design goal that we be able to explain how
everything you see in the DOM was constructed. How did the parser (or
document.createElement(NS)) create a HTMLUnknownElement, if the
constructor for HTMLUnknownElement doesn't work?
I know that this a
Hi,
For shadow DOMs which has multiple focusable fields under the host,
the current behavior of tab navigation order gets somewhat weird
when you want to specify tabindex explicitly.
This is the doc to introduce a new attribute delegatesFocus to resolve
the issue.
On Jan 13, 2015, at 10:22 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 1/13/15 1:18 PM, Ryosuke Niwa wrote:
I agree. It's unusual for a constructor of a super class to automatically
instantiate an arbitrary subclass based on its arguments. And we usually
solve that convenience problem by
From: Boris Zbarsky [mailto:bzbar...@mit.edu]
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
On 1/13/15 12:06 PM, Gabor Krizsanits wrote:
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. ;)
Isn't there a chance to consider our use-case in ES6 spec. then?
I suspect not in time for ES6.
From: Gabor Krizsanits [mailto:gkrizsan...@mozilla.com]
Isn't there a chance to consider our use-case in ES6 spec. then?
I kind of feel like I and others dropped the ball on this one. Until this
thread I didn't realize how important the dual-stage allocation +
initialization was, for
I could use more information here.
http://www.w3.org/TR/DOM-Level-3-Events/#interface-MouseEvent specifies
MouseEvent attributes with the attribute keyword. WebIDL description of
attribute seems to apply here http://www.w3.org/TR/WebIDL/#idl-attributes.
Why shouldn't the attribute keyword be used?
On 1/13/15 12:05 PM, Domenic Denicola wrote:
From: Boris Zbarsky [mailto:bzbar...@mit.edu]
var x = new Element(a, http://www.w3.org/1999/xhtml;)
The idea is that your above example throws, preserving the invariant.
That sounds annoying
Presumably this means that
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/13/2015 06:26 PM, Vincent Scheib wrote:
I could use more information here.
http://www.w3.org/TR/DOM-Level-3-Events/#interface-MouseEvent
specifies MouseEvent attributes with the attribute keyword. WebIDL
description of attribute seems to
From: Boris Zbarsky [mailto:bzbar...@mit.edu]
Just to be clear, this still didn't allow you to upgrade a my-img to be a
subclass of img, because that required a change in allocation, right?
Agreed. That needs to be done with img is=my-img, IMO. (Assuming the
upgrading design doesn't get
On Jan 13, 2015, at 4:21 AM, Arthur Barstow art.bars...@gmail.com wrote:
On 1/13/15 6:54 AM, cha...@yandex-team.ru wrote:
13.01.2015, 05:31, Boris Zbarsky bzbar...@mit.edu:
On 1/12/15 1:56 PM, Olivier Forget wrote:
Unfortunately
multiple range selections are not a nice to have. All
On 1/13/15 1:18 PM, Ryosuke Niwa wrote:
I agree. It's unusual for a constructor of a super class to automatically
instantiate an arbitrary subclass based on its arguments. And we usually solve
that convenience problem by introducing a factory class/function.
While true, I do think there's a
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27709
sch...@chromium.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On 1/13/15 12:50 PM, Domenic Denicola wrote:
Agreed. That needs to be done with img is=my-img, IMO. (Assuming the
upgrading design doesn't get switched to DOM mutation, of course.)
Although! Briefly yesterday Arv mentioned that for Blink's DOM implementation there's no real
difference in
From: Boris Zbarsky [mailto:bzbar...@mit.edu]
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
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. ;)
Isn't there a chance to consider our use-case in ES6 spec. then?
Basically, ES6 is moving toward coupling allocation and
initialization but the
On 1/13/15 12:10 PM, Domenic Denicola wrote:
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
From: Boris Zbarsky [mailto:bzbar...@mit.edu]
But it also means that user-space code that has to create an HTML element
generically now has to go through document.createElement instead of being
able to do |new HTMLElement(a)|, right?
That seems totally fine to me though. The idea of a
On Jan 13, 2015, at 9:25 AM, Domenic Denicola d...@domenic.me wrote:
From: Boris Zbarsky [mailto:bzbar...@mit.edu]
But it also means that user-space code that has to create an HTML element
generically now has to go through document.createElement instead of being
able to do |new
On Jan 13, 2015, at 8:26 PM, Domenic Denicola d...@domenic.me wrote:
From: Bjoern Hoehrmann [mailto:derhoe...@gmx.net]
I know that this a major concern to you, but my impression is that few if
any other people regard that as anything more than nice to have,
especially if you equate
From: Ryosuke Niwa [mailto:rn...@apple.com]
Shouldn't we throw in this case because the concert type of somename is
HTMLUnknownElement?
Yes, that's exactly the current design. Hidden a bit:
https://github.com/domenic/element-constructors/blob/master/element-constructors.js#L4
This still
On Tue, Jan 13, 2015 at 8:15 PM, Ryosuke Niwa rn...@apple.com wrote:
By the same thing, do you mean that they will manually change __proto__
themselves?
Yes.
Let's say we have MyElement that inherits from HTMLElement and we're
adopting an instance of this element (let's call it myElement)
On Jan 13, 2015, at 11:31 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 1/13/15 1:33 PM, Ryosuke Niwa wrote:
Shouldn't we throw in this case because the concert type of somename is
HTMLUnknownElement?
Oh, hmm.
Yes, I guess so. That's very non-obvious to an author.
Even less obvious
On Jan 13, 2015, at 7:05 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Tue, Jan 13, 2015 at 6:15 AM, Ryosuke Niwa rn...@apple.com wrote:
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
On 1/13/15 1:33 PM, Ryosuke Niwa wrote:
Shouldn't we throw in this case because the concert type of somename is
HTMLUnknownElement?
Oh, hmm.
Yes, I guess so. That's very non-obvious to an author.
Even less obvious because for some tag names using the HTMLElement
constructor is in fact
On Jan 13, 2015, at 10:45 AM, Domenic Denicola d...@domenic.me wrote:
From: Ryosuke Niwa [mailto:rn...@apple.com]
Shouldn't we throw in this case because the concert type of somename is
HTMLUnknownElement?
Yes, that's exactly the current design. Hidden a bit:
On Jan 13, 2015, at 4:15 AM, cha...@yandex-team.ru wrote:
13.01.2015, 00:57, Ryosuke Niwa rn...@apple.com:
On Jan 12, 2015, at 4:13 AM, cha...@yandex-team.ru wrote:
09.01.2015, 16:42, Anne van Kesteren ann...@annevk.nl:
I'm wondering if it's feasible to provide developers with the
On Jan 13, 2015, at 11:27 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Tue, Jan 13, 2015 at 8:15 PM, Ryosuke Niwa rn...@apple.com wrote:
By the same thing, do you mean that they will manually change __proto__
themselves?
Yes.
Let's say we have MyElement that inherits from
I imagine this has all been discussed before, but why do __proto__-munging when
adopting cross document? That seems bizarre, and causes exactly these problems.
When you put an object in a Map from another realm, it doesn't __proto__-munge
it to that other realm's Object.prototype. Why is the
On 1/13/15 2:43 PM, Domenic Denicola wrote:
Why is the tree data structure embodied by the DOM any different?
The issue is not the tree structure but rather 1) what it means to have
a certain document as your ownerDocument and 2) Whether there are
footguns here that make it too easy for
On Jan 13, 2015, at 3:46 PM, Brian Kardell bkard...@gmail.com wrote:
On Tue, Jan 13, 2015 at 2:07 PM, Ryosuke Niwa rn...@apple.com
mailto:rn...@apple.com wrote:
To separate presentational information (CSS) from the semantics (HTML).
Defining both style isolation boundaries and the
On Tue, Jan 13, 2015 at 8:09 PM, Ryosuke Niwa rn...@apple.com wrote:
On Jan 13, 2015, at 3:46 PM, Brian Kardell bkard...@gmail.com wrote:
On Tue, Jan 13, 2015 at 2:07 PM, Ryosuke Niwa rn...@apple.com wrote:
To separate presentational information (CSS) from the semantics (HTML).
Defining
On 1/13/15 6:54 AM, cha...@yandex-team.ru wrote:
13.01.2015, 05:31, Boris Zbarsky bzbar...@mit.edu:
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
As in the thread Ben split, I think it's just Aryeh omitted in the current
spec focus. Visual Studio supported multiple selections in version 11 or
so. MS Word, I don't remember, but probably version 9 or 10. I agree that
it's a great feature, but also agree with Aryeh and Ben that we have a lot
13.01.2015, 05:31, Boris Zbarsky bzbar...@mit.edu:
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
13.01.2015, 00:57, Ryosuke Niwa rn...@apple.com:
On Jan 12, 2015, at 4:13 AM, cha...@yandex-team.ru wrote:
09.01.2015, 16:42, Anne van Kesteren ann...@annevk.nl:
I'm wondering if it's feasible to provide developers with the
primitive that the combination of Shadow DOM and CSS Scoping
On Tue, Jan 13, 2015 at 6:15 AM, Ryosuke Niwa rn...@apple.com wrote:
Have you settled the question of what happens to a custom element that's
adopted into another document?
More or less...
As far as I tested, WebKit and Blink keep the old __proto__ while Gecko
changes it to the adopted
From: Ryosuke Niwa [mailto:rn...@apple.com]
Or, we could always throw an exception in the constructor of
HTMLUnknownElement so that nobody could do it. It would mean that libraries
and frameworks that do support custom elements without - would have to use
document.createElement but that
On Jan 13, 2015, at 10:53 AM, Domenic Denicola d...@domenic.me wrote:
From: Ryosuke Niwa [mailto:rn...@apple.com]
Or, we could always throw an exception in the constructor of
HTMLUnknownElement so that nobody could do it. It would mean that libraries
and frameworks that do support
On Jan 13, 2015, at 10:06 AM, Ryosuke Niwa rn...@apple.com wrote:
On Jan 13, 2015, at 4:21 AM, Arthur Barstow art.bars...@gmail.com wrote:
On 1/13/15 6:54 AM, cha...@yandex-team.ru wrote:
13.01.2015, 05:31, Boris Zbarsky bzbar...@mit.edu:
On 1/12/15 1:56 PM, Olivier Forget wrote:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27823
Bug ID: 27823
Summary: We should consider dropping [NoInterfaceObject] from
XMLHttpRequestEventTarget
Product: WebAppsWG
Version: unspecified
Hardware: PC
On Tue, Jan 13, 2015 at 9:50 AM, Domenic Denicola d...@domenic.me wrote:
From: Boris Zbarsky [mailto:bzbar...@mit.edu]
Just to be clear, this still didn't allow you to upgrade a my-img to
be a subclass of img, because that required a change in allocation, right?
Agreed. That needs to be
On 01/12/2015 07:59 PM, Ben Peters wrote:
Multiple selection is an important feature in the future.
Indeed, there are many important use cases for it.
Here are some use cases that are implemented using multi-range selections
in Gecko today:
* visual selection of bidirectional text
*
On Tue, Jan 13, 2015 at 2:05 PM, Mats Palmgren m...@mozilla.com wrote:
On 01/12/2015 07:59 PM, Ben Peters wrote:
Multiple selection is an important feature in the future.
Indeed, there are many important use cases for it.
Here are some use cases that are implemented using multi-range
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27712
Joshua Bell jsb...@google.com changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
On Tue, Jan 13, 2015 at 2:07 PM, Ryosuke Niwa rn...@apple.com wrote:
To separate presentational information (CSS) from the semantics (HTML).
Defining both style isolation boundaries and the associated CSS rules in an
external CSS file will allow authors to change both of them without having
to
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25223
Joshua Bell jsb...@google.com changed:
What|Removed |Added
Status|RESOLVED|REOPENED
51 matches
Mail list logo
