

The fundamental problems with CSS3 - bdfh42
http://mattwilcox.net/archive/entry/id/1031/

======
stillmotion
My biggest horror with all this new W3C tech, is that in reality: it's really
old. Because of Microsoft's stupid mistakes while reigning power over the
browser world, we've been in this 10 year period of stagnation in which we've
go nowhere.

There's no real laws you can put against Microsoft, but if this were a real
world situation, we'd be trying them for crimes against humanity. They have
effectively ceased innovation for an incredible amount of time, and I would go
ahead and say that they've slowed down the exceedingly fast development of the
last decade.

CSS3, Javascript 2, HTML 5, XHTML 2, etc. should've came out years ago.
Possibly in different forms, but nonetheless this monopolization over a
browser market has killed _everything_.

I am glad that Google is getting into this game. Not only because it will
definitely give Microsoft a run for its money, but we will finally have new
innovation that before seemed to take years to implement.

~~~
DLWormwood
> I would go ahead and say that they've slowed down the exceedingly fast
> development of the last decade.

As a fellow developer, I'm about a commit a heresy down to text:

"Most people don't want fast development."

People may claim they want change or for things to be "done with" in a timely
matter, but the reality is that change brings disruption in economic, social,
and political terms. Take a look at IP4, for example. IP6 just isn't getting
traction because the problems it solves have now become "features" to many
people. (NAT being one of the big ones, since it's gotten the perception of
being a security feature.) My job involves working with IE 6, since my
organization refuses to update our systems to even use IE 7, much less
standards-compliant stuff like Chrome or Firefox.

Simply put, if MS was sent to trial for "crimes against humanity," the jury of
"peers" who would to be selected would acquit them. Why? Because the court
would likely consider "peers" to be end users, business men or the ignorant,
not developers or technologists like us.

~~~
potatolicious
The removal of NAT, IMHO, is a major ache in the market. What used to be
purely an annoyance to developers and technologists has now become a serious
stumbling block for users.

The internet is no longer the download-from-website model that it was years
ago. There is a massive amount of user participation now, which is why upload
caps are increasing as services like video chat, peer-to-peer gaming, etc take
off.

And now you tell them only one person can initiate a video chat from behind a
single router. The user is annoyed. Or you tell them that you can't both be
playing the same game at once on two computers due to a port conflict.

IMHO there's a real need to get NAT out of our system, and there's a very real
consumer benefit to doing so. It directly opens doors to services and products
that people are _already_ clamoring for.

~~~
DLWormwood
Just for the record, I'm not a believer in NAT, but I have worked for people
who do, hence my using it as an example of a "feature."

------
halo
CSS does have its limitations, however I'm not convinced providing full DOM
manipulation is a good idea. I admit it does solve the problem and provide
greater flexibility, but the downside is that it'd be very quickly misused
with content and presentation becoming more tightly coupled as people start
using the convenient CSS DOM manipulation with dynamic pseudo-classes for
interactivity and removing many of the accessibility advantages that CSS has.
There's also very real unaddressed problems in terms of creating a readable
syntax, maintaining CSS code with injections all over the place and potential
browser rendering issues. To me, the cure seems worse than the disease, and
the Advanced Layout Module, despite its ugliness, is probably a better
solution.

CSS3 has gone a long way towards improving selectors, and I'll be the first to
admit calc is undoubtedly both necessary and long overdue. I'm not fussed
either way by CSS variables - I can see both sides of the coin.

~~~
neilk
Can accessibility really get any worse? Extremely few websites are accessible
today. If it weren't helpful for SEO, nobody would bother with it at all.

Can readability get any worse? Nobody really understands floats. This is a
layout language in which people regularly _boast_ about how they achieved
_three-column layouts_. Think about that for a second.

And if you look at the code that achieves said three-column layout, it is
impossible to tell what it does without comments. That's because CSS is
written out as a set of spring-loaded contraptions all interacting with each
other, meaningless without the "cascade" of DOM elements just so, and a
browser model just so. There's nothing like "three_column_layout(node, node,
node)".

