In short, this question is about the cross-browser-compatibility-ness of a way to serve a HTML page as XML. I am interested in serving a web page as XML to be interpreted as HTML for increased CSS performance by removing the user agent style sheet. The reason for this concern will not be explained as it already has caused this question to go sideways. I found this webpage containing what I was looking for: a way to disable the user agent stylesheet. Except, that web page failed to give anything regarding browser compatibility. SO here are my questions about this.

  • That XML webpage (same as the one above) appears to successfully disable the user stylesheet by making the browser load an XML file as if it were a web page. What is the common term that describes what this web page is doing is called (a word(s) that could be used in a Google search to learn more about it)?
  • What is the browser compatibility (which web browsers will load the page correctly) for loading webpages in this way without the user agent stylesheet? Also, what about javascript? Will the behavior of Javascript in pages like this stay consistent across browsers? So far, the differences I have found (using javascript executed in the dev console)between Javascript in normal pages, and javascript in this page to be the following (in Chrome).

    • By default, all elements will have Element as their constructor. This causes (among other things):
      • onmoveover, onmouseout, onclick, and other mouse events are undefined. Instead, addeventlistener must be used.
      • document.body to be null.
      • offsetparent to be undefined.
      • clienttop and clientleft to be undefined.
    • document.doctype to be null.
    • The documents constructor to be XMLDocument

    Are there any other differences in javascript? How does the behavior of javascript differ from browser to browser?

I do not want to rant, but at the same time I do not want my answer to be falsely marked as off question. So, I will share this one bit of my attempted reasearch on it. After hours of searching, I found what is called XSLT. However, it doesn't appear to be what I'm looking for because in the demo pages of XSLT I found, I saw that the user agent stylesheet was still being applied.

  • We could have done without all of the meta commentary. – Robert Harvey Jul 7 '17 at 22:42
  • 1
    @RobertHarvey I don't know the common name that what I am asking is called, and it sounds very similar to what my research turn up, but was inconclusive about: XSLT. So its very hard to describe it concisely enough for the discussion not to go sideways, or being accidentally marked as a duplicate of XSLT. – Jack Giffin Jul 7 '17 at 22:53

You're doing premature optimization.

Although, the question you linked claims that:

I know that I can override it by CSS, but that creates lots of overriden specifications, and that seems to highly affect the CPU usage when browsing the page.

[...]

It is a single static page with several hundred hidden <li> items that alternatively become displayed with a click of a button powered by Javascript. I comfirmed that the Javascript part is not using up the CPU much.

[...]

I am using Google Chrome CPU profiler and timeline for the particular page.

and is slightly more elaborate than the usual “I believe that here's the bottleneck, although I haven't profiled anything yet,” it may happen that:

  • The person asking the original question had a flaw in the measurements,
  • The person claimed he profiled the thing, but haven't really done anything,
  • There was a bug in the version of Chrome from 2012,
  • There was something very specific on the page, aside several hundred hidden list elements.

If it was a real performance analysis, I would expect the question to contain:

  • The detailed information about the experiment being done. What was measured? How? In which context? On which machines? Which operating system was used? Were the machines doing anything else?

  • The source code, allowing the test to be performed independently.

  • The actual measures.

  • A comparison between between the page where default style was reset with the same page where default style was kept intact.

  • A conclusion, such as: “Based on the collected data (see above), it appears that default style override caused additional 82 ms. on tested machines, which represents an average of 19% of the load time.”

Since the original question cannot be used as a relevant benchmark, you're only supposing that:

on this website normally microscopic increases in CSS performance will be bloated out to noticeable macroscopic jumps in performance.

and that CSS reset stylesheet would be the bottleneck. Let's see.

Macroscopic jumps in performance

I am creating a project-oriented website where users can create projects with millions of items (DOM nodes)

The fact that today's browsers are very capable of rendering a lot of stuff doesn't mean that you should cram a lot of stuff on a page. From design's perspective, this simply doesn't make sense.

Imagine looking at a million elements at once. A million numbers. A million images. A million words. Whatever. How does it look like? By comparison, a 1920×1080 monitor contains 2073600 pixels. Those are pixels, not data elements. Not words or numbers, or even chart points.

The fact is that if you're showing a few thousands of data elements, in order to be usable, those elements should be presented in specific forms, such as images or charts. This means that each of those elements won't have any DOM node, because you'll be using a canvas. For anything else, the number of elements which would be visible for a user would decrease to a few hundreds.

