|
Re: [xsl] Why does Chrome's XSL processor validate my XML files when processing them, and how can I make it stop doing that so that it processes them faster?
2021-02-21 06:40:44
Thank you very much, all of you, for your replies!
You were right, the source of the problem is not the parsing of the XSD.
I removed "xsi:noNamespaceSchemaLocation=...", and it didn't resolve the
problem. Then I also removed
"xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'", and it still
didn't resolve the problem. It should have occurred to me to try that,
sorry. Anyway, then I looked at the console of Chrome and found out that
the problem is not in fact one of speed of performance: The loading of
the file takes around 200 ms in either case. But when no DTD is
specified, I see the screen turn white for a fraction of a second, which
made me believe that the issue was speed.
Knowing these things, I realized that the problem is actually a known
bug of Chrome. In certain cases, Chrome produces a "white flash" (as it
apparently came to be called) before loading a page. Here is one
description of it:
https://superuser.com/questions/717343/how-can-i-make-chromes-white-flash-when-a-new-tab-is-opened-be-black
So the situation is that, when a DTD is specified, no white flash
occurs, but when an XSD is specified or nothing is specified, it does
occur. I still have not figured out why that is. In one description of
the bug, I read that the white flash occurs when a page "of a new
domain" is loaded. Maybe, when a DTD is specified, Chrome takes the
pages to be of the same domain, and otherwise not. That does not really
make sense to me, but it is the only possible explanation that I have
found so far. Anyway, I now know the cause of the problem and should be
able to find a solution. So, thanks again!
As for Firefox, you were right, Martin. Firefox does not execute my
stylesheet because it is in the parent folder. If I put the stylesheet
into the same folder as the file, Firefox does execute it (provided that
the security setting pointed out by Michele is deactivated). And Firefox
does not produce a white flash. So, if I can't resolve the problem with
Chrome, I might consider moving the stylesheet and switching to Firefox.
Many thanks,
Wolfhart
On 21-02-21 08:37, Martin Honnen martin(_dot_)honnen(_at_)gmx(_dot_)de wrote:
Am 21.02.2021 um 04:57 schrieb Wolfhart Totschnig
wolfhart(_dot_)totschnig(_at_)mail(_dot_)udp(_dot_)cl:
Thank you, Kurt, Liam, and Michele, for the prompt replies!
Kurt's and Michele's suggestions did not resolve my problem. Installing
the "XML Tree" extension for Chrome did not accelerate the processing of
the XSL stylesheet, and Firefox still refuses to execute the stylesheet
after changing the said security setting.
To Liam's suggestions:
Are you producing XHTML with a DOCTYPE?
No, just HTML (see below).
Without seeing teh stylesheets or the input or the output it's
impossible to say.
I am not sure what a minimal example would be in this case. Here, at any
rate, are the preambles of the XML files and of the stylesheet:
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="../zettel.xsl"?>
<zettel xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:noNamespaceSchemaLocation="../zettel.xsd">
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.1"
For XSLT using 1.1 seems an odd version, I have to say, as that never
was a final W3C recommendation. Not likely, however, to be the cause of
your problem. Does Firefox execute your XSLT if you change version to
1.0 and use the security setting change Michelle posted earlier?
But I think Firefox for local file URIs only allows downwards selection
like `href="zettel.xsl"` or `href="subdir/zettel.xsl"`, not any upwards
navigation like ".." in the file system.
--~----------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
EasyUnsubscribe: http://lists.mulberrytech.com/unsub/xsl-list/1167547
or by email: xsl-list-unsub(_at_)lists(_dot_)mulberrytech(_dot_)com
--~--
|
|