CSS or just MESS?

Posted on by c-smile

I believe that CSS (Cascading Style Sheets) in its development has reached some point that could be classified as a mess.
I suspect that quantity of features has changed the quality of the whole foundation. And not exactly in good direction.

Look, CSS used to have simple and regular construction:

selector 
{
  attribute1: value[s];
  attribute2: value[s];
  ...
}

Pretty neat and clear if you would ask me. Simple list of name:value pairs separated by ‘;’ and enclosed by ‘{‘,’}’ brackets.

At some point people decided to add media-queries that required new level of block containment:

@media <media-expr> {
   selector {
     attribute1: value[s];
    ...
   }
}

which is not that bad – still manageable by some tools like ANTLR parser generator.

But please note that media-expr above. It has its own micro-format with AND, OR and peculiar ONLY operators. Even media-expression specific length units… But no arithmetic operations there. Hmm, wait, there are arithmetic operations in CSS now! In the calc() function. But there are no AND, OR and friends in this place.

So we have at least two places in CSS where expressions are used but with different notations.
Seems like as different strangers passed by this X-Mas tree and have left their own decoration on it.

CSS design principle fig

And those lists in CSS …

First of all I do not know any other language but CSS that uses space (‘ ‘) as an operator. Space here is a) token delimeter and b) an operator that glues two tokens into a list. So value of the attribute border: 1px solid red; is a list of three values ‘1px’, ‘solid’ and ‘red’. That is again fine. We can live with this.
But here another stranger passes by our tree who needed e.g. list of fonts. So one list should contain another one. In good mood that stranger would introduce brackets and write something like this:

font: 12pt (Arial Verdana sans-serif)

But sudden voice from the Heaven: “brackets and other programming stuff are not for CSS – John the Web Designer will not get them”. So our stranger decided to add ‘,’ (comma) as another list-gluing-operator. And we’ve got this: 

font: 12pt Arial, Verdana, sans-serif;

Note that comma here is an operator of higher priority than space as Arial, Verdana, sans-serif here is a single value (list by itself) of <font-family> attribute.

Story continues…. Another girl was swinging around that tree and suddenly decided that ‘/’ (slash) would also look extremely cool as another list-gluing-operator of her own. And so, voila!, we have:

p { font: x-large/110% "New Century Schoolbook",serif }

.
with the hope that this in principle better comprehensible than something like font: (x-large 110%) ("New Century Schoolbook" serif).

Well, our beautiful in its ugliness CSS tree was standing this way for years. But now new people are singing Jingle Bells around it. New times – new ideas, e.g. of multiple backgrounds. So instead of single list of values defining various background attributes (like positions, repeat, url, color, etc) we will have list of list of values.

Yeah! So another list-gluing-operator is coming, right?

Nope. There are simply no characters left after 10 years of CSS development. So another creative approach was introduced – to reuse ‘,’ (comma) again but with the brand new meaning.

In the background we are getting this:

background: url(a.png) top left no-repeat,
            url(b.png) center / 100% 100% no-repeat,
            url(c.png) white;

Note that comma is a different operator here as its priority is less than space. That is clearly different from the ‘font’ attribute we saw above. And yet note that clever use of ‘/’ again …

Yes, it is just a mess. It is not possible to write a parser that will handle ‘font’ and ‘background’ by using the same code as e.g. ‘font’ and ‘background’ attributes are written in different languages.

If you think that this is over then no. Another creative team is entering the stage with the Wobble song:

@keyframes 'wobble' {
    0% { left: 100px;  }
    40% { left: 150px; }
    60% { left: 75px;  }
    100% { left: 100px;  }
  }

Yeah, why not? Indeed, values in place of name tokens are really nothing if to compare with those lists …

And while our party is going on there is another group of modest people is busy printing their own stuff on other side of the tree:

@page :first {
  color: green;
  @top-left {
    content: "foo";
    color: blue;
  }
  @top-right {
    content: "bar";
  }
}

At the moment CSS looks like a patch quilt where each tile uses its own language with distinct notation and grammar. Am I alone who think that this is a sign of bad language design [process]?

It appears that all successful programming and data definition languages were created by single persons or compact groups of like-minded people. Java, C/C++, Pascal, SQL, you name it. Is this mess because of CSS has no central author[ity] or why?