Of course, there are sometimes more DOM nodes than there are data elements displayed on a page. But having millions of DOM nodes? I don't believe it.

What about the scroll?

Indeed, pages do get scrolled up and down, which means that they sometimes contain more elements than the user has to see at once.

Note that while very long pages (long in terms of vertical scrolling) are usually less responsive, the relation between performance and number of DOM nodes on a page is not exactly linear. Browsers are smart enough to focus on the content which has to be displayed to the user, and do slightly less work for content which is not visible.

Nevertheless, you can get yourself in a situation where there is a huge amount of information to display on a single page. Luckily, there are two examples where this problem was successfully solved: Google Maps and Google's PDF viewer.

With Google Maps, the browser displays the content which is visible, and discards the content which is not. This has a benefit and a drawback. The benefit is that you can run Google Maps on a machine which has less than a few terabytes of memory. The drawback is that when you move from one location to another, the application should occasionally reload the data it discarded a few minutes ago.

With Google's PDF viewer, the approach is very similar. The entire PDF is rendered as a bunch of images and text, all using position="absolute". Every time you scroll the page, the app recomputes what should or should not be shown, and manually adjusts the top and left position of the elements. This makes it possible to effectively handle millions of DOM elements while ensuring outstanding responsiveness.

CSS impact

Still, for any large website with rich content, it would be wise to take a look at CSS impact, and once you've used a CDN, properly minified your static resources and implemented proper client-side caching mechanisms, there would be possibly a few CSS optimizations.

In general, those optimizations focus on:

  • The number of styles,
  • The number of elements targeted by a selector,
  • The complexity of selectors.

And, indeed, you may notice that CSS reset stylesheets are among the ones you may want to optimize, since they contain a bunch of * { ... }.

Once you find that those selectors are an actual bottleneck of your entire application, you work on the selectors to either remove them when possible, or make them more specific. In both cases, it generally consists of a trade-off between performance and consistency and backwards compatibility. In other words, you may decide that it's not that important to have a consistent space between two elements between Chrome and Safari, or that you don't really care that one particular area of the web app is displayed incorrectly in Internet Explorer 9.

This is basically how it works.

  • Thank you so incredibly much for your brilliant, thoughtful, well rounded, unbiased answer. However, I regret having to inform you that you misunderstood the question. My question has nothing to do with that SO post except that link in the SO post. I am basing the increase in performance upon the dev-tools that tell me that the user-agent-style sheet is not present. And, the question is not about a discussion behind my purposes and intents, rather its about cross-browser compatibility. – Jack Giffin Jul 9 '17 at 22:13
  • @lolzerywowzery Using XML as an approach to either performance, or cross browser compatibility is extremely misguided. – TheCatWhisperer Jul 10 '17 at 13:42
  • 1
    Also, you claim your question is about cross browser compatibility, but it mostly mentions performance; so I understand why this answer would focus on performance. – TheCatWhisperer Jul 10 '17 at 13:45
  • @TheCatWhisperer Thank you for expressing your concerns over the aim of the question. I hope I have mended the situation with the changes I have made to the question. – Jack Giffin Jul 10 '17 at 17:09
  • 1
    @lolzerywowzery: I think it's an XY problem, and your recent edits to the question don't make my answer irrelevant. What happens is that you're asking for a technical solution to solve a problem which, in the current form of your question, is unclear. It also happens that your original question made the problem explicit: your concern is performance. Thus, my answer was intentionally focused on that specific concern. – Arseni Mourzenko Jul 10 '17 at 17:34
up vote 0 down vote accepted

How To Make A XHTML Page

