Time to ditch CSS? What are the problems with this alternative?

CSS, in my opinion, has always been an awful system for laying out pages... almost absurdly so. There are so many aspects of the specification that simply do not make any sense (like how vertical padding and margin are relative to the width of the parent... what?), to the point that every time I try and use CSS I begin to question the sobriety of whoever came up with it. Almost anything you try and accomplish using CSS requires some sort of workaround involving nested divs, and ultimately you have to resort to javascript for certain features. Add to this the fact that it is implemented inconsistently across browsers, and that each browser requires some prefix for css properties (which means almost any of the new CSS3 features have to be written 3-4 times) and the result is a giant mess.

So I decided to try a little experiment. Since I end up using javascript anyway to accomplish most layouts, I thought I might be better off ditching CSS altogether, at least for page structuring. I wrote a javascript library which parses layouts specified in XML files, and applies them to an HTML document using absolutely positioned and sized, non-nested divs. So the idea is that each page has an HTML file containing all content, an XML file specifying how that content should be arranged on the page, and a CSS style sheet used only for superficial styling (colors, fonts, etc).

here are a few examples (tested in the latest version of all the major browsers):Example 1Example 2
In the first example, press the button to inflate the layout. Resize the window to see the responsiveness of the system. The second example demonstrates top-down stacking with height of the stack being minimized, and the yellow boxes fill available height in the stack.

The way I see it, internet/computer speeds are fast enough these days that if you can specify a layout system that works exactly how you want it to, and will render the same way across all platforms, in under 50kb, why not? Why remain a slave to the major browsers ability to implement a system that was poorly designed in the first place?

The most powerful part of this system is that anytime I want a new feature, I can simply implement it myself: I don't need to wait for the next CSS spec. And so far, in addition to designing my spec in a way that actually makes sense, I've added some very useful features not found reliably in CSS, such as:

The ability to easily align any element (including text) inside any other element, top/center/bottom, left/center/right.

The ability to float elements inside a parent from the left, right, top, or bottom. Furthermore the ability to stack the elements into the smallest possible space

The ability to set an element to fill remaining space in the parent, or split the space evenly with other filling elements.

When setting widths/heights in percentages, the ability to specify percent of width, height, or of the smallest dimension (%w, %h, %s), allowing easy creation of square elements.

The ability to easily set elements to be spaced apart evenly.EDIT: One other feature is the ability to expand or shrink a container by certain number of pixels, which is useful for relatively sized elements. So you could for example create a container that is 100% of the parent size, but specify a shrink of 50px for any or all edges.

Finally, the system is accessible and degrades gracefully such that if javascript is disabled, the user will still have access to all of the content.

So what are your thoughts on this method. What are the possible pitfalls? Documentation for all of the features, as well as the source code is on github .

I may say more after I get some sleep, but I'll make a few points now.

Have you considered performance and mobile devices?

If the prefixed properties annoy you, use a CSS preprocessor, like LESS or Sass. Prefixed properties were created to allow work on the CSS3 specifications to go as fast as possible. They are not a perfect solution and alternatives continue to be discussed, but they are important to aiding progress.

I have tested a few samples on my mobile device, a bottom-of-the-line android device. There have been no perceivable differences in render time between my javascript-only layout engine and native CSS layouts in any of my tests. And if the differences in performance are not perceivable, then i'm not too worried about them.

I have heard of flexbox, but my understanding is that its features cannot be reliably utilized, as the spec is not supported by all browsers. Furthermore, the way I see it, this will always be the case. There will always be a new spec to solve the problems of the old one, and it will always take way too long to be implemented by all browsers. By using my own javascript-only layout engine, I ensure that my pages always render equally for all users, regardless of browser or platform.

As for the CSS preprocessors and the percentage padding technique: yes, they work to solve certain problems with CSS. But like I said, almost anything you try and accomplish using CSS requires some sort of workaround. These types of solutions are the wrong approach in my view, because they are built on a system that is faulty in the first place. It is much more attractive to me to start with a rock-solid foundation--a layout engine that makes absolute, logical sense--than to keep finding these types of workarounds (however clever they may be) to try and trick CSS into behaving the way we all expect it to.

Have you tried building the complex home page from one of the more popular sites on the web, e.g. Amazon.com? Have you tried testing with it deployed on a server geographically remote from you?

I have heard of flexbox, but my understanding is that its features cannot be reliably utilized, as the spec is not supported by all browsers.

I figured you'd notice that which is why I didn't mention it. Yes, IE9 and older do not support it and some older versions of Firefox implemented an older version of that specification.

Furthermore, the way I see it, this will always be the case. There will always be a new spec to solve the problems of the old one, and it will always take way too long to be implemented by all browsers.

Standards take time to write and test before they are finalized. Browsers are getting faster at implementing things. Even Microsoft has been developing IE steadily for a while now after they stopped for many years once they had released IE6.

There are so many aspects of the specification that simply do not make any sense (like how vertical padding and margin are relative to the width of the parent... what?)

My hypothesis for the reason for that is that heights are so often left as auto (which is a good thing) that it would be a problem if the vertical margins and padding (with percentage values) could not be calculated until the height of the element was known, which is especially a problem when all of its content has not finished loading.

@Kravvitz No, I have yet to try a test on the scale of the amazon homepage. As I continue to refine the engine, I will also continue to produce more complex examples. That said, I simply do not anticipate real performance issues for any reasonable webpage based on my tests thus far. Each container requires requires one width, height, x-offset, and y-offset calculation, which I would say average to around 5 basic arithmetic operations each, as the code is optimized such that each container will only perform these 4 calculations only once per render cycle. I have not tried testing from a remote server... what issues do you envision would arise from this?

@Paul-Ninja It's true that my examples use inline styling applied via javascript. Even so, I would say that there is still separation of style and content for all practical purposes. Because the document that contains the content contains no styling data, it would still be easy to change the style and structure without altering the content document. Furthermore, the inline styling will not negatively impact a screen reader (by my understanding) because the divs remain non-nested, and in logical order.

But even if I'm wrong about that, the style could still be applied using classes via the 'class' attribute in the XML document if you wanted to.