W3C home > Mailing lists > Public > www-style@w3.org > April 2013

Re: URL comparison

From: Brian Kardell <bkardell@gmail.com>
Date: Sun, 28 Apr 2013 07:56:10 -0400
Message-ID: <CADC=+jcuCEws_A3qqBoaLJQwkR5z5P9jgjLO1dMimNgHj8y-WA@mail.gmail.com>
To: "Tab Atkins, Jr." <jackalmage@gmail.com>
Cc: Anne van Kesteren <annevk@annevk.nl>, www-style@w3.org, WebApps WG <public-webapps@w3.org>
On Apr 25, 2013 1:39 PM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:
>
> On Thu, Apr 25, 2013 at 4:34 AM, Anne van Kesteren <annevk@annevk.nl>
wrote:
> > Background reading: http://dev.w3.org/csswg/selectors/#local-pseudo
> > and http://url.spec.whatwg.org/
> >
> > :local-link() seems like a special case API for doing URL comparison
> > within the context of selectors. It seems like a great feature, but
> > I'd like it if we could agree on common comparison rules so that when
> > we eventually introduce the JavaScript equivalent they're not wildly
> > divergent.
>
> My plan is to lean *entirely* on your URL spec for all parsing,
> terminology, and equality notions.  The faster you can get these
> things written, the faster I can edit Selectors to depend on them. ^_^
>
> > Requests I've heard before I looked at :local-link():
> >
> > * Simple equality
> > * Ignore fragment
> > * Ignore fragment and query
> > * Compare query, but ignore order (e.g. ?x&y will be identical to
> > ?y&x, which is normally not the case)
> > * Origin equality (ignores username/password/path/query/fragment)
> > * Further normalization (browsers don't normalize as much as they
> > could during parsing, but maybe this should be an operation to modify
> > the URL object rather than a comparison option)
> >
> > :local-link() seems to ask for: Ignore fragment and query and only
> > look at a subset of path segments. However, :local-link() also ignores
> > port/scheme which is not typical. We try to keep everything
> > origin-scoped (ignoring username/password probably makes sense).
>
> Yes.
>
> > Furthermore, :local-link() ignores a final empty path segment, which
> > seems to mimic some popular server architectures (although those
> > ignore most empty path segments, not just the final), but does not
> > match URL architecture.
>
> Yeah, upon further discussion with you and Simon, I agree we shouldn't
> do this.  The big convincer for me was Simon pointing out that /foo
> and /foo/ have different behavior wrt relative links, and Anne
> pointing out that the URL spec still makes example.com and
> example.com/ identical.
>
> > For JavaScript I think the basic API will have to be something like:
> >
> > url.equals(url2, {query:"ignore-order"})
> > url.equals(url2, {query:"ignore-order", upto:"fragment"}) // ignores
fragment
> > url.equals(url2, {upto:"path"}) // compares everything before path,
> > including username/password
> > url.origin == url2.origin // ignores username/password
> > url.equals(url2, {pathSegments:2}) // implies ignoring query/fragment
> >
> > or some such. Better ideas more than welcome.
>
> Looks pretty reasonable.  Only problem I have is that your "upto" key
> implicitly orders the url components, when there are times I would
> want to ignore parts out-of-order.
>
> For example, sometimes the query is just used for incidental
> information, and changing it doesn't actually result in a "different
> page".  So, you'd like to ignore it when comparing, but pay attention
> to everything else.
>
> So, perhaps in addition to "upto", an "ignore" key that takes a string
> or array of strings naming components that should be ignored?
>
> This way, :local-link(n) would be equivalent to:
> linkurl.equals(docurl, {pathSegments:n, ignore:"userinfo"})
>
> :local-link would be equivalent to:
> linkurl.equals(docurl, {upto:"fragment"})  (Or {ignore:"fragment"})
>
> ~TJ
>

Anne/Tab,

We created a prollyfill for this about a year ago (called :-link-local
instead of :local-link for forward compatibility):

http://hitchjs.wordpress.com/2012/05/18/content-based-css-link/

If you can specify the workings, we (public-nextweb community group) can
rev the prollyfill, help create tests, collect feedback, etc so that when
it comes time for implementation and rec there are few surprises.
Received on Sunday, 28 April 2013 11:56:38 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:10 UTC