On 07/07/11 16:10, Lex Trotman wrote:
Hi Lionel,
Nice detective work.
On 7 July 2011 00:47, Lionel Orry<[email protected]> wrote:
Hi again Lex (and sorry to disturb you :) ),
Le mercredi 6 juillet 2011 16:12:15 UTC+2, Lex Trotman a écrit :
On 6 July 2011 23:04, Lionel Orry<[email protected]> wrote:
Well, it seems I found the problem: the<object> tag cannot be auto-closing.
So we should replace
<object data="{imagesdir=}{imagesdir?/}{target}" type="image/svg+xml" />
Thats a perfectly valid empty element, and to quote the XML spec
"Empty-element tags may be used for any element which has no content"
I've been digging into this as well, and I know it's a valid element.
The fact is asciidoc generates a file whose extension is ".html",
whatever the content is HTML or XHTML (thus XML). And a local file
opened by Firefox (for example) sees its mime-type set according to
the file extension.
To give it a try, I created a symbolic link to my faulty test_svg.html
called test_svg.xhtml.
The '.xhtml' link displays correctly, while the '.html' does not. The
corresponding info pages show that the first one only has the correct
mime-type (application/xhtml+xml).
I've not found any way to force the mime-type to be different with
some content in the xhtml source. It is feasible with addons that help
you force the mime-type, but it's not my personal goal to do that.
May those findings make the ".html" extension given by asciidoc
questionable? Yes and no. For the majority of browsers to get the
right mime-type, we might probably need to name these ".xhtml" or
".xml". But the .html extension is handy for other reasons (we humble
users notice immediately that the file is viewable in a browser, and
there's a high change that double-clicking on it or 'xdg-open' it will
open the right app for this, i.e. a web browser.).
The lesson to remember from this experiment is that if you open a
local file generated by asciidoc and supposedly XHTML, it will be
rendered as HTML by certain browsers !
And in which case the empty element syntax IS illegal. Of course we
can always explicitly specify the outfile name ;-).
by
<object data="{imagesdir=}{imagesdir?/}{target}"
type="image/svg+xml"></object>
But I suppose to make erroneous browsers work this is ok. (After all
there is a long history of adjusting HTML so that dumb browsers work,
hi IE :-)
Well in that case the browsers were not erroneous, they were rendering
content as text/html, that's all. But indeed the fix is easy so that
everyone is happy, so why not...
Well ok then, the bug was in using the mime type over the explicitly
declared content type. Still a bug to be worked around. If your beta
is less than two weeks old you might try submitting a bug report to
Firefox, you never know they might listen.
or even better:
<object data="{imagesdir=}{imagesdir?/}{target}" type="image/svg+xml">
<span class="comment"><strong>ERROR</strong>: SVG file '{target}' cannot
be rendered</span>
</object>
Or even better have an attribute for user supplied alternate text.
In fact this is probably very important for accessibility.
Now all we need is for Stuart to come out of hibernation ... (well it
is winter in NZ :-)
Can't drag myself away from The Tour, wind trainer out TV on!
I see things are starting to back up a bit, just looking for a clear block of
time and some motivation :-)
Cheers, Stuart
Cheers
Lex
--
You received this message because you are subscribed to the Google Groups
"asciidoc" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/asciidoc?hl=en.
