David said:
David said:
David said:
kangax wrote:
On 3/27/10 6:51 PM, David Mark wrote:
David Mark wrote:
David Mark wrote:
[...]
And just ran into another one. This one was just missing:-
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
...and putting that in fixed it. You can see it in action here:-
http://code.eblackwelder.com/demos/MyWidgetsLibrary/MyTabs/index.html
...at least until I let the author know to add the missing META. Is
Opera ever picky when it comes to XPath. Of course, it isn't a good
idea to leave off that META (as the W3C validation service will tell
you).
The author of the example didn't even (knowingly) use a query. My
getEBCN has the one freaking line of code in the entire library that
calls getEBCS (never the QSA version though as it is an external
adapter). I was always on the fence as to whether I wanted to do that
(call getEBCS internally). I didn't want to add a third fork for the
host-provided gEBCN at the time as it was too new. And I would rather
not have to duplicate the loop and check code that is already in the
query module. But then, it is sort of lame to make getEBCN available
only as part of the query module (something I could address on the
server side). Like XHTML support, I need to add a flag (and eventually
a build option) to disable (or exclude) the XPath forks.
That coming to mind was no coincidence. The docs (on my site) explain
what is going with both issues. It's that $%# isXmlParseMode method,
which is thoroughly unforgiving and lacking any real robustness (it
should really be attempting to create a namespaced element rather than
just looking at the createElementNS method and noting whether the user
included an appropriate META or not). Still, that contract is
documented (should probably have a big red star next to it or
something). The first cited failure was because the META was included
at the end of the HEAD (not above the TITLE where it belongs). The
unforgiving part is good (both users will now know to always when and
where to include this META). The lack of robustness is very bad.
So does `document.evaluate` failure have to do with position of
content-type/charset META in regards to TITLE, or is it some encoding
issue related to content-type sniffing and META positioned low in the
HEAD? Or was META missing completely?
Not a thing.
Referring to your "what does it have to do with" query. As for the
latter two queries, both happened. One user left it out of their
example and the other had it after the script. Imagine my chagrin to
see their otherwise fine efforts failing in Opera. D'oh!
And sorry for the confusion about the TITLE. The SCRIPT is what matters
(i.e. it must come after the appropriate META). In my mind, the SCRIPT
follows the TITLE, but that is irrelevant to the issue.
The builder is updated. XHTML support can now be filtered at build
time. That is what I should have done in the first place, but the
original My Library (server and client side) was more of a furious
stream-of-consciousness than an actual design. Thanks to my
indifference to marketing it over the years, the user base is still
small enough for me to mold it into something better (getting there).
The button that launches the XHTML test page is disabled when this
support is filtered; but, of course, that can be "fooled" by disabling
scripting or using a browser that doesn't disable buttons dynamically
(e.g. Opera 6, NN4). If you fool it, the XHTML test page issues a
warning at the top that you are trying to test XHTML, but the build is
lacking XHTML support. But, for the most part, it doesn't seem to make
any difference (i.e. the test page still works). The notable exception
(as discussed in this thread) is the query module in XPath-capable
browsers. This can be demonstrated by fooling the test page and running
the unit tests in an XPath-capable browser (most modern standards-based
browsers have it). All but the query tests pass. This confirms that
the XPath query fork was correct to add the html namespace to its
expressions (as failing to do so results in failure in at least some
XHTML DOM's). I thought I had a reason to do that, but couldn't
remember as it has been too long since I wrote it and my commenting on
the original code was fairly non-existent (something else I am
addressing now). The problem that arose was that XML parse mode was
being falsely identified due to page authors breaking the documented
contract related to the Content-Type META (is the last resort fallback
for the isXmlParseMode test). With this new build option, authors can
ignore that contract without being bitten by false positives.
If you are wondering how the XHTML test page can (mostly) work without
XHTML support, it is because My Library only deals with the (default)
HTML namespace. However, the next update to the query module, which
adds support for XML DOM's (e.g. XHR results) will add support for other
namespaces. Of course, the XML DOM support is unrelated to XHTML support.
For those who wish to forget all of these details, follow the
recommendation on the new builder and *exclude* XHTML support. If you
don't follow the preceding discussion, you definitely don't need such
support. If you use the full build from the Downloads page, you can
disable XHTML support by setting an API property:-
var API = { disableXmlParseMode:true };
See:-
http://www.cinsoft.net/mylib-doc.asp#isxmlparsemode
On a slightly related note, users of the full build are advised to set
the deferAudio property in the same way. I will change the default for
that one (needs to be true) in the near future.
var API = { disableXmlParseMode:true, deferAudio:true };
This keeps audio plug-ins from being initialized on load (definitely
something to avoid in most cases). Should definitely be used for those
who seek to run query unit tests as well as the initialization adds two
OBJECT's to the DOM.
