On 21/09/14 22:19, Boris Zbarsky wrote:
> On 9/21/14, 9:00 AM, James Graham wrote:
> More interestingly, either the specification is implementable or not.
> Again, because once the REC is published everyone goes home and never
> touches that document again.
>
> The two implementations condition was there to make sure you didn't end
> up with specs that basically reflected one UA's internals and that no
> one else could implement....
Yeah, I understand the reasoning. But I think it's an example of
replacing a difficult question with a simpler, but less accurate, one. I
think you'd get a better result by asking for agreement from all the
relevant implementors that they felt that the spec was implementable.
Obviously answering this question with any accuracy requires the
implementor to actually put some effort into understanding the design in
the context of their code, probably by implementing it. This would allow
you to be less conservative (you don't have to wait for every
low-priority bug to be fixed), without having to sabotage the testsuite
in order to keep up the pretense those bugs don't exist at all.
Of course in reality, if someone ships something that exposes their
internals and content comes to depend on it, everyone else is forced to
copy that behaviour anyway, with as much fidelity as they can. Specs are
only helpful here in the face of good actors. Even well-intentioned
actors without the right level of technical insight, and incentives to
ship quickly, can be harmful. As we both know, it's not unheard of for
people to follow enough process to get their stuff to Rec. with two
"interoperable" implementations, and gaping holes in the spec.
>> it doesn't seem at all
>> reasonable to demand that the specification is held to a higher standard.
>
> Note that I made no such demand, precisely because I think it's
> unrealistic.
Right, I didn't intend to accuse you personally of making unrealistic
demands. In general my reply to you wasn't intended to be taken as
disagreement, just as a useful jumping off point into the discussion.
>> My concrete suggestion is that we, as an organisation, work to achieve
>> parity between the tests we require to ship our own code and those we
>> release in ways that can be used to support a spec and, more
>> importantly, those that can be used verify that different
>> implementations match up.
>
> This is a good idea, but not terribly relevant to what dbaron should say
> in his AC rep capacity, right?
No, this was intended to be a broader point aimed at ensuring that, as
far as possible, the kind of problems we're experiencing with HTML don't
repeat in the future.
In terms of what dbaron should say, it seems like we should report the
publication, but note that we are unhappy with the overall process that
has led to this specification for all the reasons that have been
identified elsewhere on this thread.
>
>> Making this process as low-overhead as
>> possible is something that I'm working on.
>
> And it's much appreciated!
>
> Note that actually sanely testing something like navigation in
> non-browser-specific ways is ... hard. Basic things like "open a
> cross-origin window and wait for it to load" aren't really possible. :(
Using window.open("http://some.cross.origin.url";), you mean? Couldn't
you put a postMessage() in the load event of the opened document? It
requires your test to go async and depends on how precise your needs are
of course.
There is a hope that over time we can address more use cases that need
access to privileged APIs. There is a work in progress that will allow
using WebDriver from test cases, for example. It's not clear that this
will allow us to meet all needs, but it should make a difference in some
cases.
>> Obviously this isn't going to make a short-term difference for old
>> features like WindowProxy. I'm not sure what to suggest for those cases
>> given that we have de-facto shown an unwillingness to invest even
>> relatively small amounts of effort into reviewing existing tests that
>> could be part of the HTML testsuite for that feature [1].
>
> Missing reference?
https://critic.hoppipolla.co.uk/r/282
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