To answer the question, everything about the linked page is off-bat. There is nothing cross-browser about it (though it does work fine in most browsers coincidentally). Expect change and decreasing browser support. A much better way to go is XHTML. XHTML is XML parsed as HTML which is exactly what you are looking for. XHTML has none of the unique HTML features that prohibit performance and produce strange error-prone parsing behaviors. Do the following steps to get an XHTML template page from which you can work off.

  1. Begin the XHTML page with <?xml version="1.0" encoding="UTF-8"?>
  2. Next, follow with <!DOCTYPE html> (this is case-sensitive in XHTML)
  3. In the <head>, you must then add <meta http-equiv="Content-Type" content="application/xhtml+xml;charset=UTF-8" /> to reaffirm that this is XHTML (silly, right?)
  4. Because the XHTML spec demands it, you should also put a <title>Title Of The Webpage</title> tag somewhere in the <head>. If you do not want a title for your webpage, then put <title></title> in your <head>.
  5. Make sure Content-Type: application/xhtml+xml is in the headers served with this webpage. If you do not know what this means then read the following. First, I would try putting a .xhtml extension on the webpage and seeing if your server already has a MIME type for XHTML. If that fails, then check if your server supports PHP. If your server supports PHP, then an incredibly crude, awful, and abusive (but still 100% working) way to get XHTML is to put <?php header("Content-Type", "application/xhtml+xml"); ?>at the very very very absolute top of your file before everything else (even before the <?xml version="1.0" encoding="UTF-8"?>). If all else fails, then try changing the file extension to .xml. I know that (in chrome at least) xml files will get interpreted as XHTML files if done exactly correctly without a single flaw in steps 1-4.

Your resulting XHTML web page code should something like the following. (Special note to avoid a particular splitting headache: Microsoft browsers only scan ~4kb into the file for <meta http-equiv="X-UA-Compatible" content="IE=Edge" />. Do not place this tag down too far down the page or you will be sorry).

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
    <head>
        <meta http-equiv="Content-Type" content="application/xhtml+xml;charset=UTF-8" />
        <title>Title Of The Webpage</title>
        <meta http-equiv="X-UA-Compatible" content="IE=Edge" />
    </head>
    <body>
        The body content goes here
    </body>
</html>


Some quirks about XHTML

