1

I'm using PrinceXML to make some PDFs of some HTML which includes some MathJax markup. In order to render the math properly, the javascript handling the math rendering needs to be run on the page before conversion to PDF.

If I enable javascript in PrinceXML and try to load the MathJax library, I get a "TypeError: null value is not an object" in the initialisation code. Tracking this down, it turns out that the following causes the error:

var scripts = (document.documentElement || document).getElementsByTagName("script");
var namePattern = new RegExp("(^|/)"+BASENAME+"\\.js(\\?.*)?$");
for (var i = scripts.length-1; i >= 0; i--) {
if (scripts[i].src.match(namePattern)) { // <--- Error thrown here
  STARTUP.script = scripts[i].innerHTML;
  if (RegExp.$2) {
    <etc...>

The error is thrown on a script element without an src attribute (MathJax uses script elements to store LaTeX code in). PrinceXML appears to handle missing src attributes by returning null when accessing a missing src attribute - hence scripts[i].src.match(namePattern) throws an error as src is null. However, when done in Firefox (see fiddle: http://jsfiddle.net/9ZHMR/) element.src returns the empty string when the src attribute is missing, and so I didn't see this issue when working in the browser.

Which behaviour is 'correct' - should a script element's src attribute be null or the empty string if the attribute does not exist? Is this a case of real-life vs the standards?

EDIT I'm interested primarily in whether this behavior is specified by a standard somewhere, so I know whether to post a bug report to Firefox or PrinceXML, or if there is no standard, post a bug report to MathJax to handle this case.

Community
  • 1
  • 1
almailer
  • 45
  • 1
  • 6

3 Answers3

1

This depends on the specific implementation for the HtmlScriptElement. If the specific implementation has the src attribute predefined as an empty string as it seems to be the case in FireFox then the src would be returned as an empty string. If it is initially defined to be null then src would be returned as null.

Konstantin Dinev
  • 34,219
  • 14
  • 75
  • 100
  • The src attribute is defined as #IMPLIED in the standard linked above, and has no default value. Is the empty string not a default value? My interpretation is that the value of an attribute which is #IMPLIED and missing from the document with no default specified shoulw be null? – almailer Sep 27 '12 at 09:34
  • The above is a standard, however javascript engines implement it differently, thus all the browser differences we all love so much. – Konstantin Dinev Sep 27 '12 at 09:59
1

You could probably avoid the error with this minor amendment, which checks for a src before using it:

if (scripts[i].src && scripts[i].src.match(namePattern)) {
    ...

Or long hand...

if (scripts[i].src) {
    if (scripts[i].src.match(namePattern)) {
        ...

If scripts[i].src is null, it will evaluate as "falsey".

Fenton
  • 241,084
  • 71
  • 387
  • 401
  • Thanks for the workaround - however, I'm wanting to establish if there is a specification for this behaviour in the standard. If there is, then I know which project to file a bug report with. If not, then I need to file a bug with MathJax suggesting your fix :) – almailer Sep 27 '12 at 09:36
  • I believe returning `null` is correct if there is no attribute. Returning an empty string for a missing attribute is misleading - especially given that for some attributes, their presence alone (rather than their value) has meaning. – Fenton Sep 27 '12 at 09:57
1

The spec at http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#the-script-element says:

 attribute DOMString src;

That's not a nullable string return value, so returning null from .src is not allowed by the spec.

Boris Zbarsky
  • 34,758
  • 5
  • 52
  • 55
  • We have observed in our code, that the src is being translated to actual null value when refering to `document.scripts`. Thanks to this post, we looked into the spec https://html.spec.whatwg.org/multipage/scripting.html#the-script-element and to our surprise, the `DOMString` has been changed to `USVString` that does not guarantee to be translated ot `'null'` string. – Rafał Czabaj Nov 24 '22 at 15:48
  • `USVString` just means it's a Unicode string (unlike `DOMString`, which could contain any sequence of 16-bit integers that are not actually valid Unicode anything). The spec still does not allow `src` to be null. If it did, the type would be `USVString?` (similar to the `crossOrigin` attribute, but with `USVString`), not just `USVString`. – Boris Zbarsky Nov 26 '22 at 03:56