Re: URL comparison
Le 25/04/2013 20:41, s...@cateches.is a écrit : Requests I've heard before I looked at :local-link(): * Simple equality * Ignore fragment * Ignore fragment and query * 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) What about links that point to a null URL with a hash? ie a href=#back-to-top Obviously this is a local link, but it doesn't really fit into the host/path/query segmentation that's defined with the :local-link([0|1|2...]) definition[1]. Perhaps a :local-link(hash) keyword would be appropriate so that we could select links within the page? [1]http://dev.w3.org/csswg/selectors/#local-pseudo Selectors 4 says an element that is the source anchor of a hyperlink whose target's absolute URL matches the element's own document URL. So the href attribute value would be parsed as an URL and made absolute per the usual rules before being matched by :link-local. In an HTML document, without a base element, the base URL would be the document URL and so :link-local would match. However, :local-link() also ignores port/scheme which is not typical. Isn't it perfectly reasonable to expect that a different scheme/port is running an entirely different application? I agree that Selectors 4 should be changed here. URLs that differ only by the scheme or port number should not be considered local. -- Simon Sapin
prollyfill registry [Was: Re: URL comparison]
[ sorry for the cross-posting but not clear which list(s) to remove) ] On 5/1/13 6:05 PM, ext Clint Hill wrote: I'd like to add to what Brian is saying below: This is effectively the goal of the public-nextweb group as I see it. We want to provide a way for developers to build these types of prollyfills and .. More importantly .. Share and publicize them to get the necessary exposure and feedback. Without that second part there is no point in the first. I think prollyfill.org could be more useful if it acted as a registry for these things. In fact Brian and I did this with Hitch (leveraging Github as the source host) and I tend to believe this is the right way. Right now there is a wiki listing the known prollyfills out in the wild but maybe this is not easy to find and not easy to provide feedback too. It's my opinion that prollyfill.org turn into a registry that is simply pointer to Github projects. Thoughts? Having a reliable and up-to-date registry/service like you describe seems like a good idea. (I am indifferent as to where that service is hosted and managed. If any of the data is relevant for WebApps' specs, we could add a reference to the relevant spec in WebApps' [PubStatus] document, as is already done for some specs re CanIUse for implementation data.) -AB [PubStatus] http://www.w3.org/2008/webapps/wiki/PubStatus On 5/1/13 10:03 AM, Brian Kardell bkard...@gmail.com wrote: + the public-nextweb list... On Wed, May 1, 2013 at 9:00 AM, Anne van Kesteren ann...@annevk.nl wrote: On Sun, Apr 28, 2013 at 12:56 PM, Brian Kardell bkard...@gmail.com wrote: 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/ Cool! 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. Did you get any feedback thus far about desired functionality, problems that are difficult to overcome, ..? -- http://annevankesteren.nl/ We have not uncovered much on this one other than that the few people who commented were confused by what it meant - but we didn't really make a huge effort to push it out there... By comparison to some others it isn't a very 'exciting' fill (our :has() for example had lots of comment as did our mathematical attribute selectors) - but we definitely can. I'd like to open it up to these groups where/how you think might be an effective means of collecting necessary data - should we ask people to contribute comments to the list? set up a git project where people can pull/create issues, register tests/track fork suggestions, etc? Most of our stuff for collecting information has been admittedly all over the place (twitter, HN, reddit, blog comments, etc), but this predates the nextweb group and larger coordination, so I'm *very happy* if we can begin to change that. -- Brian Kardell :: @briankardell :: hitchjs.com
Re: URL comparison
On Sun, Apr 28, 2013 at 12:56 PM, Brian Kardell bkard...@gmail.com wrote: 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/ Cool! 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. Did you get any feedback thus far about desired functionality, problems that are difficult to overcome, ..? -- http://annevankesteren.nl/
Re: URL comparison
+ the public-nextweb list... On Wed, May 1, 2013 at 9:00 AM, Anne van Kesteren ann...@annevk.nl wrote: On Sun, Apr 28, 2013 at 12:56 PM, Brian Kardell bkard...@gmail.com wrote: 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/ Cool! 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. Did you get any feedback thus far about desired functionality, problems that are difficult to overcome, ..? -- http://annevankesteren.nl/ We have not uncovered much on this one other than that the few people who commented were confused by what it meant - but we didn't really make a huge effort to push it out there... By comparison to some others it isn't a very 'exciting' fill (our :has() for example had lots of comment as did our mathematical attribute selectors) - but we definitely can. I'd like to open it up to these groups where/how you think might be an effective means of collecting necessary data - should we ask people to contribute comments to the list? set up a git project where people can pull/create issues, register tests/track fork suggestions, etc? Most of our stuff for collecting information has been admittedly all over the place (twitter, HN, reddit, blog comments, etc), but this predates the nextweb group and larger coordination, so I'm *very happy* if we can begin to change that. -- Brian Kardell :: @briankardell :: hitchjs.com
Re: URL comparison
I'd like to add to what Brian is saying below: This is effectively the goal of the public-nextweb group as I see it. We want to provide a way for developers to build these types of prollyfills and .. More importantly .. Share and publicize them to get the necessary exposure and feedback. Without that second part there is no point in the first. I think prollyfill.org could be more useful if it acted as a registry for these things. In fact Brian and I did this with Hitch (leveraging Github as the source host) and I tend to believe this is the right way. Right now there is a wiki listing the known prollyfills out in the wild but maybe this is not easy to find and not easy to provide feedback too. It's my opinion that prollyfill.org turn into a registry that is simply pointer to Github projects. Thoughts? On 5/1/13 10:03 AM, Brian Kardell bkard...@gmail.com wrote: + the public-nextweb list... On Wed, May 1, 2013 at 9:00 AM, Anne van Kesteren ann...@annevk.nl wrote: On Sun, Apr 28, 2013 at 12:56 PM, Brian Kardell bkard...@gmail.com wrote: 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/ Cool! 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. Did you get any feedback thus far about desired functionality, problems that are difficult to overcome, ..? -- http://annevankesteren.nl/ We have not uncovered much on this one other than that the few people who commented were confused by what it meant - but we didn't really make a huge effort to push it out there... By comparison to some others it isn't a very 'exciting' fill (our :has() for example had lots of comment as did our mathematical attribute selectors) - but we definitely can. I'd like to open it up to these groups where/how you think might be an effective means of collecting necessary data - should we ask people to contribute comments to the list? set up a git project where people can pull/create issues, register tests/track fork suggestions, etc? Most of our stuff for collecting information has been admittedly all over the place (twitter, HN, reddit, blog comments, etc), but this predates the nextweb group and larger coordination, so I'm *very happy* if we can begin to change that. -- Brian Kardell :: @briankardell :: hitchjs.com
Re: URL comparison
On Apr 25, 2013 1:39 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Thu, Apr 25, 2013 at 4:34 AM, Anne van Kesteren ann...@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. ?xy will be identical to
?yx, 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.
Re: URL comparison
Dear Anne,
On Thu, Apr 25, 2013 at 12:34 PM, Anne van Kesteren ann...@annevk.nl wrote:
Background reading: http://dev.w3.org/csswg/selectors/#local-pseudo
and http://url.spec.whatwg.org/
Local link pseudoselector, as presently specified, seems to be tightly
coupled to the absolute URI design of the domain from which the
resource is served. This seems quite brittle and will cause weird
behavior when resources are inevitably rearranged. Consider the case
of a compressed archive with markup documents and CSS files.
I believe the web already has several syntaxes for dealing with this
and related problems. I propose standards harmonization below.
: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.
I agree that URI comparison is quite important and powerful. I am very
excited to see a consistent and simple comparison specification
emerge.
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. ?xy will be identical to
?yx, which is normally not the case)
* Origin equality (ignores username/password/path/query/fragment)
These are all types of pattern-matching.
* 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)
This is a function specification.
: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).
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.
Fundamentally, comparison is about structural pattern-matching. As it
happens, the WWW already has an incredibly widespread syntax which
internally performs pattern-matching: relative URI references. (aside:
mathematically, relative URI refs are hylomorphic function
specifications on otherwise opaque identifier strings)
To that end, I propose a factorization of the tightly coupled parsing
specification in WHATWG URL resulting in 3 separate functions:
1. parsing
2. normalization
3. relative reference resolution
Once this specification is properly factored, discussion,
specification and implementation of the pattern-matching semantics of
:local-link() and equivalent JavaScript functionality becomes much
easier. This is elucidated in my proposal below.
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
PROPOSAL
I believe the primary objective of this work is to define a syntax for
URI patterns. There are presently 2 different but compatible standard
URI pattern syntaxes:
1. RFC 3986 Relative URI references
2. RFC 6570 http://tools.ietf.org/html/rfc6570 URI templates
Through re-use of these pattern syntaxes, the :local-link()
pseudoselector gains incredible flexibility, expressivity,
consistency, and (to my eye) simplicity.
I will use the notation [path] | [pattern] for pattern matching.
I haven't worked out *all* the details yet, but here are some possible
patterns to get us started:
= own-document links
. = this document's path (/foo/bar/baz | . = /foo/bar/ and
/foo/bar/ | . = /foo/bar/ | )
./ = this document's path or deeper (includes path-sibling resources and self)
.. = this document's parent path (/foo/bar/ | .. = /foo/)
../ = this document's parent path or deeper (includes aunts/uncles and self)
../. = ..
/ = this domain (':local-link(0)')
https:///; = HTTPS resources on this domain
Now, at this point, you may say But, David, this syntax can't even
express the current :local-link() examples! and you would be right.
However, this syntax can easily express links to resources *relative*
to the present one which is a crucial feature for any URI pattern
matching system.
Let's now consider the extension of this syntax with the syntax of RFC
6570. In particular, the construct we appear to be missing from the
URI reference syntax is *binding*. RFC 6570 concerns URI construction
but we can easily envision using the same syntax for the inverse of
construction, destruction. Because we do not require to bind
structural elements into a local
URL comparison
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.
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. ?xy will be identical to
?yx, 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).
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.
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.
--
http://annevankesteren.nl/
Re: URL comparison
On Thu, Apr 25, 2013 at 4:34 AM, Anne van Kesteren ann...@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. ?xy will be identical to
?yx, 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
RE: URL comparison
Requests I've heard before I looked at :local-link(): * Simple equality * Ignore fragment * Ignore fragment and query * 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) What about links that point to a null URL with a hash? ie a href=#back-to-top Obviously this is a local link, but it doesn't really fit into the host/path/query segmentation that's defined with the :local-link([0|1|2...]) definition[1]. Perhaps a :local-link(hash) keyword would be appropriate so that we could select links within the page? [1]http://dev.w3.org/csswg/selectors/#local-pseudo However, :local-link() also ignores port/scheme which is not typical. Isn't it perfectly reasonable to expect that a different scheme/port is running an entirely different application? -s
Re: URL comparison
On Thu, Apr 25, 2013 at 11:41 AM, s...@cateches.is wrote: Requests I've heard before I looked at :local-link(): * Simple equality * Ignore fragment * Ignore fragment and query * 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) What about links that point to a null URL with a hash? ie a href=#back-to-top Obviously this is a local link, but it doesn't really fit into the host/path/query segmentation that's defined with the :local-link([0|1|2...]) definition[1]. Perhaps a :local-link(hash) keyword would be appropriate so that we could select links within the page? That's what :local-link (without the ()) is for - it selects links within the same page. That is, links where the url is identical, ignoring the hash. However, :local-link() also ignores port/scheme which is not typical. Isn't it perfectly reasonable to expect that a different scheme/port is running an entirely different application? Yes, which is why Anne says that we should include port/scheme in the comparison. ~TJ
