On Mon, Mar 17, 2014 at 9:08 AM, Anne van Kesteren wrote:
> On Thu, Feb 13, 2014 at 2:34 PM, Boris Zbarsky wrote:
>> On 2/13/14 5:35 AM, Anne van Kesteren wrote:
>>>
>>> Also, Type 2 can be used for built-in elements
>>
>> Built-in elements need Type 4.
>
> Well, Chrome does not have Type 4, yet
On 3/17/14 12:08 PM, Anne van Kesteren wrote:
Well, Chrome does not have Type 4, yet is implementing parts of the
their elements using shadow DOM constructs.
What makes you say Chrome doesn't have Type 4?
They do in fact have it for the case in question, as far as I can tell
(inaccessible .sh
On Thu, Feb 13, 2014 at 2:34 PM, Boris Zbarsky wrote:
> On 2/13/14 5:35 AM, Anne van Kesteren wrote:
>>
>> Also, Type 2 can be used for built-in elements
>
> Built-in elements need Type 4.
Well, Chrome does not have Type 4, yet is implementing parts of the
their elements using shadow DOM construc
On Sat, Feb 15, 2014 at 1:57 AM, Maciej Stachowiak wrote:
>
> On Feb 14, 2014, at 9:00 AM, Erik Arvidsson wrote:
>
>
>
>
> On Thu, Feb 13, 2014 at 9:00 PM, Maciej Stachowiak wrote:
>
>>
>> On Feb 13, 2014, at 4:01 PM, Alex Russell
>> wrote:
>>
>> A closure is an iron-clad isolation mechanism
On Feb 14, 2014, at 7:16 PM, Boris Zbarsky wrote:
> On 2/14/14 10:07 PM, Ryosuke Niwa wrote:
>> We most vigorously object to making the CSS style resolver depend on JS
>> DOM object properties.
>
> Ryosuke, I think you misunderstood the proposal. I'm pretty sure we all
> object to having the
* Alex Russell wrote:
>So you've written off the massive coordination costs of adding a uniform to
>all code across all of Google and, on that basis, have suggested there
>isn't really a problem? ISTM that it would be a multi-month (year?) project
>to go patch every project in google3 and then wait
On Feb 14, 2014, at 9:00 AM, Erik Arvidsson wrote:
>
>
>
> On Thu, Feb 13, 2014 at 9:00 PM, Maciej Stachowiak wrote:
>
> On Feb 13, 2014, at 4:01 PM, Alex Russell wrote:
>> A closure is an iron-clad isolation mechanism for object ownership with
>> regards to the closing-over function obje
On Feb 14, 2014, at 7:07 PM, Ryosuke Niwa wrote:
> On Feb 14, 2014, at 6:12 PM, Daniel Freedman wrote:
>>> Since you have preciously claimed that instantiating a template element may
>>> not be a common pattern for custom elements / web components, I have a hard
>>> time accepting the claim tha
On Feb 14, 2014, at 7:16 PM, Boris Zbarsky wrote:
> On 2/14/14 10:07 PM, Ryosuke Niwa wrote:
>> We most vigorously object to making the CSS style resolver depend on JS
>> DOM object properties.
>
> Ryosuke, I think you misunderstood the proposal. I'm pretty sure we all
> object to having the CS
On 2/14/14 10:07 PM, Ryosuke Niwa wrote:
We most vigorously object to making the CSS style resolver depend on JS
DOM object properties.
Ryosuke, I think you misunderstood the proposal. I'm pretty sure we all
object to having the CSS style resolver depend on anything that involves
JS properti
On Feb 14, 2014, at 6:12 PM, Daniel Freedman wrote:
> On Fri, Feb 14, 2014 at 5:39 PM, Ryosuke Niwa wrote:
> On Feb 14, 2014, at 5:17 PM, Alex Russell wrote:
>
>> On Fri, Feb 14, 2014 at 3:56 PM, Ryosuke Niwa wrote:
>> On Feb 14, 2014, at 2:50 PM, Elliott Sprehn wrote:
>>> On Fri, Feb 14, 201
On 14 Feb 2014 17:39, "Ryosuke Niwa" wrote:
>
> On Feb 14, 2014, at 5:17 PM, Alex Russell wrote:
>
>> On Fri, Feb 14, 2014 at 3:56 PM, Ryosuke Niwa wrote:
>>>
>>> On Feb 14, 2014, at 2:50 PM, Elliott Sprehn
wrote:
On Fri, Feb 14, 2014 at 2:39 PM, Boris Zbarsky wrote:
>
> On 2
On Fri, Feb 14, 2014 at 6:12 PM, Daniel Freedman wrote:
> The other hand of this argument is that components that wish to lock
> themselves down could write:
>
> this.shadowRoot = undefined;
>
> Of course, this does would not change the outcome of the Shadow Selector
> spec, which is why a flag fo
On Fri, Feb 14, 2014 at 5:39 PM, Ryosuke Niwa wrote:
> On Feb 14, 2014, at 5:17 PM, Alex Russell wrote:
>
> On Fri, Feb 14, 2014 at 3:56 PM, Ryosuke Niwa wrote:
>
>> On Feb 14, 2014, at 2:50 PM, Elliott Sprehn wrote:
>>
>> On Fri, Feb 14, 2014 at 2:39 PM, Boris Zbarsky wrote:
>>
>>> On 2/14/1
On Fri, Feb 14, 2014 at 5:17 PM, Alex Russell wrote:
> On Fri, Feb 14, 2014 at 3:56 PM, Ryosuke Niwa wrote:
>
>> [...]
> We all agree it's not a security boundary and you can go through great
>> lengths to get into the ShadowRoot if you really wanted, all we've done by
>> not exposing it is mak
On Feb 14, 2014, at 5:17 PM, Alex Russell wrote:
> On Fri, Feb 14, 2014 at 3:56 PM, Ryosuke Niwa wrote:
> On Feb 14, 2014, at 2:50 PM, Elliott Sprehn wrote:
>> On Fri, Feb 14, 2014 at 2:39 PM, Boris Zbarsky wrote:
>> On 2/14/14 5:31 PM, Jonas Sicking wrote:
>> Also, I think that the Type 2 enc
On Fri, Feb 14, 2014 at 3:56 PM, Ryosuke Niwa wrote:
> On Feb 14, 2014, at 2:50 PM, Elliott Sprehn wrote:
>
> On Fri, Feb 14, 2014 at 2:39 PM, Boris Zbarsky wrote:
>
>> On 2/14/14 5:31 PM, Jonas Sicking wrote:
>>
>>> Also, I think that the Type 2 encapsulation has the same
>>> characteristics.
On Feb 14, 2014, at 2:50 PM, Elliott Sprehn wrote:
> On Fri, Feb 14, 2014 at 2:39 PM, Boris Zbarsky wrote:
> On 2/14/14 5:31 PM, Jonas Sicking wrote:
> Also, I think that the Type 2 encapsulation has the same
> characteristics. If the component author does things perfectly and
> doesn't depend on
On Fri, Feb 14, 2014 at 2:39 PM, Boris Zbarsky wrote:
> On 2/14/14 5:31 PM, Jonas Sicking wrote:
>
>> Also, I think that the Type 2 encapsulation has the same
>> characteristics. If the component author does things perfectly and
>> doesn't depend on any outside code
>>
>
> And never invokes any D
On 2/14/14 5:31 PM, Jonas Sicking wrote:
Also, I think that the Type 2 encapsulation has the same
characteristics. If the component author does things perfectly and
doesn't depend on any outside code
And never invokes any DOM methods on the nodes in the component's
anonymous content. Which is
On Fri, Feb 14, 2014 at 2:02 PM, Ryosuke Niwa wrote:
> On Feb 14, 2014, at 9:00 AM, Erik Arvidsson wrote:
>
> On Thu, Feb 13, 2014 at 9:00 PM, Maciej Stachowiak wrote:
>>
>> On Feb 13, 2014, at 4:01 PM, Alex Russell wrote:
>>
>> A closure is an iron-clad isolation mechanism for object ownership
On Feb 14, 2014, at 9:00 AM, Erik Arvidsson wrote:
> On Thu, Feb 13, 2014 at 9:00 PM, Maciej Stachowiak wrote:
> On Feb 13, 2014, at 4:01 PM, Alex Russell wrote:
>> A closure is an iron-clad isolation mechanism for object ownership with
>> regards to the closing-over function object. There's ab
On Thu, Feb 13, 2014 at 9:00 PM, Maciej Stachowiak wrote:
>
> On Feb 13, 2014, at 4:01 PM, Alex Russell wrote:
>
> A closure is an iron-clad isolation mechanism for object ownership with
> regards to the closing-over function object. There's absolutely no
> iteration of the closed-over state of
On Feb 13, 2014, at 4:01 PM, Alex Russell wrote:
> On Thu, Feb 13, 2014 at 1:25 PM, Maciej Stachowiak wrote:
> On Feb 12, 2014, at 4:04 PM, Alex Russell wrote:
> It is meant to be an encapsulation mechanism. Let me give a comparison. Many
> JavaScript programmers choose to use closures as a wa
On Feb 13, 2014, at 4:01 PM, Alex Russell wrote:
> On Thu, Feb 13, 2014 at 1:25 PM, Maciej Stachowiak wrote:
>
> On Feb 12, 2014, at 4:04 PM, Alex Russell wrote:
>
>>
>>
>> In discussion with Elliot and Erik, there appears to be an additional
>> complication: any of the DOM manipulation m
On Thu, Feb 13, 2014 at 4:07 PM, Charles McCathie Nevile
wrote:
> On Thu, 13 Feb 2014 19:09:33 +0100, Tab Atkins Jr.
> wrote:
>> On Thu, Feb 13, 2014 at 2:35 AM, Anne van Kesteren
>>> On Thu, Feb 13, 2014 at 12:04 AM, Alex Russell
Until we can agree on this, Type 2 feels like an attractive
Tab,
On Thu, 13 Feb 2014 19:09:33 +0100, Tab Atkins Jr.
wrote:
On Thu, Feb 13, 2014 at 2:35 AM, Anne van Kesteren
On Thu, Feb 13, 2014 at 12:04 AM, Alex Russell
Until we can agree on this, Type 2 feels like an attractive nuisance
and, onreflection, one that I think we should punt to co
On Thu, Feb 13, 2014 at 1:25 PM, Maciej Stachowiak wrote:
>
> On Feb 12, 2014, at 4:04 PM, Alex Russell wrote:
>
>
>
> In discussion with Elliot and Erik, there appears to be an additional
> complication: any of the DOM manipulation methods that aren't locked down
> (marked non-configurable and
* Maciej Stachowiak wrote:
>Type 2 is not meant to be a security mechanism. It is meant to be an
>encapsulation mechanism. Let me give a comparison. Many JavaScript
>programmers choose to use closures as a way to store private data for
>objects. That is an encapsulation mechanism. It is not, in
On Feb 12, 2014, at 4:04 PM, Alex Russell wrote:
>
>
> In discussion with Elliot and Erik, there appears to be an additional
> complication: any of the DOM manipulation methods that aren't locked down
> (marked non-configurable and filtered, ala caja) create avenues to get
> elements from t
* Anne van Kesteren wrote:
>On Thu, Feb 13, 2014 at 12:04 AM, Alex Russell wrote:
>> Until we can agree on this, Type 2 feels like an attractive nuisance and, on
>> reflection, one that I think we should punt to compilers like caja in the
>> interim. If toolkits need it, I'd like to understand tho
On Thu, Feb 13, 2014 at 2:35 AM, Anne van Kesteren wrote:
> On Thu, Feb 13, 2014 at 12:04 AM, Alex Russell
> wrote:
> > Until we can agree on this, Type 2 feels like an attractive nuisance
> and, on
> > reflection, one that I think we should punt to compilers like caja in the
> > interim. If too
On Thu, Feb 13, 2014 at 2:35 AM, Anne van Kesteren wrote:
> On Thu, Feb 13, 2014 at 12:04 AM, Alex Russell wrote:
>> Until we can agree on this, Type 2 feels like an attractive nuisance and, on
>> reflection, one that I think we should punt to compilers like caja in the
>> interim. If toolkits ne
On 2/13/14 5:35 AM, Anne van Kesteren wrote:
Also, Type 2 can be used for built-in elements
Built-in elements need Type 4.
-Boris
On Thu, Feb 13, 2014 at 12:04 AM, Alex Russell wrote:
> Until we can agree on this, Type 2 feels like an attractive nuisance and, on
> reflection, one that I think we should punt to compilers like caja in the
> interim. If toolkits need it, I'd like to understand those use-cases from
> experience.
On Tue, Feb 11, 2014 at 5:16 PM, Maciej Stachowiak wrote:
>
> On Feb 11, 2014, at 4:04 PM, Dimitri Glazkov
> wrote:
>
> On Tue, Feb 11, 2014 at 3:50 PM, Maciej Stachowiak wrote:
>
>>
>> On Feb 11, 2014, at 3:29 PM, Dimitri Glazkov
>> wrote:
>>
>>
>>
>>> Dimitri, Maciej, Ryosuke - is there a mu
On Feb 11, 2014, at 4:04 PM, Dimitri Glazkov wrote:
> On Tue, Feb 11, 2014 at 3:50 PM, Maciej Stachowiak wrote:
>
> On Feb 11, 2014, at 3:29 PM, Dimitri Glazkov wrote:
>
>>
>> Dimitri, Maciej, Ryosuke - is there a mutually agreeable solution here?
>>
>> I am exactly sure what problem this
On Feb 11, 2014, at 3:36 PM, Dimitri Glazkov wrote:
> Durrr. Forgot a NOT.
>
> On Tue, Feb 11, 2014 at 3:29 PM, Dimitri Glazkov
> wrote:
>
> I am NOT exactly sure what problem this thread hopes to raise and whether
> there is a need for anything other than what is already planned.
I was not
On Tue, Feb 11, 2014 at 3:50 PM, Maciej Stachowiak wrote:
>
> On Feb 11, 2014, at 3:29 PM, Dimitri Glazkov
> wrote:
>
>
>
>> Dimitri, Maciej, Ryosuke - is there a mutually agreeable solution here?
>>
>
> I am exactly sure what problem this thread hopes to raise and whether
> there is a need for
On Feb 11, 2014, at 3:29 PM, Dimitri Glazkov wrote:
>
> Dimitri, Maciej, Ryosuke - is there a mutually agreeable solution here?
>
> I am exactly sure what problem this thread hopes to raise and whether there
> is a need for anything other than what is already planned.
In the email Ryosuke c
Durrr. Forgot a NOT.
On Tue, Feb 11, 2014 at 3:29 PM, Dimitri Glazkov wrote:
I am NOT exactly sure what problem this thread hopes to raise and whether
> there is a need for anything other than what is already planned.
>
On Mon, Feb 10, 2014 at 11:08 AM, Arthur Barstow wrote:
> On 2/6/14 9:06 PM, ext Ryosuke Niwa wrote:
>
>> Could chairs of the working group please clarify whether we have had a
>> reach of consensus on the default encapsulation level in shadow DOM?
>>
>
> As described in [WorkMode], WebApps' async
Thanks for the clarifications, Arthur!
On Feb 10, 2014, at 11:08 AM, Arthur Barstow wrote:
> On 2/6/14 9:06 PM, ext Ryosuke Niwa wrote:
>> Could chairs of the working group please clarify whether we have had a reach
>> of consensus on the default encapsulation level in shadow DOM?
>
> As descr
On 2/6/14 9:06 PM, ext Ryosuke Niwa wrote:
Could chairs of the working group please clarify whether we have had a reach of
consensus on the default encapsulation level in shadow DOM?
As described in [WorkMode], WebApps' asynchronous participation and edit
first "work modes" means group member
Hi,
Could chairs of the working group please clarify whether we have had a reach of
consensus on the default encapsulation level in shadow DOM?
More concretely, have we _decided_ that we only want Type 1 encapsulation for
the level 1 specifications of Web components instead of Type 2 or Type 1
45 matches
Mail list logo
