- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Sat, 1 Nov 2014 12:56:26 +0100
- To: Sam Ruby <rubys@intertwingly.net>
- Cc: WHATWG <whatwg@whatwg.org>
On Sat, Nov 1, 2014 at 12:38 PM, Sam Ruby <rubys@intertwingly.net> wrote:
> On 11/1/14 5:29 AM, Anne van Kesteren wrote:
>> It doesn't say that. (We should perhaps try to find some way to make
>> "{scheme}://" syntax work for schemes that are not problematic (e.g.
>> javascript would be problematic). Convincing implementers that it's
>> worth implementing might be trickier.)
>
> How should it change?
Not sure what you're referring to.
> Acknowledging that other parsers exist is quite a different statement than
> requiring two parsers. I'm only suggesting the former.
We haven't done that for other formats. And it doesn't help with convergence.
> That may not be as we would wish it to be. But it would be a disservice to
> everyone to document how we would wish things to be rather than how they
> actually are (and, by all indications, are likely to remain for the
> foreseeable future).
This contradicts with most WHATWG work. WHATWG standards describe how
things should be, taking into account the realities of deployed
content.
That is not to say that documenting how things actually are is not
worthwhile, it's just not what we do. We describe something that
hopefully leads to convergence between implementations. That way
developers five to ten years or so from now, no longer have to paper
over the differences.
> I do plan to work with others to figure out the delta. As to the data
> models, at the present time -- and without having actually done the
> necessary analysis -- I am not aware of a single case where they would be
> different.
I just gave you one, "%"... E.g. "http://example.org/?%" does not have
an RFC 3986 representation.
--
https://annevankesteren.nl/
Received on Saturday, 1 November 2014 11:56:51 UTC