Specifically on the subject of what URL spec to reference, I think it
should be Mozilla's position (which I'm willing to represent) that the
W3C HTML5 spec reference the dated URL spec[1] instead of the
copy/paste/modified(even if informatively) W3C WebApps URL spec.

[1] https://whatwg.org/specs/url/2014-07-30/

I'd like to make this proposal on public-html (since I'm still at
least somewhat participating in  W3C HTMLWG) by Wednesday unless there
are objections from Mozilla folks on this thread (which I expect 2
days sufficient to resolve).

Usually I'd just go ahead with this proposal, but given the diversity
of opinions on this thread, figured I'd see what folks here thought
first.

Regardless, I support providing that same feedback in our response to
the W3C HTML5 PR.

Thanks,

Tantek


On Mon, Sep 22, 2014 at 10:53 AM, Boris Zbarsky <bzbar...@mit.edu> wrote:
> On 9/22/14, 1:18 PM, James Graham wrote:
>>
>> 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.
>
>
> The problem was that in some cases this was more a less a non-goal (in some
> cases an anti-goal) for the spec editor.  Hence the process bit to somewhat
> force them to deal with the issue.  :(
>
>> 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.
>
>
> Yes, true.
>
>> Specs are only helpful here in the face of good actors.
>
>
> And in making it clear when people are being bad actors, yes.
>
>> 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.
>
>
> Indeed.
>
>>> 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?
>
>
> You can in some cases.  In other cases (like when you're testing the nulling
> out of window.opener by callers to disconnnect the callee from them, or
> testing opening of sandboxed things that shouldn't be allowed to run script)
> this is not an option.
>
>> It requires your test to go async
>
>
> You need that anyway for window.open, so that's not an issue.
>
>> and depends on how precise your needs are of course.
>
>
> Right.
>
>> 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.
>
>
> Yeah, I'm very much looking forward to this.
>
>> https://critic.hoppipolla.co.uk/r/282
>
>
> Thank you.  This is definitely something we should find time to review....
>
>
> -Boris
>
> _______________________________________________
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Reply via email to