[lmm]

I don't see the use for CSS; it's not powerful enough to express your styling, so you always need some kind of programmatic processor that generates it (whether in javascript or some other language), at which point you might as well have that same program apply styling directly to your elements.

But yeah, I'd rather have strong separation of markup and behaviour. I love the wicket approach to this (your templates are plain html; the only thing you can add to them is identifiers that mark a tag as being replaced by a component; all logic goes in the code), and wish I could find a templating engine for more modern technologies that used the same approach.

[talmand]

No use for CSS? CSS not powerful enough to express styling? Huh?

You want to get rid of CSS for styling and replace it with something else for styling? Wha?

The processors you speak of output CSS. They do nothing that cannot already be done with CSS, they just make it easier. Plus, when using javascript to apply styles you are still using CSS, you are just applying it in a different way.

[lmm]

>The processors you speak of output CSS. They do nothing that cannot already be done with CSS, they just make it easier.

And CSS does nothing that can't be done with inline styling (well, that's probably not true now, but it was once and could be made so again), it just makes it easier.

If your site's styling is being produced by some program which knows things like "the nav bar is 20% blue" and "all otherwise unstyled text boxes have a grey background", there's no reason that program couldn't put the styles in the html directly.

[talmand]

Sure, an application that inserts into HTML can handle what you speak of, but that doesn't address my questions about the statement of CSS being unsuitable for the task of styles.

Sorry, but inline styling is still CSS. I know that CSS standing for "cascading style sheets" may cause confusion but all styling for an HTML document is done with CSS. Even the default styles a browser uses on an otherwise "unstyled" document is based on CSS. You can insert styles directly into an HTML element with Javascript and you are still using CSS.

But if you start using such an application to insert your CSS directly into HTML then I'm willing to bet you are due for a headache in the future. There are several reasons why inserting CSS inline is a bad idea. First, you are seriously duplicating your code since you have no class structure to work with. Second, you've just given up pseudo classes. Third, good luck maintaining that code, especially if you eventually stop using the program that created this code in the first place. I fail to see how that's easier.

"all otherwise unstyled text boxes have a grey background" - those "unstyled" text boxes are now "styled", you seem to be repeating the statement that prompted my response in that somehow CSS is not the answer but then you provide an example that uses CSS.

[lmm]

>Sorry, but inline styling is still CSS. I know that CSS standing for "cascading style sheets" may cause confusion but all styling for an HTML document is done with CSS. Even the default styles a browser uses on an otherwise "unstyled" document is based on CSS. You can insert styles directly into an HTML element with Javascript and you are still using CSS.

Matter of definitions. I'm advocating styling one's page inline and/or via javascript, without using external stylesheets. (Well, I'd really advocate styling using attributes a la html3, but it's too late for that now). Call that what you will.

>First, you are seriously duplicating your code since you have no class structure to work with. Second, you've just given up pseudo classes. Third, good luck maintaining that code, especially if you eventually stop using the program that created this code in the first place. I fail to see how that's easier.

I already have a class structure, because my HTML is being generated by a program. The actual HTML is like an assembly language, not meant for manual reading or editing.

Yes, I've given up pseudo classes. I don't think I'll miss them.

[talmand]

By what you say it seems you don't understand what a class means in terms of CSS, because what you advocate is not it. In fact, your avoidance of external stylesheets heavily suggests you don't understand the idea at all. I'm not saying you don't understand these things, but what you say doesn't show it very well.

No one expects a layperson to read or edit HTML, but they do have to receive it in some manner and your method is the most bloated way to do so.

Why can't your magical application just output proper HTML and CSS, with external files if need be, without you ever having to deal with it? I understand wanting an easier way to do things but making something that outputs what amounts to a crappy substitution is not the solution.

Anyway, I wish you luck with the most inefficient method possible of creating and providing styled HTML documents.

EDIT: to the creator of domo if they happen to read this, to me this thread has nothing to do with your endeavor, I actually find it somewhat interesting despite its obvious problems. This thread is about the idea proposed about CSS as if we can be rid of it, as to be tossed away. My original intention is to explain that this is a silly idea and this has gone in a different direction.

[lmm]

I know it's not a class in CSS terms, I didn't think that distinction was relevant.

>No one expects a layperson to read or edit HTML, but they do have to receive it in some manner and your method is the most bloated way to do so.

Sending things over the wire in compressed form is trivial (many servers do it already) so this doesn't bother me.

>Why can't your magical application just output proper HTML and CSS, with external files if need be, without you ever having to deal with it?

My goal here is to reduce the number of layers you need to understand to debug your webapp. Fundamentally CSS selectors provide a way to reuse (some small specific parts of) your markup in several places - but any web application framework will already provide a way to reuse markup, with its own logic. So why should developers have to learn two different ways of abstracting their markup?