As far as I can tell, your thesis is that because CSS is underpowered, this
will help us maintain accessibility. That's totally backwards! There will
always be requirements for complex layout and interaction. That part of the
job is not going away. So something's got to give. The artistic people go to
Flash, the scripting people just do it with tables, and the server-side
programmers go for some toolkit that pretends the browser is Java. Very very
few people have the sheer bloody-mindedness to do the right thing and learn
every last browser quirk and the so-called CSS model.

CSS is DEAD. It is not the basis for a better future.

~~~
halo
I'm going to break down the differences between my opinion and the original
articles and hopefully your opinion.

I admit CSS has its problems, and the core one is this: it's too complex to
create good designs, and it's too easy to hit a brick wall. We can all agree
on this.

The most fundamental things about CSS aren't a problem. The cascade is sane,
and is probably the best thing about CSS. It makes sense, it's fairly
intuitive and can be describe in a couple of sentences. For styling, aside
from the ugly non-JavaScript compatible syntax and the occasional unintuitive
property-name choice, we're in pretty good state generally.

The two biggest, and very real, problems are the unintuitive box model and
layout model. Everyone should agree with this.

I'll first deal with the relatively simply box model problem. The W3C box
model was incredibly poorly thought out and makes like incredibly and
unnecessarily difficult. It's simply inside-out. The width should refer to the
total width of the box as in IE4 and quirks mode: this makes things
wonderfully intuitive, makes things look as you expect and allows you to mix
different units with ease. As it is, it width refers to the inside of the box
and the real width is the inside width + border + padding. This is quite
obviously nuts. There are two fixes to this problem: a nastier backwards-
compatible one, and an actual nice solution. Both are in CSS3, and it gets
full marks from me here. The first fix is to provide a way of calculating
values so you can easily mix percentages with pixels. This is in CSS3 as the
calc function. The second fix is switching to the traditional sane box model.
In CSS3 there is a property to do this - add "box-sizing: border-box". So far,
CSS3 gets full marks from me.

The second core problem is layout. We currently have the "float model". I put
them in quotes because it's not so much a model as people meeting the
limitations of CSS2 but wanting many of the advantages of it and finding a way
around them using floats. Presumably when CSS2 because a recommendation in
1998 the web looked like a very different place, the limitations of the model
weren't considered a big problem, and then we were left in standards limbo
which left us for several years without a decent CSS2 implementation and no
table-replacing display: table implementation in the major browsers in sight.
And up until now the only usable, accessible CSS model we had was arguably
designed for something else entirely - the task of allowing text to flow
around images on normal layout pages. To say this dirty hack is lacking is
obvious an understatement, and that's excluding working around CSS bugs, but
I'd still argue it's the best thing we have and the accessibility advantages
and content seperation are worth the dirty hacks.

And so we have where we are today and our problem - how do we provide a good,
natural, way to make layouts?

And any answer to this leads us to the fundamental subquestion and finally to
where we started this discussion: how seperate do we want our content and
presentation to be?

This is actually a difficult, and slightly, ideological question. The more you
seperate content and presentation, complexity of both the spec and language
goes up, flexibility goes up, inherent accessibility goes down and so does
inherent maintainability. The "completely" solution results in DOM injection,
the "not completely" solution results in something nearer to the Advanced
Layout Module.

And this is where our fundmental differences clearly lie.

I believe that forcing a reasonable amount of semantic ordering within content
is a good idea as it helps encourage a certain amount of inherent
accessibility as content has to be ordered. I believe that any syntax that
would allow DOM injection would be inherently ugly syntax and not fit well
within CSS. I believe that any syntax would have to be very carefully chosen
to work at all. I believe that if you want ultimate control over the
appearence of the page, you always have JavaScript and jQuery at your
disposal.

And you, and the article, believe that the advantages of flexibility outweighs
my criticisms, and CSS would be underpowered without them.

\---

And to go back to your own post:

Accessibility can get worse, and CSS3 is looking like it will improve the
situation.

Readability can get worse - floats are a dirty hack especially when combined
with CSS hacks for dated browsers and as such inherently aren't readable, but
adding injection into the mix won't automatically make life better.

And yes, floats are a dirty hack and aren't an indicator of the future of CSS
either way.

