Safari CSS Handling--Mistake or Difference of Opinion?

[Makosuke]

I took some time last night to fiddle with an odd bit of behavior I'd noticed in Safari, and managed to distill it down to a specific test case

In a nutshell, if you specify the font-family of an eletment using CSS to a font that does not have a seperate italic version (or even a generic class, if your preference is set to a font that doesn't have an italic version), then try to apply the property font-style: italic to it, Safari, instead of applying a pseudo-italic effect to the text (just slant the font to the right), forces the font into a default that does have an italic version (looks like maybe Arial on my Panther system).

The behavior isn't really in question--it is easilly reproducable on two different systems, and has existed in every Safari version I've tried through 1.1.

What I'm wondering if this is a techincally acceptable behavior according to the CSS specs (which I've read through, but couldn't pin down a case one way or another for this), or if it's actually a rendering bug. In either case, it's not the behavior you'd expect, and every other browser I've tried (even iCab) does what you'd expect--forces a pseudo-italic version of the font.

 

[mnkeybsness]

are those even acceptable web fonts?

 

[Makosuke]

Originally posted by mnkeybsness
are those even acceptable web fonts?

So far as I understand the specs, there are no "acceptable" web fonts; CSS2 allows you to define any font you want via the font name, and also provides (requires, actually) generic font families (serif, sans-serif, cursive, fantasy, and monospace) as a fallback mechanisim. You can define any specific font you want--the only issue is whether the user's browser will support it.

The five generic font families should, at least in theory, be more general-purpose, with each matched to an appropriately styled font on the user's system so that you can define a general look (or fallback in the case of lack of a specific font) for a page and have it work on most user agents. Though the generic families need not map to seperate fonts, the W3C doc even gives suggestions as to the fonts that might be used as defaults.

In the case of Safari, on my system even the default cursive font fails when made italic, since whatever it is set to (I didn't try to change any font settings in Safari) doesn't have a seperate italic version.

It's interesting to note that the CSS2 standards doc says that setting font-style to italic will select the italic version of a definined font family. It doesn't say what to do in the case that one doesn't exist, although it does note under font-style: oblique that "A font that is labeled 'oblique' in the UA's font database may actually have been generated by electronically slanting a normal font." This certainly implies that it's acceptable for a user agent to generate an italic version of a font without one, but doesn't seem to require that behavior.

To me, it would make more sense for Safari to at leat ignore the italic property if it's going to be hard-nosed about generating "fake" italic text; that way you won't end up with a sudden shift in font in the middle of a text section where one wasn't intended.

 

[FattyMembrane]

here's what it looks like if you italicize a specific word within a sentence of non-italic text.

if i understand it correctly, the quartz text system will not perform false transformations of fonts. try italicizing lucida grande in textedit, it will not happen. i can understand the motive in doing this, as false transformations would have different appearances in different places and are not truly part of the typeface.

the proper behavior is arguable; if you leave the text in the font face specified by the css, it could potentially throw off a major emphasis in the text, whereas the current behavior is ugly, but convey's the necessary emphasis.

i think it really boils down to responsible web design and only using italics in font's with an italic/oblique variation, but we all know how responsible web designers are about making good code...

 

[Makosuke]

Originally posted by FattyMembrane
the proper behavior is arguable; if you leave the text in the font face specified by the css, it could potentially throw off a major emphasis in the text, whereas the current behavior is ugly, but convey's the necessary emphasis.

i think it really boils down to responsible web design and only using italics in font's with an italic/oblique variation, but we all know how responsible web designers are about making good code...

I had the same thought about text emphasis if you insisted on refusing to artificially italicize fonts.

However, your comment about responsible web design, though basically correct, isn't entirely on target, since the same behavior can occur (and does with the default fonts) even when using a generic font class.

Therefore, if I think I'm being safe and just using a generic "serif" class, but then want to italicize some text (perfectly reasonable), but it turns out that the UA's serif font doesn't have an italic version, I end up with a chunk of italicized san-serif type smack dab in the middle of an otherwise acceptable block of text. This can and does happen just by setting the font to the "cursive" class now.

What's worse is that the same can happen with any italicization (or even bolding) in a document if the user set their default font to something with no italic version; even though I leave the font as whatever they set, all I have to do is use a <strong> or <em> tag, and suddenly you have a chunk of bold or italicized text in a font completely different from the rest of the document, not to mention completely different from the default the user set and that the web designer was politely trying to respect. Try it--it's easy to force it to happen on well-coded pages by messing with your prefs.

Though technically not against spec, that just seems rude, aside from being different from every other browser implementation, period. Heck, the spec even suggests that UAs can create artifical oblique versions of a font.

Last thought while I'm at it: CSS2 expressly allows you to set varying degrees of boldness, and while it's not required for a UA to support this, it's impossible if you only allow "true" bold versions of fonts.

Is this actually a limitation in Quartz text, or just the text engine that TextEdit (and Safari, apparently) use? You'd think that if Apple will let you add fancy drop shadows and double colored strikethroughs in their text engine, they'd let you slant the text a bit.

(Speaking of which, though, Safari now supports the text-shadow CSS property! Cool! Just it and, I've heard, late builds of Opera, though I've never seen it work on Opera.)

 

[Rower_CPU]

Very interesting test case, Makosuke.

As you guys have already covered, I think this is one of those issues that falls into the grey areas that the W3C hasn't resolved in the CSS spec. Although, the usefulness of italicizing a cursive font is debatable.

I'm really happy to see people here pushing the envelope with CSS, and getting discussion going on topics like this.

 

[Makosuke]

Originally posted by Rower_CPU
Although, the usefulness of italicizing a cursive font is debatable.

I'm really happy to see people here pushing the envelope with CSS, and getting discussion going on topics like this.

Scary as it may be, I occasionally find stuff like this fun. When most people buy a book or find a tutorial to learn HTML and/or CSS, I just started reading the specs, because it was more fun that way.

That said, the unfortunate thing about this issue is that it doesn't involve much envelope pushing at all, just simple font manipulation. It also doesn't require anything as potentially odd as italicizing a cursive font; as I pointed out, you can illustrate the same issue by doing nothing fancier than setting your default font to something serif with no bold version and looking at a page with a <strong> tag somewhere.

Not an everyday occurance, but we're not talking arcana.

I do belive all us Machead webmasters should start putting tolken shadow CSS properties into our designs. That way Safari-using Mac users (and maybe some Opera people) can feel special that their browsers are the only ones that support the property, so the pages look subtly cooler in their browser. (Ironically, I still use Chimera, though.)

 

[Rower_CPU]

I was referring more to the text shadow thing than the italics issue in regards to "pushing the envelope", but I agree.

I can't wait to see more CSS3 properties gain wider support. Then again, I'd be happy with full, consistent CSS1 and 2 support in current browsers.

 

[Makosuke]

Originally posted by Rower_CPU
Then again, I'd be happy with full, consistent CSS1 and 2 support in current browsers.

I think by "current browsers" you mean "IE". The more you know, the more you hate it.

I'd be happy if that standards-flaunting piece of refuse Microsoft calls a browser would have even half-decent support for CSS2, and Netscape 4 would just die quietly.

 

[Rower_CPU]

Exactly.

All I do for NN4 is screen all the CSS but some basic font and color declarations in the body and give them a nice statement to the effect of "Update already, slacker!" in a div with display:none.

I'm continually amazed with the inconsistencies in IE6 and the friggin' whitespace issues are just plain dumb.