To clarify, they can specify meaning, data, and behavior. Technically the `style` tag applies any abstract styling, and there are attributes for things like table-related elements that can change the superficial appearance (not sure which one that was); just pretend that the latter isn't a thing.
You do remember the hell that was the font tag, don’t you?
I think a lot of confusion from HTML being used for UIs vs hypertext documents. It’s a natural evolved mess still balancing the two.
But style should apply to the applied representation, while HTML should represent the intent of the content. The line is fuzzy, and HTML/CSS has a bad history of what falls where.
The cool thing with browsers is that we can bake in style to support multiple representations at once: monitor, mobile, printer, etc. Using the style attribute directly is mostly a side effect of only targeting the browser. Although your example of relative units is more ambiguous. Using a proper tag to represent the intent or falling back to a class where HTML lacks one would be preferable.
I think the separation makes more sense if you’ve used other document systems. SGML or XML DocBook, LaTeX, ROFF, etc.
For the last, if I use the man or mandoc module, all the man page norms are there for me and I’m just plugging in the content with the right macros.
W/o, I’m manually flipping registers all over the place.
Neither is necessarily "better", but rather they are different design choices. HTML at first wasn't intended to have very much styling at all, and originally there was some more styling mixed into the HTML itself (like <font>, bgcolor, etc.). Since now we pretty much want to make our webpages look like anything, it seemed to make sense to those drafting the standards to separate the two concerns, since HTML is mostly about page flow structure and data display, and page sources would be even harder to read than they already are if everyone was just putting their styles within HTML tags. If you're looking for a data attribute, it can be hard on the eyes to be constantly sifting through attributes for styling.
You certainly can do things to overload attributes and do what you're suggesting (in a sort of hackish way), and you wouldn't necessarily be wrong in doing so if that's your preference. Many people just don't like that.
One of the great things about separating styles out of HTML is that they can be contained in files and included separately. With poor connectivity, ideally, it's beneficial to keep the main page source to be as slim as possible so that it can still be downloaded and read even if the styling hasn't yet finished downloading. That's not nearly as relevant anymore, but it would not be surprising if keeping pages lean was a motivator in moving away from putting more stuff in HTML.
Contrary to popular belief, HTML and CSS are unrelated.
If any CSS property was also an HTML attribute, any addition to either spec would have to make sure it wouldn’t conflict. One example is the `content` HTML attribute and CSS property. They serve different purposes and have a completely different syntax.
Thanks for lecturing me, I'm aware of all that and know the genesis myth of CSS ;)
Sorry but I think you guys/gals don't get it - the question is why do we need two item-value syntaxes. Like, HTML has 'bgcolor=black' as markup attribute, and owing to SGML, the effective value for that attribute can be defaulted, inherited, and assigned in a context-dependent way. Those mechanisms aren't directly part of HTML because they don't need to be when it's understood that HTML as an SGML application can of course make use of all the authoring mechanism SGML has. But then comes CSS and defines an entirely new syntax that's almost the same (eg. "background: #000"). How is that helpful?
To say it in another way: let's assume we want web pages in 3D space, and yes I know z-index and CSS parallax effect are a thing so bear with me. Following the CSS logic, we should tunnel a background depth/z coordinate via CSS-in-HTML, like
<p style="background-image: url(bla); 3d-props: 'z is -100angstrom, depth-of-field is 123deg'">
where I deliberately have chosen ad-hoc characters for the item/value separator and multiple-properties separator to make the point.
You know, having a common meta syntax for elements/attributes is the entire point of SGML as a text format after all ;)
You don’t like my “lecturing,” but you continue making preposterous statements and asking questions that can’t be answered without “lecturing.” It’s like you’re saying “why is the sky is blue when we have water?” and then correcting yourself with “but I was talking about the stars, dude. ;)”
To answer pragmatically:
- don’t use the style attribute
- you could use XLST, which is style (and more) that uses the same ML
- are you suggesting that CSS and HTML should have the same style? <a style=“color=\”red\””>? I don’t know how that’s better.
Maybe you’re still missing some lecturing: HTML is content and CSS is style. What you’re saying about 3D context would be specified in CSS, in a separate file, so your CSS-in-HTML readability argument (I guess that’s your argument? Who knows) falls pretty flat.
It’s almost the same as complaining that JS doesn’t have the same format as HTML while it totally could, but instead we have JS-in-HTML. Oh how unfair life is.
As far as I can see, you’re just trolling, so thanks for the laughs.
What you’re saying was not clear from the start, you keep moving the goalpost.
Ironically XML allowed namespaces so css:color="red" could have totally been a thing. However CSS came out to separate content from style, so doing that wouldn’t have made much sense. I wouldn’t be surprised if the style attribute was added later.
Edit: wow I was right:
> HTML 3.0 supports style sheets via the use of the LINK element [1]
> HTML 4.0 adds new hooks for style sheets, which suggest how a document is presented. The new ID, CLASS, and STYLE attributes [2]
It keeps style instructions together instead of mingling them with data and behaviour attributes. There's some exceptions with some elements having attributes like width and border but it's mostly historical.
Do you really believe that "style" requires entire new syntax, as opposed to "data" and "behavior", vague as these categories are? In a markup language based on SGML already chock full of syntactical constructs for managing/inheriting item-value pairs? In SGML, attributes are exactly there for things that aren't to be displayed to the user; the idea that attributes are for "behaviour" or whatever is entirely made-up after the fact to justify CSS' existence.
> Do you really believe that "style" requires entire new syntax
Well it depends what you mean by entirely new, the syntax is that of a stylesheet. If we didn't have external stylesheets then maybe it wouldn't make sense to have a style attribute? but we do, so there seems to be some some logic for why we have an attribute that mimics it.
Not really sure if this is a worthwhile conversation to be honest as you seem to want this to be much more antognistic than it needs to be.
