- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Mon, 24 Sep 2012 10:58:20 +0200
- To: Boris Zbarsky <bzbarsky@mit.edu>
- Cc: whatwg@lists.whatwg.org
On Fri, Sep 21, 2012 at 5:36 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote: > On 9/21/12 11:16 AM, Anne van Kesteren wrote: >> * data URLs; in Gecko these appear to be parsed as part of the URL >> layer, because they can turn a URL invalid. Other browsers do not do >> this. Opinions? Should data URLs support .search? > > I'm not quite sure what you mean by "parsed as part of the URL layer" here. > What's the concern? Say you have <a href="data:test"/>; the concern is what e.g. a.protocol and a.pathname would return here. For invalid URLs they would return ":" and "" respectively. If we treat this as a valid URL you would get "data:" and "test". In Gecko I get "http:" and "". If I make that <a href="data:text/html,test"/> Gecko will give meaningful answers (well pathname is still "", maybe that is okay and pathname should only work for hierarchical URLs). More general, what I want is that for *any* given input in <a href="..."/>, xhr.open("GET", ...), new URL(...), etc. I want to be able to tell what the various URL components are going to be. The kind of predictability we have for the HTML parser, I want to have for the URL parser as well. (If that means handling data URLs at the layer of the URL parser rather than a separate parser that goes over the path, as Gecko appears to be doing, so be it.) >> * Advice on file URLs would be nice. > > Abandon Hope All Ye Who Enter Here? ;) > > If you want constructive advice, it would be interesting to get a full list > of all the weird stuff that UAs do here so we can evaluate which parts of it > are needed and why. I can try to produce such a list for Gecko, if there > seems to be motion on the general idea. I think that would be a great start. I'm happy to start out with Gecko's behavior and iterate over time as feedback comes in from other browsers. -- http://annevankesteren.nl/
Received on Monday, 24 September 2012 08:58:51 UTC