CSS isn't really inherently underpowered: it depends how you see it. At the
moment it needs fixing either way

And CSS isn't dying at all, and CSS is going to be completely reborn over the
coming years. Flash is still dying - Flash was always a dirty hack. CSS's
display: table is going to replace with CSS as soon once IE7 dies in about 5
years. And CSS is getting better, compatability is improving and CSS3 is going
to better than CSS2 whatever it chooses: DOM injection or not.

------
cousin_it
It seems CSS is eagerly following C++ templates into the Turing tarpit. For an
alternative, I've heard good things about the TeX "boxes and glue" layout
model.

~~~
newt0311
It seems that anything that comes out of "standards bodies" ends up looking
like C++. Standards in general need to become simpler.

~~~
smanek
Common Lisp came out of ANSI, and I'd say it doesn't look like C++ ;-)

~~~
newt0311
Yes it does. It has at least 4 different ways to loop, 4 different types of
arguments to functions, 5 or 6 different lets (functions, macros, let* ,
normal let, ...), 3 or 4 different kinds of variables (with no unifying
underlying theme), and at least 3 different flow models (the nested lists,
tagbodies, loops with returns, etc...). That is exactly the same problem with
C++. Instead of finding unifying abstractions which give the same
functionality with 1 idea, they have chosen to add in multiple specific quick
fixes to the language. They have chosen to amend the language with a thousand
small changes, each suited to its own little use case, and have ended up with
a monster of a standard that takes up 15 megabytes in 2300 files with 110,000
hyperlinks. Thats 15 _mega_ bytes mostly of text.

Scheme is a lot better but its going the way of CL, slowly but surely.

~~~
jshen
aren't the 4 different types of arguments useful? I end up hacking it into my
ruby code because it's missing. Crap like

def my_meth(options = {}); options[:named_arg_1] ||= 'bob';
options[:named_arg_2] ||= 'blub' end

~~~
newt0311
To a limit. Admittedly, having different argument types is pretty useful but
still, _5_ independent parts with their own semantics some of which may not be
usable in certain contexts* ? how are auxiliary arguments useful in the
general case?

This still does not affect the rest of my claims. Having multiple execution
models in the same language is bloated. So are many other things in the CL
standard.

