- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Tue, 20 Jan 2015 19:33:29 +0100
- To: Brad Hill <hillbrad@gmail.com>
- Cc: Brian Smith <brian@briansmith.org>, Martin Thomson <martin.thomson@gmail.com>, Mike West <mkwst@google.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>, "Manger, James" <James.H.Manger@team.telstra.com>
On Tue, Jan 20, 2015 at 7:17 PM, Brad Hill <hillbrad@gmail.com> wrote: > I'm not trying to be unfair. I understand this is not cost-free. I just > wonder - yes, we're the first to find a use for this particular syntax. It > looks cheaper now to just do a microformat that meets our needs. (though > there is probably some cost in defining additional attributes and their > processing, e.g. if multivalued, etc.) But what about the next use case for > something like a ni:/// URL? And the third, and fourth? Are we confident > that browsers are never going to accept a hash-based-identifier where today > they accept a URL? They can just reuse the existing microsyntax, no? Given that this is process this URL and then process this microsyntax and the proposal is to have "process this microsyntax", I'm fairly certain the latter is going to win out each time. (Note also that URL parsers are not interoperable at the moment and some will e.g. normalize "%67" to "g" and others won't. And RFC 3986 allows either so you'd have to add that too. Has that been done?) > Or alternately, is there harm in treating RFC6920 as a > microsyntax-in-URL-drag and not using the URL parser on it in this usage? > As such it is slightly more complex than needed when viewed in isolation, > but at least it would not impose (premature) costs on the URL parser. At that point you are essentially forking. (And we would be forking already, since that requires RFC 3986 and we don't have that.) -- https://annevankesteren.nl/
Received on Tuesday, 20 January 2015 18:33:52 UTC