[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?

[talmand]

The distinction is relevant in that you seem to want to ignore them for a less efficient method.

Yes, indeed, many servers send the HTML, CSS, and JS files compressed and is trivial, but bloated code that is compressed still takes more bandwidth than more efficient code compressed. There might be something said about combining all three into one HTTP request but to say that there's little difference between bloated inline styles and a properly created style sheet is an odd one. Even if the difference between the two is 10k per page then it adds up over time. It would be far better to rely on CSS classes in the head section of the document than to have duplicated inline styles throughout the document. It seems you are willing to create inefficient output for the sake of attempting efficient input, which only benefits you personally as the coder during the creation process of the project.

Therefore I don't think you are reducing the number of layers involved, but only masking it. In the end you will still have HTML and CSS but with a slightly different way to code them. If that's the extent of the goal then congratulations on duplicating what we already have. Although these applications are interesting and have intriguing ideas, they don't fundamentally address the inherent problems of HTML and CSS. For things like this all your doing is creating a new way to write inline styles which can be done right now without adding in new inherent problems.

What's the difference between this:

STYLE.on("element", {textAlign: "center", fontSize: 50})

or this:

element style="text-align: center; font-size: 50px;"

or this: .element {text-align: center; font-size: 50px;}

Almost nothing, in terms of inline styles. Except that the first two have to be duplicated throughout the code wherever they are required while the third only requires a reference. Now, if you need to change that text-align to left you have to change every instance of it throughout your code, except for the third where it only needs to be changed once. If this code is duplicated in multiple files then you've added complexity to the task, while with a single style sheet you only change one line. Also keep in mind that with the first example that code has to parsed on every single page load before it can be rendered.

Now, in the cases of small webapps I can see these things being of little concern. But for large projects or a regular website it's asking for headaches. Not because of things like domo, but because the end result has to be what the browser expects. Plus, there's the issue that if you want this web page to be indexed by search engines you're going to have problems. If people have turned javascript off or use a white list to control scripts then this page simply will not work with very little available fallback. If someone other than you needs to maintain or update this code and don't know this system then you will have problems.

So, am I saying that people should stop making these type of things and stop experimenting? Of course not, this type of exercise is interesting if the end goal is to determine how we could possibly replace HTML/CSS with something more useful in terms of modern websites and apps. For instance, being able to do mixins and the like in CSS is incredibly useful, which is why the CSS processors are popular. But to say that we can take something like domo to be used today as a replacement to HTML/CSS is a bit misguided. In the end it is still HTML/CSS, what we have here is the equivalent of a WYSIWYG editor for javascript coders who, for whatever reason, don't/can't/won't learn HTML and CSS even though those are the easiest parts of the equation.

Keep in mind this thread started for me because of your statement that CSS is not powerful enough to express styling when that's exactly what it does and all that it does. In the end I fail to see how what you propose is better than what we have today, in fact I feel it is worse.

By the way, CSS selectors do not provide a way to reuse your markup in several places. That is, if you are referring to HTML when you say markup, which is the usual definition of the word. CSS selectors let you target elements in your markup to style them, nothing else. You can use these selectors to reuse your CSS stylings for duplicate elements that require the same styling. It is statements like that suggest to me you don't fully understand the relationship between HTML and CSS.

[lmm]

>What's the difference between this: >STYLE.on("element", {textAlign: "center", fontSize: 50}) >or this: >element style="text-align: center; font-size: 50px;" >or this: .element {text-align: center; font-size: 50px;}

The difference is that CSS has its own syntax, its own semantics, and its own set of gotchas to learn, different from any other language. (Obviously for a simple selector like .element it's easy to know what it's going to refer to, but CSS is not limited to things that are so clear).

>Now, if you need to change that text-align to left you have to change every instance of it throughout your code, except for the third where it only needs to be changed once.

Only if you're a muppet. Your HTML is being generated by a program; that program should have a single place where it knows what the text-align of this class (in the general sense of the term) of elements should be, and you can change it in that one place if you want to change it.

>Plus, there's the issue that if you want this web page to be indexed by search engines you're going to have problems. If people have turned javascript off or use a white list to control scripts then this page simply will not work with very little available fallback.

Right; it only makes sense to use javascript if you're already using javascript for major functionality. That's what I'm really advocating for here: write your styling logic in the same language as the rest of your site's logic.

>Keep in mind this thread started for me because of your statement that CSS is not powerful enough to express styling when that's exactly what it does and all that it does.

My point was that it isn't powerful enough to express your styling in a fully abstracted way. E.g. if your website's general colour scheme is blue and you have parts that are a light blue, a mid blue and a dark blue, CSS doesn't let you define these colours in terms of each other - so if you want to change it to be green, you have to change three different colour definitions. Because of this kind of thing, people use pre-processors like LESS - which means using yet another language with its own syntax and logic to learn, when you're already using a perfectly good programming language to generate most of your site.

>CSS selectors let you target elements in your markup to style them, nothing else. You can use these selectors to reuse your CSS stylings for duplicate elements that require the same styling.

Yes, that was why I took pains to say "some small specific parts of your markup". Your styles are part of your markup, at least traditionally.