W3C home > Mailing lists > Public > public-qt-comments@w3.org > August 2005

[Bug 1524] propose new function fn:escape-html-uri

From: <bugzilla@wiggum.w3.org>
Date: Wed, 17 Aug 2005 04:38:48 +0000
To: public-qt-comments@w3.org
Cc:
Message-Id: <E1E5FhQ-000517-Ae@wiggum.w3.org>

http://www.w3.org/Bugs/Public/show_bug.cgi?id=1524





------- Additional Comments From fsasaki@w3.org  2005-08-17 04:38 -------
(In reply to comment #2)
> Here's an attempt to clarify this confusing subject.
> 
> Currently, the serialization specification, when describing URI escaping for 
the
> HTML output method, does indeed contain a reference to XLink; but the detailed
> algorithm described is actually by design identical to that described in
> Appendix B.2.1 of the HTML 4.01 specification:
> 
> http://www.w3.org/TR/1999/REC-html401-19991224/appendix/notes.html#non-ascii-
chars
> 
> People have often asked why we escape non-ASCII characters rather than 
escaping
> the characters listed in the XLink specification; it seems useful therefore to
> reference the HTML algorithm rather than the XLink algorithm, since that is 
the
> one we are using. (The practical reason for choosing this algorithm is that
> using the XLink algorithm doesn't work: in particular, it breaks many 
Javascript
> URIs in typical browsers).
> 
> This proposal (which the WGs have accepted) makes the algorithm which is
> currently built-in to the serializer available as a user-callable function, so
> that applications can invoke it when they need it and use a different 
algorithm
> when they don't. As a result of this proposal, there is a new F+O function 
which
> refers to the HTML 4.01 specification, and the serialization specification 
will
> refer to this new F+O function to describe the default serialization behavior.
> 
> Does this make things clearer?
> 
> Michael Kay (personal response)

Sorry for the late reply. Yes, this makes things clearer. Thank you very much 
for your explanatation.

Felix Sasaki
Received on Wednesday, 17 August 2005 04:38:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:57:07 UTC