On Sep 9, 2013 9:32 PM, "Tab Atkins Jr." wrote:
>
> On Mon, Sep 9, 2013 at 6:20 PM, Scott Miles wrote:
> >>> I'd greatly prefer to stick with the current plan of having to mark
> >>> things to be exposed explicitly,
> >
> > Fwiw, we tried that and got in the weeds right away. See Dimitri's post
f
On Mon, Sep 9, 2013 at 6:20 PM, Scott Miles wrote:
>>> I'd greatly prefer to stick with the current plan of having to mark
>>> things to be exposed explicitly,
>
> Fwiw, we tried that and got in the weeds right away. See Dimitri's post for
> details. I'm afraid of trading real-life pain (e.g. expl
>> since you have no clue what parts of your existing markup structure are
being depended on by others.
But we already have no clue. In all cases we are talking about guidelines.
You cannot outright prevent people from poking around in the guts of your
component.
In either case you can be assured
On Mon, Sep 9, 2013 at 4:32 PM, Dimitri Glazkov wrote:
> For what it's worth, it would be fairly easy to make shadow tree rules
> match shadow host only when ":host" is present in a rule.
>
> Unfortunately, this would leave Tab (and other CSS WG folks) in a sad
> state, since addressing these argu
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23160
Arun changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23147
Arun changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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
This progress update is brought to you in part by the Sith Order:
"Sith: When The Light Side Just Ain't Cuttin' It."
Part 1: Revenge of the :host
Turns out, it's bad to be Super Man. After the Shadow DOM meetup,
where we decided that shadow host could be matched by both outer and
inner trees
(h
Redirecting this thread to the "overlap..." thread because it is the same.
For Cyril --> I think the mistake is that XHR does provide incremental
data on 'loading' instead of delta data.
I have read again:
http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0727.html.
And still do