Re: [whatwg/url] Provide a succinct grammar for valid URL strings (#479)

On reading @karwa's last comment...

> Meanwhile, this standard is essentially in its initial testing phase in a single browser. We'll need to see what issues Safari (and other WebKit-based browsers) users encounter, and that will be some sort of validation of this standard, and then wait for adoption by other browsers, see what issues their users encounter, etc. This standard is likely at least a couple of years away from meeting its goal of describing how browsers behave, IMO.

I think this fundamentally shows a misalignment of goals between most of the people asking for a succinct goal and folks who appear to be defending the current WhatWG approach.
The WhatWG approach appears to be to attempt to document the behaviour of one browser, write tests, then attempt to converge browsers to the resulting specification. Although the goal is to eventually have a standard that browsers are expected to follow, the quoted paragraph tells me that this document is not yet a standard even in the browser world. It is merely documentation.

In my opinion, the specification should have loftier goals, but I would like to turn the conversation in a different direction and make the argument *that the existing document is counterproductive to WhatWG's own goal of converging browser implementations*

The complaint at the root of this thread is that the specification is extremely difficult to implement. It is so complicated that, given a disagreement between an attempted implementation and the specification, serious consideration needs to be put into the possibility that the specification has a defect. (And I speak from personal experience, having found such a defect.)

Or to put it more plainly, in the 30% of test cases where Chrome disagrees with Safari, there is no way to tell who is right and who is wrong. Should Chrome change to match Safari or vice versa? A standard should provide an answer to that question. But the current document seems to me incapable of doing that, and I don't see a clear path to getting it to that state. Ideally, a standard for something like this should be able to explain clearly and concisely why each of its edge cases are the way they are. But from the sounds of it, in many cases, that reasoning is merely "because Safari does this" which is exactly the opposite of good design practice.

tl:dr I personally believe that the WhatWG likely stands to benefit, even just in its goal of browser convergence, from adopting Alwin's draft as the basis of the specification going forward. I don't think this needs to be a turf war over territory.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/url/issues/479#issuecomment-1135895415
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/url/issues/479/1135895415@github.com>