Re: Fallout of non-encapsulated shadow trees

Domenic Denicola wrote:
> From: Brendan Eich [mailto:brendan@secure.meer.net]
>> >  That is a false idol if it means no intermediate steps that explain some but not all of the platform.
>
> Sure. But I don't think the proposed type 2 encapsulation explains any of the platform at all.

Are you sure? Because Gecko has used XBL (1) to implement, e.g., <input 
type=file>, or so my aging memory says. That's "good enough" and it has 
shipped for years, unless I'm mistaken.

>> >  Sorry, I'm confused. What do we have now, already, among top browsers that is "good"? Or do you mean prospective stuff? Because among interoperating browsers, AFAIK we do not have any XBL2 or Shadow DOM or other such, after all these years.
>
> I am not sure of your definition of prospective and top browsers, but according tohttps://jonrimmer.github.io/are-we-componentized-yet/  and linked issues, Chrome/Opera is shipping and Firefox is shipping behind a flag. And by shipping, I mean shipping the current shadow DOM spec, which I consider "good."
>
> (Although,https://bugzilla.mozilla.org/showdependencytree.cgi?id=811542&hide_resolved=1  shows that Firefox has lots of outstanding bugs, so I can't really say how close they are to unflagging.)

I meant "all" by "top browsers". Otherwise "we" (developers) don't 
really "have now" any cross-browser web component to stand on and resist 
2nd or 3rd variations.

>> >  Could you enumerate the three versions (in any sense) of web components in the worst case you cite above?
>
> Sure. They would be:
>
> 1. What is being shipped now/the current shadow DOM spec

You're getting ahead of your own terms of debate here. Any "we" who 
"have" WC in this list, or another standards body list, must be 
developers dealing with all top browsers, at least.

> 2. A version of it that gives soft encapsulation
> 3. A version of it that gives true encapsulation, suitable for implementing built-ins

See above about <input type=file>. Boris should weigh in.

I don't even know what 3 means. Is it well defined, or just some utopia? 
I didn't see anyone seriously propose it.

> The relative badness of having 1+2+3 vs. just 1+3 is largely a function of what "version" ends up meaning. If it is a small additional flag, no big deal. If it is three separate conceptual models and APIs, bad news.

You do seem to be making some perfect over good choices, but perfect is 
no-place -- it doesn't exist.

Let's work on 1 first, then get to 2, and declare victory. If Maciej is 
loath to implement 1 before 2, because widget APIs will leak 
implementation details, perhaps we shouldn't standardize in a hurry. I 
still see value in multiple implementors tracking a draft standard spec.

/be

Received on Wednesday, 2 July 2014 01:14:13 UTC