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? 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. On Tue Jan 20 2015 at 10:05:25 AM Anne van Kesteren <annevk@annevk.nl> wrote: > On Tue, Jan 20, 2015 at 6:51 PM, Brad Hill <hillbrad@gmail.com> wrote: > > "not invented here". > > That seems unfair. As far as I know we don't currently use URLs for > anything other than fetching and navigating throughout the web > platform. We do have a fair amount of trivial microsyntaxes for other > tasks, especially in HTML. > > It is also not like we get any leverage out of using URLs here as this > is essentially a microsyntax layered on top of a URL. We first have to > parse it as a URL, then I guess we have to check that there is no host > component (not possible per current URL parser definition by the way), > then we have to split the path component in various ways and do checks > on the query. Did you define processing for what happens if there is a > fragment there or username and password information? > > > -- > https://annevankesteren.nl/ >
Received on Tuesday, 20 January 2015 18:18:21 UTC