There are some very notable differences between XHTML and loose HTML. These differences contribute to why XHTML is so much faster to parse, and why it is (for me at least) so much better for development in some cases, but not others.

  • Tags are written differently: <script defer src="..."> is invalid. Instead, you must do <script defer="" src="..."></script>.
    1. All tags must be closed.
    2. All attributes must have values. To create a blank attribute, set its value to "" like so: <iframe sandbox=""></iframe>.
    3. All tags in XHTML are allowed to be self closing (e.g. <tag /> as a 100% interchangeable shorthand for <tag></tag>). However, to maintain compatibility with horrible web browsers (*cough*: IE) that don't understand XHTML and render the page in HTML, you must only self-close tags that would be recognized in HTML as being self closing. From what I have observed, the following can be self closed: <meta />, <img />, <br />, <link />, <input />, and <hr />. However, the following oddballs (that ideally would be able to be self closed) must never be self closing: <td></td>, <th></th>, <script src="..."></script>, <title></title>, and <canvas></canvas>.
    4. (Most) HTML minifiers will completely break a XHTML page. Their output will be valid HTML, but not valid XHTML. So, watch out and be careful.
    5. In XHTML, there can never be duplicate attributes. For example, the HTML tag <div style="color:red" style="font-weight:bold">AnonyCo</div> will make AnonyCo both red and bold. But, in XHTML, this tag will produce a syntax error. In XHTML, the tag <div style="color:red;font-weight:bold">AnonyCo</div> must be used. This can be quite useful for development because the browser basically points out to you "Hey! This is bad practice" for free.
    6. HTML completely ignores custom namespaces, but XHTML does not. Be aware that "cute" code like <email:example>admin<i>@example.com</i></email:example> will produce different behavior in XHTML than in HTML. In HTML, "@example.com" will be italicised, whereas in XHTML "@example.com" will not be italicised. However, if we were to do <email:example xmlns="http://www.w3.org/1999/xhtml">admin<i>@example.com</i> or <div xmlns:email="http://www.w3.org/1999/xhtml"><email:example>admin<i>@example.com</i></email:example></div> in XHTML, then "@example.com" should become italicised according to the specs. However, here lies a hidden quirk: I have never thus far actually seen custom namespaces used in production code (aside from the links at the top of the page), so expect both browser support and browser behavior to be both browser dependent and very likely subject to depreciation. Moreover, I have not yet been able to come up with a single good realistic use for custom namespaces. Moreoversomemore, browsers that do support custom namespaces likely perform poorly when fed custom namespaces because the custom namespaces were likely an after-thought for spec-conformance, not something mainstream that has been heavily optimized.
  • Javascript behavior differs a little (in a very good way)
    1. Let us assume we did the following:
      <button id="myWTFPR_Button">Click Here To Get Your Mind Blow</button>
      <script>myWTFPR_Button.onclick = function(){alert("And bam!")}</script>
      That should fail, right? WRONG! To preserve compatibility with websites from the 90's, at every tag which has an id-attribute, the browser wickedly creates a new window property at window[id] and sets the value of this window property to the element. WHAT THE FUCKING PERFORMANCE RAMIFICATIONS?!?!?!? (Sorry, I just had to say that. Good lord does this infuriate me!) Thankfully, this does not happen in XHTML. In XHTML, the code snippet above would ever so wonderfully fail because ID's of parsed tags do not become window properties.
    2. Yay! At least one good refusal to downgrade in XHTML. (Suprise, suprise, suprise!) XHTML documents actually allow you to do document.createElement("div") and it will work as you would hope (but not expect) it to work. There is no need to do the crazy B.S. one might think XHTML would demand like document.createElementNS("http://www.w3.org/1999/xhtml", "div").
    3. In loose HTML, creating HTML content directly in the document via javascript (e.g. with .innerHTML, .outerHTML, and .insertAdjcentHTML(...)) will never throw an error no matter what. In XHTML, creating HTML from a text string will throw an error if the content to be created is not valid XML/XHTML. Make sure to wrap your code dealing with HTML creation in HTML brackets. Also be careful when developing with a framework like ReactJS where the error may become obscured/hidden and break the entire page suddenly.
  • Page rendering is different in XHTML.
    1. If there is an error in the XHTML, then the browser will display a <parsererror> element at the top of the body followed by a rendering of the page up to where the error occured.
    2. XHTML does not recognize <noscript>...</noscript> tags. Instead, XHTML treats <noscript>...</noscript> exactly the same as it would treat a <span>...</span>. Thus, if Javascript is enabled and a page is XHTML, then the contents of <noscript>...</noscript> tags will be displayed to the user despite the fact that javascript is enabled. Although, do not worry too much. From what I have seen, yes: <canvas>Oh poo! Canvas is not supported again</canvas> and <iframe>Sorry, but your browser is a piece of bulls***</iframe> do work properly in XHTML pages, hiding your secret cursing at broken old browsers from the eyes of common people.
  • XHTML v.s. HTML
    1. Honestly, there are very few reasons for why not to switch to XHTML since (if for no other reason then because) XHTML is parsed several times faster than HTML because there is no back up and figure out where this tag ends, there is no wildly varying behavior between the various tags, and ID's do not get assigned as window properties, speeding up the Javascript start up and execution immensely.
    2. XHTML may be much saner than HTML, but (to maintain compatibility with non-XHTML-conformant browsers), one must design their XHTML webpage to be backwards compatible with bad old loose HTML.

You are not approaching the problem correctly. You need to focus on mastering the tools and technologies available to you before attempting to reinvent/circumvent them. If any thing, your XML approach will make things worse, not better; web browsers are made to display html.

Most html browser compatibility problems are due to developers trying to work against html instead of with it. Master the uses of each element type, and do things by the book, and most of your compatibility problems will not be an issue.

Similar things can be said of javascript. Also, use a framework such as jquery, it is specifically made to get around browser compatibility issues.

For the different user agent styles, you should be using a css reset framwork. They are specifically designed to address styling differences between browsers. Additionally, limit yourself to a css framework like bootstrap, use its classes.

Additionally, a previous revision of your question suggests to me, that you have not made a clean separation of display concerns and logic concerns within your mind. I fear that you may be trying make you page pull double duty; both being the expression and display of your client "nodes". This is a very bad idea; and in the long run will cost you significantly more time than it saves you.

If you want to store the nodes as XML, this is fine (though I am certain there are better options), do not try to display them this way as well. Your application's job is to translate storage to a logical entity to a way of displaying it (html). These are three separate concerns and must not be convoluted.

  • Thank you so incredibly much for your brilliant, thoughtful, well rounded, unbiased answer. However, you fail to cite any sources. The reason I came to SE to ask this question was so that I wouldn't have to rely on intuition and reasoning, instead having some evidence one way or the other. So, if you can find some evidence (some sources) written by people who either have tangible evidence or programmed a web browser, then I will gladly upvote your answer and checkmark it as solved. – Jack Giffin Jul 10 '17 at 23:31

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.