Home/ Questions/Q 7948227
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-04T01:39:51+00:00

I’m working on a project where we went from XHTML to HTML back to

  • 0

I’m working on a project where we went from XHTML to HTML back to XHTML and there are some definite behavioral changes going back with regards to the page rendering before the CSS loads and scripts that read styles reading them before the CSS loads. Can anyone shed some light on why the following is happening and what can be done about it?

Basically, I have a page with the following structure:

<body>
    <!-- Content from Source A -->
    <link href="http://a.example.com/style.css" />
    <header>...</header>

    <!-- Content from Source B -->
    <link href="http://b.example.com/style.css" />
    <div>...</div>

    <!-- Content from Source A -->
    <footer>...</footer>
    <script src="http://a.example.com/script.js">
        /* e.g. */
        alert($('header').offset().height);
    </script>
</body>

When we were in HTML rendering mode, the page blocks rendering at expected points. When we hit the Source A CSS, rendering pauses (blank screen); when we hit the Source B CSS, rendering pauses (header is visible). When we hit the Source A JavaScript, rendering pauses (full page shown) and the script reads element styles from their rendered state. (In reality, of course, WebKit doesn’t stop parsing the DOM or executing JavaScript while the CSS loads, but it does halt execution at the first point where the script needs to read a style.)

When we are in XHTML mode, the page doesn’t halt rendering at all and will render the entire page completely unstyled. After that, it appears to process the scripts and stylesheets in the order loaded, or rather it executes the scripts in order but doesn’t wait for the stylesheet to load before executing a loaded script. This means that the page will render three times (unformatted, with one stylesheet, and with two stylesheets) and the script may infer completely inaccurate values for element sizes.

Can someone shed light on this? This is happening in all WebKit browsers I’ve tested, including Chrome 17, Mobile Safari 5, and Android Browser 2.1. Is there any way to ensure HTML render ordering without resorting to the text/html mime type?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    WebKit uses libxml2 to handle XML, which sends the parsed XHTML back to WebCore and JavaScriptCore to do the CSS rendering and JavaScript execution.

    Webkit Architecture

    Stylesheet and script tags link to what’s called an external entity in XML terminology. That means they are processed last. The XML spec says:

    Except when standalone=”yes”, they must not process entity declarations or attribute-list declarations encountered after a reference to a parameter entity that is not read, since the entity may have contained overriding declarations; when standalone=”yes”, processors must process these declarations.

    Since standalone="yes" specifies that the XML document should be validated by a DTD, this triggers a different processing model.

    Link tags are handled differently than xml-stylesheet processing-instructions. The XML stylesheet spec says:

    Any links to style sheets that are specified externally to the document (e.g. Link headers in some versions of HTTP [RFC2068]) are considered to create associations that occur before the associations specified by the xml-stylesheet processing instructions. The application is responsible for taking all associations and determining how, if at all, their order affects its processing.

    Try commenting out the script tags and converting the link tags xml-stylesheet instructions. Also, try adding standalone=”yes” to the XML declaration:

    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<?xml-stylesheet href="foo.css"?>

    In addition, the use of special characters, entities, and XSLT can further complicate the picture, since the processing model differs between HTML and an XML dialect like XHTML:

    The range of allowed chars in XML is defined by the XML spec, and
    the range is fully checked by libxml2. Not a concern, unless you parse
    this for example with an HTML parser and give the preparsed tree to
    libxml2 to serialize back. I hope you’re not doing this as XSLT is
    an XML language and must be parsed by an XML parser.

    XSLT Processing Model
    References

    • 0