On Sun, 29 Mar 2009, Giovanni Campagna wrote:
(In this email I will use URL5 as a short for Web Addresses, as that
previously was the URL part of HTML5)
This section is to be extracted from HTML5 shortly. I've forwarded your
e-mails to DanC, the editor of the Web Addresses spec.
Cheers,
--
On Sun, 22 Mar 2009, Giovanni Campagna wrote:
As far as I can tell the LEIRI requirements aren't actually an
accurate description of what browsers do.
My question was more specific: what are the *techical differences*
betwen LEIRI and Web Addresses?
I don't think there's a complete
On Mon, 23 Mar 2009, Julian Reschke wrote:
Ian Hickson wrote:
Note that the Web addresses draft isn't specific to HTML5. It is
intended to apply to any user agent that interacts with Web content,
not just Web browsers and HTML. (That's why we took it out of HTML5.)
Be careful;
2009/3/29 Kristof Zelechovski giecr...@stegny.2a.pl:
It is not clear that the server will be able to correctly support various
representations of characters in the path component, e.g. identify accented
characters with their decompositions using combining diacritical marks. The
peculiarities
(In this email I will use URL5 as a short for Web Addresses, as that
previously was the URL part of HTML5)
As subject says, this is the continuation of the thread about LEIRI vs
URL5 archived at
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-March/018929.html,
where discussion diverged
2009/3/29 Anne van Kesteren ann...@opera.com:
On Sun, 29 Mar 2009 14:37:19 +0200, Giovanni Campagna
scampa.giova...@gmail.com wrote:
Summing up, the differences between URL5 and LEIRI are only about the
percent sign and its uses for delimiters.
I'm not sure if you're correct about those
On Sun, 29 Mar 2009 15:01:51 +0200, Giovanni Campagna
scampa.giova...@gmail.com wrote:
2009/3/29 Anne van Kesteren ann...@opera.com:
I'm not sure if you're correct about those differences, but even if you
are they are not the only differences. E.g. LEIRIs perform
normalization if the input
2009/3/29 Anne van Kesteren ann...@opera.com:
On Sun, 29 Mar 2009 15:01:51 +0200, Giovanni Campagna
scampa.giova...@gmail.com wrote:
2009/3/29 Anne van Kesteren ann...@opera.com:
I'm not sure if you're correct about those differences, but even if you
are they are not the only differences.
It is not clear that the server will be able to correctly support various
representations of characters in the path component, e.g. identify accented
characters with their decompositions using combining diacritical marks. The
peculiarities can depend on the underlying file system conventions.
Ian Hickson wrote:
...
Note that the Web addresses draft isn't specific to HTML5. It is intended
to apply to any user agent that interacts with Web content, not just Web
browsers and HTML. (That's why we took it out of HTML5.)
...
Be careful; depending on what you call Web content. For
On Mon, 23 Mar 2009 09:45:39 +0100, Julian Reschke julian.resc...@gmx.de
wrote:
Ian Hickson wrote:
...
Note that the Web addresses draft isn't specific to HTML5. It is
intended to apply to any user agent that interacts with Web content,
not just Web browsers and HTML. (That's why we took
Anne van Kesteren wrote:
Be careful; depending on what you call Web content. For instance, I
would consider the Atom feed content (RFC4287) as Web content, but
Atom really uses IRIs, and doesn't need workarounds for broken IRIs in
content (as far as I can tell).
Are you sure browser
On Mon, 23 Mar 2009 11:25:19 +0100, Julian Reschke julian.resc...@gmx.de
wrote:
Anne van Kesteren wrote:
Be careful; depending on what you call Web content. For instance, I
would consider the Atom feed content (RFC4287) as Web content, but
Atom really uses IRIs, and doesn't need workarounds
Anne van Kesteren wrote:
I wasn't talking of browser implementations of feeds, but feed
readers in general.
Well yes, and a subset of those is browser based. Besides that, most
feed readers handle HTML. Do you think they should have two separate URL
parsing functions?
Yes, absolutely.
On Mon, 23 Mar 2009 11:31:01 +0100, Julian Reschke julian.resc...@gmx.de
wrote:
Anne van Kesteren wrote:
Well yes, and a subset of those is browser based. Besides that, most
feed readers handle HTML. Do you think they should have two separate
URL parsing functions?
Yes, absolutely.
Why?
Anne van Kesteren wrote:
On Mon, 23 Mar 2009 11:31:01 +0100, Julian Reschke
julian.resc...@gmx.de wrote:
Anne van Kesteren wrote:
Well yes, and a subset of those is browser based. Besides that, most
feed readers handle HTML. Do you think they should have two separate
URL parsing functions?
On Mon, 23 Mar 2009 11:46:15 +0100, Julian Reschke julian.resc...@gmx.de
wrote:
Because it's preferable to the alternative, which is, leaking out the
non-conformant URI/IRI handling into other places.
Apparently that is already happening in part anyway due to LEIRIs. Modulo
the URL
Anne van Kesteren wrote:
On Mon, 23 Mar 2009 11:46:15 +0100, Julian Reschke
julian.resc...@gmx.de wrote:
Because it's preferable to the alternative, which is, leaking out the
non-conformant URI/IRI handling into other places.
Apparently that is already happening in part anyway due to LEIRIs.
On Mon, 23 Mar 2009 11:58:59 +0100, Julian Reschke julian.resc...@gmx.de
wrote:
Whitespace is a big issue - auto-highlighting will fail all over the
place.
Auto-higlighting and linking code already fails all over the place due to
e.g. punctation issues. A solution for whitespace
Anne van Kesteren wrote:
The issue is that it's *not* the same thing.
Well, no, not exactly. But they perform essentially the same task,
modulo a few characters. And since one is a superset of the other (as
long as URL encoding is UTF-8) I don't see a point in having both.
Well, then let's
Anne van Kesteren wrote:
On Mon, 23 Mar 2009 12:50:46 +0100, Julian Reschke
julian.resc...@gmx.de wrote:
...and other characters that are not allowed in URIs and IRIs, such as
{ and } (which therefore can be used as delimiters).
And keeping them invalid but requiring user agents to handle
On Mon, 23 Mar 2009 12:50:46 +0100, Julian Reschke julian.resc...@gmx.de
wrote:
...and other characters that are not allowed in URIs and IRIs, such as
{ and } (which therefore can be used as delimiters).
And keeping them invalid but requiring user agents to handle those
characters as part
On Mon, 23 Mar 2009, Julian Reschke wrote:
You are essentially proposing to change existing specifications (such as
Atom). I just do not see the point.
The point is to ensure there is only one way to handle strings that are
purported to be IRIs but that are invalid. Right now, there are at
Ian Hickson wrote:
On Mon, 23 Mar 2009, Julian Reschke wrote:
You are essentially proposing to change existing specifications (such as
Atom). I just do not see the point.
The point is to ensure there is only one way to handle strings that are
purported to be IRIs but that are invalid. Right
[cc'ed DanC since I don't think Dan is on the WHATWG list, and he's the
editor of the draft at this point]
On Mon, 23 Mar 2009, Julian Reschke wrote:
For example, curl will not refuse to fetch the URL
http://example.com/% despite that URL being invalid.
Should it refuse to?
The
Ian Hickson wrote:
[cc'ed DanC since I don't think Dan is on the WHATWG list, and he's the
editor of the draft at this point]
On Mon, 23 Mar 2009, Julian Reschke wrote:
For example, curl will not refuse to fetch the URL
http://example.com/% despite that URL being invalid.
Should it refuse
On Mon, 23 Mar 2009, Julian Reschke wrote:
However, what seems to be more likely is that one tool refuses to fetch
the file (because the URI parser didn't like it), while in the other
case, the tool puts the invalid URL on to the wire
IMHO this is basically the definition of a standards
On Mar 23, 2009, at 2:25 PM, Ian Hickson wrote:
On Mon, 23 Mar 2009, Julian Reschke wrote:
However, what seems to be more likely is that one tool refuses to
fetch
the file (because the URI parser didn't like it), while in the other
case, the tool puts the invalid URL on to the wire
IMHO
On Sat, 21 Mar 2009, Giovanni Campagna wrote:
Now I would like to ask:
are there any major differences that requires the W3C / WHATWG to
publish an other specification, just for HTML5, instead of just
referencing the IRI-bis draft or the LEIRI working group note?
As far as I can tell the
2009/3/22 Ian Hickson i...@hixie.ch:
On Sat, 21 Mar 2009, Giovanni Campagna wrote:
Now I would like to ask:
are there any major differences that requires the W3C / WHATWG to
publish an other specification, just for HTML5, instead of just
referencing the IRI-bis draft or the LEIRI working
HTML5 originally included a section about resource identifiers
processing. A few days ago that section was extracted into the W3C
editor draft of Web Addresses. I noticed it and remembered that I had
read once something like that.
Precisely, what I once read is http://www.w3.org/TR/leiri, a note
31 matches
Mail list logo
