On Apr 25, 2013 1:39 PM, "Tab Atkins Jr." <[email protected]> wrote: > > On Thu, Apr 25, 2013 at 4:34 AM, Anne van Kesteren <[email protected]> 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.