* Details: [http://www.lispworks.com/documentation/HyperSpec/Body/03_da....](http://www.lispworks.com/documentation/HyperSpec/Body/03_da.htm)

~~~
jshen
yeah, i wasn't trying to dispute your main claim, I just miss CLs argument
types when I'm in other languages so it jumped out at me.

------
etal
There are a lot of "what ifs" in the history of web tech, and considering this
article, JSSS (<http://en.wikipedia.org/wiki/JavaScript_Style_Sheets>) versus
CSS springs immediately to mind. Using Javascript for styling pages in 1996
may have sounded like needless complexity, but in retrospect it seems like it
would have been a much better choice. Whole-page layout deserves a true
programming language.

~~~
ambition
Separation of presentation from content is good, but presentation is a task of
arbitrary complexity and requires arbitrary computation (aka a full
programming language) to do properly.

Many current frameworks are inadvertently used to bring the power of a
programming language to presentation, but most of them don't seem to realize
it yet.

------
lacker
I think the fundamental problem is that the html/css/javascript/server stack
needs to get _simpler_. For some apps, you are best off abandoning html
entirely, and doing everything via javascript. Eventually we might be able to
unify client-side and server-side code with approaches like Google Web Toolkit
or YC's AppJet, but it is not quite simple enough yet.

~~~
jonnytran
Yes, the ability to write code once that runs on either your server or the
client is amazing, something Fog Creek implemented in Wasabi. But as
JavaScript matures, it makes you start to wonder why you even bother with HTML
at all; you can simply dynamically generate DOM nodes in JavaScript. And once
you start doing this, most of the things you wanted to do running code on both
client and server disappear.

~~~
jshen
"But as JavaScript matures, it makes you start to wonder why you even bother
with HTML at all; you can simply dynamically generate DOM nodes in
JavaScript."

SEO

~~~
jerf
Oh! So _that's_ why Google is developing a speedy JS interpreter... they want
to be able to see JS-based pages! They can load a page into a browser-with-no-
graphics, and give the JS a certain amount of time to run before freezing the
page and then reading off the DOM nodes instead of reading HTML. If they don't
like the results, they can just use the HTML like they used to.

(Reading off the DOM nodes also gives them a fresh crack at some more semantic
analysis that used to be really hard, since it involved emulating a browser...
did you use <span class="some_header"> instead of <h1>? They can make a better
heuristic guess at that if they are "inside" a browser and thus capable of
seeing that the size is twenty points higher than the surrounding text, no
matter how you implemented that.)

To really pull this off, you need a browser engine that enough people are
using that site designers need to account for it, and it needs to be designed
with the goal of running just the engine as quickly as possible on the
backend, with the ability to cut it off after a certain amount of time.

So... has anybody dug deeply enough into Chrome to have an opinion on the
feasibility of running the browser without a UI?

~~~
jshen
I'm not sure what your point is. Is your point that we shouldn't worry about
rendering pages with JS because someday in the future google will be able to
index it equally well?

If so your livelyhood clearly doesn't depend on SEO. I'm not gambling mine on
what is currently vaporware.

Btw, people made this exact point about flash a few years ago and your pages
will not rank nearly as well if you do them in flash.

~~~
jerf
I think my point was pretty adequately captured by "So that's why _Google_ is
developing a speedy JS interpreter", although I have done you the favor of re-
emphasizing the subject for you.

I don't care about SEO. I think _Google_ wants to see into those sites, and I
don't think they much care about SEO either.

~~~
jshen
I still don't see what your point is.

Something like, "google doesn't care about SEO therefore site s that do should
use javascript frameworks instead of static html" or something?

~~~
jerf
My point is not about you at all. If you can't see the value for Google of
seeing through Javascript, that's your problem, not mine or Google's.

~~~
jshen
hehe, well when you reply to my comment I assume that it is about my comment.
This is the whole point of threaded comments

------
johns
OT: The author's use of underline for emphasis is annoying. It looks like a
lot of links, but they're not. He should swap the styles of his links and
whatever he uses to emphasize text.

~~~
Herring
It would also be nice if we started writing abstracts for the lengthier & more
technical posts.

------
endergen
The problem is that Microsoft inversely gains from improving the ease of
browser development. The easier it becomes to develop software using open
source tools(No Visual studios) on an OS-independent platform(The web with
browsers) the less money they make.

Google's recent project (Native Client) is what I've been waiting for as a C++
developer. It basically allows you to run native code(assembler) in browser.
But then has security mechanism so that the code cannot do anything to the
client computer unless the user of that client has given the
container(Sandbox) that runs the code permission.

This will allow people to build their own UI frameworks, that render much more
rich graphics and hopefully behave the same no matter what Browser/OS
combination you are running on.

References:

Announcement:

[http://google-code-updates.blogspot.com/2008/12/native-
clien...](http://google-code-updates.blogspot.com/2008/12/native-client-
technology-for-running.html)

Native client code base hosted at Google code:

<http://code.google.com/p/nativeclient/>

Ars Technica review:

[http://arstechnica.com/news.ars/post/20081209-safer-than-
act...](http://arstechnica.com/news.ars/post/20081209-safer-than-activex-a-
look-at-googles-native-client-plugin.html)

Do people really think we'll ever reach a point where different vendors
building code-bases based on documentation built by a committee will ever
behave even remotely the same? Have you read any of the W3C documentation,
it's fucking ridiculous. We should be sharing implementations, it's the only
way to ensure bit-level identical behavior of a target system(Performance
characteristics aside).

I really hope Native Client takes off. In combination with Gears for client
side storage it would allow us to build desktop quality software but with the
web advantages of cross platform development, zero install applications(well
as long as you don't consider caching a form of installing), user's pulling
down the latest client at all times, and etc.

Awaiting our new Google overlords. Endergen

------
old-gregg
If we're talking about _fundamental_ problems, then the only fundamental
problem is that we're using document markup tools to build rich UIs, which is
super-retarded even comparing to early 90s VB6 era.

WTF is <p> or <ul> or <div> and all that crap? I haven't seen an HTML template
that looked comprehensible after a year in development.

What do they have to do with UI programming? What we really need is something
like MXML or XUL, only cleaned up and widely supported by all browsers,
especially IE9.

~~~
sjs382
<p> <div> <ul> don't have anything to do with UI.* They are document markup
elements. UI is applied to a document (html) via CSS (style) and JS
(behavior).

This is all pretty elementary for someone reading this site... Maybe I missed
some sarcasm? :p

*Well, they do in a lot of instances, but when properly used, they have nothing to do with UI.

~~~
fauigerzigerk
Yes that's the dogma. Alas, it's completely lost on me. I fail to understand
how tables are more "semantic" than nested divs. Tables only have semantics
within the context of some formalism that defines their semantic meaning.
Outside of such a context they can be anything, so why not a way of laying out
information on a page?

I don't see how swaths of divs, some of them used for semantics (according to
some metadata standard), some of them used for purely presentational purposes,
improve anything.

CSS people (or should I say modern web developers) are completely anal about
not using tables for layout whilst at the same time the whole notion of
document structure is so utterly destroyed in any JavaScript heavy app.

These priorities make no sense to me. Laying out web pages with divs and CSS
is a black art. It's fragile. It breaks in all kinds of nasty ways. It reduces
the productivity of UI development to pre 90s levels and leads ot entire pages
done in Flash.

~~~
sjs382
"I fail to understand how tables are more "semantic" than nested divs. Tables
only have semantics within the context of some formalism that defines their
semantic meaning."

Tables are not more semantic than nested divs. But nested divs aren't very
semantic, either. Tables are used for tabular data. Divs are used for dividing
content.

"I don't see how swaths of divs, some of them used for semantics (according to
some metadata standard), some of them used for purely presentational purposes,
improve anything."

No one is proposing that you make every element a div. In the web standards
community, we call this "divitis" and while better than table-based layouts,
it still isn't semantic.

"CSS people are completely anal about not using tables for layout whilst at
the same time the whole notion of document structure is so utterly destroyed
in any JavaScript heavy app."

Don't lump these developers (who's code doesn't gracefully degrade for non-
JavaScript users0 together with the rest of us.

"These priorities make no sense to me. Laying out web pages with divs and CSS
is a black art. It's fragile. It breaks in all kinds of nasty ways."

Just because you don't understand how to make something work doesn't mean it's
a "black art". Plenty of web developers are able to create semantically-
meaningful documents styled (cross-browser) with CSS. CSS offers advantages,
but you seem to only see (imaginary) disadvantages.

"It reduces the productivity of UI development to pre 90s levels and leads ot
entire pages done in Flash."

I'm not even sure how to respond to this. It's ridiculous.

------
olavk
He has a good point: CSS can only define the appearance of existing HTML
elements. Sometimes you need visual elements which doesn't correspond to any
semantic HTML element. I think SVG would be a good approach for designing
these "unsemantic" visual elements, and you can use CSS with SVG. SVG would
also be a good way to extend CSS beyound the built-in properties, eg. if I
want to design a wawy border to apply to some elements.

He also has a good point about the need for calculation in CSS. However I am
really worried about the possible manitenance nightmare of a turing-complete
CSS! It should be designed very carefully. A constraint-based sublanguage for
CSS would perhaps make sense.

------
thomasmallen
_"If you look at the specification there was only one property in CSS1 that
could be used to effect layout - float. position didn’t even exist, and in
HTML 2 neither did <div>, the two essential tools without which no modern
design could be achieved (without resorting to tables)."_

Lost me there. A <div> is just a vanilla block-level element. You can turn
anything into a <div>.

 _"CSS can only be applied to elements that have semantic meaning"_

You should see the CSS that developers I've worked with write. Even worse is
that DreamWeaver has its "style1", "style2" way of doing things which makes
picking apart a stylesheet very tedious.

------
tptacek
The fact that you can already accomplish what he wants with jQ, and that his
proposed solution is to add imperative programming semantics to CSS, one
assumes the reasonable response to this is simply a compiler that spits out
CSS/JS based on whatever random feature he wants CSS to have.

