Re: [xml] URIEncoding

In message <20020622192712 M97099 icimatch com>
          "Sebastian Böhm" <seb icimatch com> wrote:


On Sat, Jun 22, 2002 at 12:04:38PM +0200, Sebastian Böhm wrote:
<a href="javascript: if (a < b) do()">do</a>
Is is possible with the current Version of libxml to procude such a line ?
When no, then it is not usable for xslt.

  Well what you show here is againts the requirements for HTML and XML

maybe, but this is a very very common practice.
Netscape4.x refuses to execute javascript like this:
<a href="javascript:%20if%20(%20a%20&lt;%20b)%20do();">do</a>

Can you tell me how I have to write it, so that NS4 can work with that ?
Even if I cut all the spaces:
<a href="javascript:if(a&lt;b)do();">do</a>
NS4 still does not exucute the javascript. (syntax error)

why this is so ?

  Point me to the part of the specification you think libxml2
violate, then I may change my mind, so far I think you're in error !

Maybe libxml2 does not violate HTML, but I think I should have the control of
the output, when I want to violate then I should be able to do this. For XML
this is not neccessary, but for HTML I think it is.
Have you ever seen a Webbrowser (with a market share more than 0.01%) which
behaves correctly to the HTML specification ?

That's not really a justification for breaking what is (or is intended to
be) a totally compliant library. If the HTML being generated by xsltproc is
not to your liking then you might be better off post processing it.

Maybe that what I want violates W3C-HTML, but now it violates reality.

Why should it be impossible to produce such HTML. ( For XALAN/XERCES, SAXON or
MSXML3 this is the normal behavior)

Because it is perpetuating broken behaviour. The specifications are there for
a very good reason. What reality might be is another issue. If you find that
the behaviour of a compliant application is unsuitable for another
application then it is the latter application that is at fault and should be
addressed rather than the former.

I can understand you when you want to be stricly on the spec. I do not develop
libxml , I use it , and from the users perspective I can tell you, that it
would be very nice have controll of the encoding of the src and href attrs.

It is precisely because of the broken behaviour of certain clients that we
end up in this situation. Personally, I would say to stop the brokeness and
concentrate on the making things work compliantly. If you want to generate
broken output then I would recommend that you do something your side. If
a broken behaviour is introduced in libxml then some time down the line
someone is going to come back and ask why such broken behaviour is causing
them problems when the specification explicitly states that it should do
something different. And the whole problem starts again.

For reference, HTML 4.01 specification (just the one I happen to have to
hand at the moment) is very clear about what is acceptable in section 3.2.2.

In certain cases, authors may specify the value of an attribute without any
quotation marks. The attribute value may only contain letters (a-z and A-Z),
digits (0-9), hyphens (ASCII decimal 45), periods (ASCII decimal 46),
underscores (ASCII decimal 95), and colons (ASCII decimal 58). We recommend
using quotation marks even when it is possible to eliminate them.

By extension of this, Netscape is the party at fault and it would seem to be
addressing the wrong problem to break libxml to cope with Netscapes prior

These are obviously my views and I do understand that others believe in
making everything as broken as the lowest common denominator.

Gerph {djf0-.3w6e2w2.226,6q6w2q2,2.3,2m4}
... Eyes to the heavens, screaming at the sky;
    Trying to send you messages, but choking on goodbye.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]