6 Replies to “CSS or just MESS?”

  1. Luckily TI’s product is not a web browser, nor anything that has to be web compliant. Actually I was thinking (again) the other day what “the ultimate” gui toolkit should look like. Sciter is almost there in my opinion and where I think it fails is the web complicity – it has too much of it – only wasting performance and wasting tags that could be otherwise used. In my opinion H-SMILE should be based on HTML/CSS, but only on the good points, only where it makes sense, because it is a well known syntax. But nobody is going to port their web portal to Sciter for offline use.

    The purpose is entirely different. The only place where HTML/CSS is actually needed is a help system or something similar that will display formatted text. All these many tags and inline stuff make little or no sense for application gui. It is all blocks and layout-ing these blocks. Maybe there should be something like a single element that support HTML formatted text and images. HTMLayout is layout defined with HTML-like syntax, not HTML page, because it is not a page. So display: block, blocks-inside for the win :). IMHO it is much more important to have some drawing definition language (you mentioned it once). Something that can easily handle many layered drawing operations and animation. This could change how things are done in a great way. Then one wouldn’t need to stack elements one upon the other to simulate layers and stuff. One would just need blocks and the right layout. Then CSS selectors combined with some drawing rules can do the rest. I see no reason why H-SMILE should follow behind w3 rules. I don’t do lot of web programming recently, but I feel seriously retarded when I need to go back to CSS and Javascript DOM and all that browsers provide. It is plain stupid thing compatible with something made 10 years ago meant for displaying text…

    My point is H-SMILE is more than enough web compatible. It is not embedded browser. Trying to follow new web standards (if they are not particularly useful) is going back IMHO.

  2. Yep, I am with you, Borislav.

    But what about HTML5 ( http://www.w3.org/TR/html5/ ) ?

    “In this version, new features are introduced to help Web application authors, new elements are introduced based on research into prevailing authoring practices”

    HTML5 is targeted towards applications – not just to support of formatted text, HTML4 was good enough on that, IMHO.
    So presumably HTML5 should help? But that is just a markup language at the end …

  3. HTML5 may help web applications, but don’t forget these [web] people are stuck with what the least common denominator (i.e. IE) has to offer. Even if this was not the case they are pretty stuck. I mean all they have is javascript/html. They can’t extend the browser. They need to consider how google crawler works. They often need to consider how the web server works. So they kind of need this standards otherwise it becomes a mess. We on the other hand are not writing web application. Even if we are, we are not executing them in the browser, but in our own client (based on HTMLayout/Sciter) over which we have infinite (well almost) control. So my point is HTML is a nice readable way to define layout. CSS is a nice readable way to define some visual properties of this layout. They both are a good way to appeal to wider audience and make it easier for them to get started. That’s about it. I don’t know if all the HTMLayout users have the same opinion as me, but I like to do my own stuff. You see at first I was trying to stick to my web programming habits while using HTMLayout, then I realized I don’t need to stick to retarded habits because this is never going to be a web application but a desktop one and I have much more power at my fingertips. It is my own thing and I don’t need to make it compatible with IE or old server software or google or whatever. So it is good to have some web compatibility to get started. Later it is good to be able to get rid of all that and do your own stuff the way you like. Right now I use master css from scratch and all kinds of custom tags to do various things, so my html editor thinks all my tags are wrong and displays them in ‘wrong tag’ color. But it suits my logic and likings. In fact I want to get rid of as much builtin/web standard stuff as possible to get maximum performance and maximum ‘the way I like it’ markup. For example – why on earth would anyone want to write ‘html’,’head’ and ‘body’ tags in a desktop application? They are completely useless (unless they do some good to internal h-smile workings which I’m unaware of). You just need to include your styles/scripts/tag definitions at the top of the document. There is no ‘title’,’meta’ or whatever. Even if there is you will have your own way of processing it. If you like these in a head tag – fine – define your own head tag and put them in it. It takes only few lines… The list of examples goes on. There is a lot that can be done to aid applications (applications as opposed to pages). But my opinion is that this should be more in the form of libraries/modules. The host should be very basic, but extremely fast and [easily] customizable.

  4. Agreed. No language should ever work like that, but I don’t think it is beyond repair yet. It is possible to unify the representation of lists without breaking backwards compatibility, because there ARE a handful of characters that could be used without a problem. You could use {} or () for grouping. If John the Web Designer can understand the current system, but can’t comprehend grouping with curly braces, he must have something wrong with him.

    The thing about using {} to fix this is that it doesn’t conflict with existing syntax. Currently, nothing uses {} in a single style. (Though it looks like wobble is trying to kill this option too?) I’m not sure how existing parsers will feel about it, but if they follow the standard about ignoring things they don’t understand, I think they should be fine, right?

    You’ve participated in CSS development a lot in the past. Any chance you could convince folks to fix this before it’s too late?

  5. To bobef about HTML5. Standartization is a good thing for the Web of course.

    But let’s compare:

    http://dev.w3.org/html5/markup/ (circa 2009) and
    http://www.w3.org/TR/html4/ (circa 1998)

    not that much I would say. To wait 10 years for things like <input type=datetime> is simply not acceptable. Better than nothing of course.

    I strongly believe that the whole principle of such development is plainly wrong.

    The golden age of web technologies development was the time when browsers were fighting for the market by adding features. IE5 and IE6 added a lot to what we have now. E.g. main thing behind AJAX http://en.wikipedia.org/wiki/XMLHttpRequest#History_and_support was added by guerilla methods of Outlook Web Access team (OWA is the best online email application IMO).

    This time Google is pushing new features under the umbrella of HTML5. Pretty much in the same way. I remember it was an even an attempt make SQLite specification as a part of HTML5. No objections to the SQLite per se but in HTML? All this smells not so good.

    I would rather to see minimal specification (HTML4 was pretty solid spec IMO) but with extensibility mechanism. Just allow to specify something like this:

    input[type=datetime] { behavior: datetime; }

    With the ability to hookup your own script based implementation if your browser does not support ‘datetime’.

    You can put separate spec for things like ‘datetime’. It will be significantly better as we can update specs for behaviors after month of public discussion or so. But not another 10 years …

    And about `<html>`,`<head>`, etc. tags in Sciter. ( BTW: they are optional in html 🙂

    In principle I can add support of ‘root’ value to the display-model model attribute so you can define something like:

    window 
{ 
  display: block; 
  display-model: root; 
}

    and so your markup may look like: 

    <window>
 <title>..</title>
 <content> </content>
</window>

    nothing difficult. If it matters.

  6. It is funny. I agree IE5/6 made a lot of difference. Plus they could be used for desktop applications. At the time they were so ahead of everything else. On other hand IE6 was holding back web development for years.

    In principle I can add support of ‘root’ value to the display-model model attribute so you can define something like:

    It would look better IMO, but it doesn’t matter much. It was just a thing that came to my mind.

Comments are closed.