-2

I have always thought that you cannot add in-line :hover{..} styles to a element, however I came across this page not that long ago, where I see stuff like this.

<a href="http://www.w3.org/"
          style="{color: #900}
          :link {background: #ff0}
          :visited {background: #fff}
          :hover {outline: thin red solid}
          :active {background: #00f}">...</a>

I don't like in-line styles at all, but my current app is based on in-line styles/scripts so, this would be a excellent feature for me.

There is one problem: it doesn't work.

Does anyone know why this doesn't work? Did Chrome not implement it or something?

Demo

Demo code from w3.org

Community
  • 1
  • 1
iConnor
  • 19,997
  • 14
  • 62
  • 97
  • 2
    possible duplicate of [CSS Pseudo-classes with inline styles](http://stackoverflow.com/questions/5293280/css-pseudo-classes-with-inline-styles) – PW Kad Aug 08 '13 at 18:17
  • The answers there are incorrect @PWKad – iConnor Aug 08 '13 at 18:21
  • As it clearly states on w3.org that you can – iConnor Aug 08 '13 at 18:22
  • 1
    if you're aiming for new Geckos, you might take a look at [scoped styles](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/style#A_scoped_stylesheet). [Not that that's a real solution](http://html5doctor.com/the-scoped-attribute/), but since you're dealing with in-line stuff anyway... – kubi Aug 08 '13 at 18:26
  • @kubi that's interesting but the reason I am using inline styles because creating a style element for every element in javascript would be bad – iConnor Aug 08 '13 at 18:29
  • 1
    There is a difference between "It works in every browser", "It doesn't work in all browsers", "It doesn't work in any browsers", and "There is a special browser it may work in". Generally, if it doesn't work in every (modern) browser it is considered to not work. Your linked document from W3C is from 2003, or what we call the pre-modern browser era. – PW Kad Aug 08 '13 at 18:41
  • I know the difference between what you just said, what made you think that I didn't? – iConnor Aug 08 '13 at 18:44
  • 2
    Specifically when you said 'All of the answers in that question are incorrect' when they are not incorrect. – PW Kad Aug 08 '13 at 18:45
  • The answer doesn't say anything about what I'm asking in my question – iConnor Aug 08 '13 at 19:00
  • 1
    @PW Kad: Thanks for linking. I've posted an answer here instead of closing as dupe though since this question centers around the old spec link rather than the concept in general. – BoltClock Aug 08 '13 at 21:34
  • @Connor - The answers on the duplicate question aren't incorrect - the page you found is an old working draft. It only acts as a page for review within the W3C, not that it's part of a standard. Check out the status part of the page for more information: http://www.w3.org/TR/2002/WD-css-style-attr-20020515#status – derekerdmann Aug 08 '13 at 21:53
  • @PWKad they do not answer this question, that is what I meant. – iConnor Aug 09 '13 at 11:55

1 Answers1

9

As a matter of fact, the same document was referenced in another question here. This is what I had to say about it:

That document you link to is a 10-year-old draft.

It's 11 years old now, but that's not the point (although it does suggest a very likely reason why the example you give doesn't work). The point is that the example given does not appear in the latest revision of the same specification. So, supposedly, embedding selectors in style attributes was deemed not viable and dropped as a result.

My answer to the question linked in the comments suggests why such a feature was deemed not viable — it's simply not compatible with the current state of CSS as a language:

Note that inline styles participate in the same cascade as selectors in rule sets, and take highest precedence in the cascade (!important notwithstanding). So they take precedence even over pseudo-class states. Allowing pseudo-classes or any other selectors in inline styles would possibly introduce a new cascade level, and with it a new set of complications.

Of course, I don't claim to speak for the people who actually made the decisions and/or wrote the spec, but if I were one of them, that's the reason I would have given for not supporting the feature.

That would also explain why no browser has implemented such a feature (or, more likely, the lack of implementation was among the factors causing it to be reconsidered and then ultimately dropped, giving vendors even more of a reason not to start implementing it now that the spec has reached CR status).

The lesson here is to never cite old revisions of W3C technical documents as canon. Always remember to review the latest specification; you should be able to find a link in the header of the document.

Community
  • 1
  • 1
BoltClock
  • 700,868
  • 160
  • 1,392
  • 1,356