Domenic Denicola wrote:
From: Brendan Eich [mailto:[email protected]]
> 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
