Dear explorer,
You’re always so nice to me. You give me all kinds of useless javascript errors, if ever you give them rather than simply executing nothing without the slightest tell. You break all kinds of standards, you’re not even able to tell the difference between a border and a padding when you go to the length of using the width of an element (it should be easy enough to skin the first 20 pages of a specs for a team of developers; perhaps it is not). You don’t like the DOM, don’t like ECMAscript, you make us put ActiveX all around. for even the simplest task But yet, one thing I wonder: tell me why, if I put inside an element <input type=”checkbox” value=”/management”>, when I ask you back the content of the element you tell me it is <INPUT type=checkbox value=/management>, bringing my memories back to the terrific days of HTML 3?
Take care and burn in hell,
- RedGlow
Posted by mattia as html at 3:53 PM CEST
No Comments »
It’s so nice to have standards. DocBook is one which is good enough for many uses. E.g., the notes for the linux system and network administration course I’m writing which I mentioned about some posts ago.
So, tell me why if you ask for an SVG image to be right aligned, 5cm wide and to scale height appropriately, the results with, respectively, the Norman Walsh XHTML XSL stylesheets and his same FO stylesheets and FOP, are the following:
The code was:
<imagedata
width=”5cm”
align=”right”
fileref=”stack_tcp_ip.svg”
format=”SVG”
scalefit=”1″/>
I know, I ask much, since I involved SVG, DocBook, XHTML, XSL and PDF all in a single cauldron, but… damn, they are ALL standards! :-P
– 2:15 update
I tried for a while to make things fit well, and they didn’t. So, I chose to make conversion to PNG beforehand. This worked well for HTML version, but gave very ugly results in PDF, which uses higher DPI. So I renounced to a single format, and gave double specification of images in the docbook (why have I used a vectorial format, then…). I tried to include PDF in PDF version, but FOP crashes on it (isn’t able to get information from PDF; the comic thing is that he says in turn: “Content is not allowed in prolog”, “Error while recovering image information” and “GRAVE: Image not available” - a perfect case of exception misunderstanding). So I chose for double version PNG (a 90dpi and a 600dpi one), and this way it worked. Almost. In the XHTML version, the “right” alignment is interpreted as a float, in the PDF, as a normal align. Well, I can’t have everything. All in all, I had to make some four trials, which should have all worked, and instead only one did. *GROWL*.
Posted by mattia as docbook, fo, fop, html, image, svg, xhtml, xml, xsl at 9:35 PM CEST
1 Comment »
Substantially, this has made me mad. In the current status, you can’t reliably use getElementById on objects returned by an XMLHttpRequest. Useless to say, there’s a way to make things work correctly, but only under Firefox. Sigh.
Posted by mattia as ajax, ecmascript, html, xml at 2:19 PM CEST
No Comments »
When Zope parses text/html elements, instead of XML (xhtml and the like) uses a different parser. That is, not an XML parser, but rather an HTML parser like the ones used by browser, more relaxed, which allows for unclosed tags and the liks.
BUT…
there’s always a but. In HTML, technically speaking, not all combinations of tags are allowed, even if browsers permit it. E.g., a span cannot contain a div. So, zope too complains about this fact. But how does it complain?
Page Template Diagnostics
Compilation failed
zope.tal.htmltalparser.NestingError: Open tags <html>, <body>, <div>, <div>
do not match close tag </span>, at line 105, column 5
Now, please, tell me, why the fuck you told me about not matching tags when the problem is that the document in not valid against given DTD?!?! So, I lost a whole afternoon after this wrong error message, before been enlightened by the documentation. For sure, I didn’t mind looking at it, since the error message did state quite clearly what the problem was.
One more notes about designing programs in the future. Tell a lots of things when an error come out but, above all, tell the REAL error, not some approximate, wrong information. This is much worse that a laconic error message.
Posted by mattia as html, xhtml, zpt at 10:47 AM CEST
No Comments »
