meyerweb.com

Skip to: site navigation/presentation
Skip to: Thoughts From Eric

Blink Support(s)

Just a quick followup to last month’s post about @supports:

@supports (text-decoration: blink) {
	#test {
		color: green;
		background: yellow;
		text-decoration: blink;
	}
}

Results in all @supports-supporting browsers I was able to test: green text on a yellow background, except Firefox 22, which additionally blinks the text.  The latest nightly builds of Firefox 23 do not blink the text, thanks to bug 857820.

Discuss.

Six Responses»

    • #1
    • Comment
    • Wed 24 Apr 2013
    • 1206
    Lars Gunther wrote in to say...

    The keyword “blink” is still supported. From a comment in bug 857820.

    We shouldn’t remove “blink” keyword even if we don’t support the blink effect. Both IE10 and Chrome recognize “text-decoration: underline blink;”.
    Per CSS 2.1, conforming user agents are allowed not to blink the text.
    http://www.w3.org/TR/CSS21/text.html#lining-striking-props

    Thus “blink” is supported, it just does not blink…

    • #2
    • Comment
    • Wed 24 Apr 2013
    • 1210
    Eric Meyer wrote in to say...

    Lars: I’m absolutely aware of that, believe me. But when the text doesn’t blink, I don’t know that most people would regard that as actual support, as per my argument in last month’s post.

    • #3
    • Comment
    • Wed 24 Apr 2013
    • 1302
    Patrick Kettner wrote in to say...

    I am confused.

    In this particular case, it seems like if anything it is a spec bug.
    While I agree it is not clear that support for blink tag includes browsers whose tags don’t blink, the spec clearly states

    ‘ Conforming user agents may simply not blink the text.’

    Wouldn’t the ‘correct’ thing to do be update the spec to remove this wording, and thereby make the browsers remove this from their list of @support-ed properties?

    • #4
    • Comment
    • Wed 24 Apr 2013
    • 1541
    Paul Irish wrote in to say...

    Yup, this is a spec bug. Due to the (ridiculous) way the spec is written, Mozilla is fully correct to let the browser pass for @supports.
    Let’s poke the bear at bug 857820 and see if anything can be done about the spec.

    • #5
    • Comment
    • Wed 24 Apr 2013
    • 1602
    Ben wrote in to say...

    In this case, the browsers are saying “I support that — I fully understand what you want me to do, and I could easily do it — but I refuse.”

    • #6
    • Comment
    • Thu 25 Apr 2013
    • 0932
    Eric Meyer wrote in to say...

    Ben: true, but then it would be a simple matter for a browser to parse all known property-value combinations, and just “refuse” to do anything with those it hasn’t yet implemented. Does that sound like support to you? It sounds like parsing to me, not support. Support is when you actually do what the author has specified, not when you recognize what the author has said. Under your argument, even a badly-broken, wildly inconsistent implementation is still “support” because the property and value were correctly parsed.

Leave a Comment

Line and paragraph breaks automatic, e-mail address required but never displayed, HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>



Remember to encode character entities if you're posting markup examples! Management reserves the right to edit or remove any comment—especially those that are abusive, irrelevant to the topic at hand, or made by anonymous posters—although honestly, most edits are a matter of fixing mangled markup. Thus the note about encoding your entities. If you're satisfied with what you've written, then go ahead...


April 2013
SMTWTFS
March May
 123456
78910111213
14151617181920
21222324252627
282930  

Sidestep

Feeds

Extras