Re: Fallout of non-encapsulated shadow trees

Domenic Denicola wrote:
> From: Brendan Eich [mailto:brendan@secure.meer.net]
>
>> >  I don't even know what 3 means. Is it well defined, or just some utopia?
>
> I think it is as well defined as 2 is. Both are really in terms of vague requirements:
>
> 2. Widget libraries should be implementable without leaking implementation details to non-determined consumers.

This is what <input type=file> relies on in Gecko, IINM, so there's an 
existence proof and practical (if single-implementation) definition.

You did not reply to my point that we have (2) and it's not 
"unexplained", nor does a spec for it "explain nothing". It may be 
overspecified by the one implementation in Gecko, but it's along the 
lines of what Maciej and Ted presented.

> 3. Widget libraries should be implementable without leaking implementation details to determined consumers.

Sounds like some evolution of Shadow DOM to use Google Caja => SES, etc. 
Where SES is not a utopia, but not widely used either; considered 
burdensome (fairly or not).

>> >  Let's work on 1 first, then get to 2, and declare victory.
>
> I think the crux of my argument is that this would be a mistake.

What "this"? You want to stand on (1) till (3) is figured out and made 
practical? You have to account for (2) sufficing in Firefox still, and 
justify making perfect enemy of good (always a mistake in my book).

>> >  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.
>
> I fully agree with this, however.

Pronoun trouble again. If by "this" you mean "multiple implementors 
tracking a draft standard spec", then we shouldn't have any vendor 
arguing "shipped it, set the standard, spec is frozen". Right?

/be

Received on Wednesday, 2 July 2014 02:00:18 UTC