Using the System Font in Web Content

System colors have been around forever, I don't remember them being IE specific. If they were it wasn't for long.

http://webdesign.about.com/od/colorcharts/l/blsystemcolors.h...

I always appreciate when they are used, so pages fit my OS theme.

Thanks, that clarifies that indeed this only works in Safari.

Thinking beyond just OS X, the purpose for a general "-system-*" font and style identifier would be that web apps could more easily have the "native look" without having to explicitly identify the operating environment. (And identifying the operating environment still doesn't necessarily tell you what their system font is set to; that's still heavily presumptuous.)

Maybe someone's Linux distro is using a serif typeface, or a monospaced serif typeface, or a monospaced sans-serif typeface, or something more like Comic Sans (have seen this more than once) as their system font.

The point is, we can do better than what we have now with regard to the goal of making web applications approach the "native look and feel" more easily and more simply. It's a balance game; a balance between adding features like this (every feature adds a little bloat) that also potentially help eliminate bloat elsewhere in code (e.g., javascript to fingerprint the environment). Further, getting the system font is something that CSS should be able to know about without the aid of JavaScript; there are lots of simple forms and data entry "applications" that don't use any JavaScript (nor should they) and would benefit from a better presentation. Writing a native application for any platform, I want to get the system font, and not have to know or assume any qualities of what that font is. With typical native applications, the default font is intrinsic in the UI widgets your using, so you don't have to think about it. With the web, typically the default font is a "document font" and not the UI widget font, so you need to be able to have some sort of mechanism beyond the default font in order to get the system UI font.

Also, to more appropriately answer your question, there exists a notion for separating "document" and "UI widget" fonts. Documents often have content to be read at long lengths. UI widgets don't have the "long length" constraint in their design context. As one example, the system font may be lighter in weight to achieve an elegant looking aesthetic. However, while the lighter weight font is acceptable for the UI widgets, it isn't nearly as acceptable for readability of document text. It's a nice to be able to have that design/usability context distinction. The default context for the web is that of the document, not the UI, the default CSS sans serif font should be the "document font".

The "default UA stylesheet" has always been a weird compromise: slightly different in every browser, yet generally all trying to render pages from 1994 mostly the same way they looked in 1994.

Personally, I think it would make way more sense if you could specify something like a "base style" meta-tag, with values like:

• "browser" (the default): do what we're doing now, where every browser styles things a bit differently, and a default Chrome <button> looks nothing like a default Safari <button>, and so forth.

• "legacy": make the page look exactly like it would when displayed in NCSA Mosaic in 1994. (This style could be inferred from the headers and auto-applied if the server sends a very old modification date or the page uses an older version of HTML.)

• "reset": a WHATWG-standardized set of CSS reset values

• "native": make tags resemble native OS controls—<p> should look like label-control text, <h1> should look like a native header style, <button> like an OS button (instead of a browser button), etc.

The interesting part of this is that this would allow the "browser" style to diverge further from the "legacy" and "native" styles than it already has, since any web designer could just ask the browser to drop all its customizations in a quick-and-convenient way.

In the context of general "-system-✻" font & style identifiers (not merely -apple-system-✻ specific)...

1. Knowing extremes and layout boundary conditions: You can reasonably test extremes of wide and condensed font metrics; it's not that hard.

2. Rigid designs: If you don't want to use the ambiguous system font, you don't have to; it doesn't change that. If you have a design that requires certain rigidity and inflexibility, you can have your explicitly imported web fonts and be happy.

3. Flexible designs: Be flexible and fluid. Be like water. Heck, there are slight unknowns with using any non-explicitly defined font. Using CSS generic-family identifiers (serif, sans-serif, cursive, fantasy, and monospace) have variation and are not guarantees, but you can still use them without much concern for layouts that are designed to be appropriately accommodating.

4. Native look and feel: If you want to achieve something closer to the native system look and feel, being able to use the system font from CSS helps you out immensely. For those that (1) design their layout to flow relatively nicely without being overly fixed or constrained and (2) want to have an appearance matching the system font, then it's great!

5. Testing: From my experience, this doesn't pose any significant testing issues. Besides testing artificial extremes of wide and condensed font metrics, practical testing across multiple environments isn't anything new. It's something that already gets done by any skilled front-end designer. Many shops will test across many browsers under may platforms anyway. Sites like http://browsershots.org, https://www.browserstack.com/screenshots, http://www.crossbrowsertool.com, http://www.browsershots.atm, https://www.browserling.com, http://dev.modern.ie/tools/screenshots/ and many others are out there for people who don't have or don't want to deal with the setup in-house to do testing. (You might have to supplement it with mobile devices in-house, sure.) You can easily cover 95% of the actually used environments (browsers/platforms) very explicitly, and for the environments you don't explicitly test for, at that point of successful testing, it's very likely there won't be an issue, and if there is an issue, it should be minor and not significantly matter. Be pragmatic.

Read the article, it clearly says...

On platforms which do not support “-apple-system,” the browser will simply fall back to the next item in the font-family fallback list. This provides a great way to make sure all your users get a great experience, regardless of which platform they are using.

There are currently discussions in the w3c regarding standardizing this value so authors could simply specify “system.” However, these discussions have not reached consensus, so WebKit prefixes this value.

Unless Apple makes it available for your use, no. Every system has its own system font and you can find them easily on the web.

Unless the font is particularly distinctive to the most casual reader, such an approach seems like pseudosecurity. San Francisco is not distinctive enough from other well-designed serif fonts that people will intuitively notice a spoofed message.

Besides, malware authors generally cannot be expected to follow copyright law. They can just steal the system font OTF and convert it to a web font, or render text as an image (which may not even be illegal), or any number of similar things.

If you are spoofing content, web fonts already have you covered. Assuming that people even notice the font enough to take it as a security cue.

It might be possible to do OS fingerprinting based on the font metrics, bypassing a spoofed UA.

It was meant to be a non-web feature, till people found out about it and started posting blogs posts elsewhere, AFAIK, hence the decision to prefix does follow that resolution.