If you are only interested in @font-face-based options, you might specify that at the top of your page. Other models are going to be equally prevalent for various licensing and display purposes. @font-face is a part of the picture, so it seems inaccurate to describe this subset of web font technologies as "Web Fonts" or even "web-native" fonts. Many commercial and proprietary fonts will be engineered for native web use as well.

Our previous model for web-readiness of fonts was the system fonts that come with PCs. Those, rather than the primitive early designs from Emigre, set a benchmark, and satisfy the most important criteria for robust web display.

Openness and speed in the context of fonts should also refer to fonts' technical abilities to download and display quickly and well on any device. Fonts won't perform, and therefore can't be considered web-native, if they aren't also built intentionally for the low-res media of web/mobile devices. So consider adding a third trait: web-native engineering. Unhinted TTFs, however free, open, or distributable, aren't likely to gain wide acceptance on the web if they look like hell. There have already been missteps in this area. A permissive license doesn't preclude a font from failing in this new medium.

I wonder if you can tighten up some of your language. "the thin and thick parts of the letterforms ... should be close." This implies they are close in proximity. You might say about letterforms that web fonts should be low-contrast or that their hairlines should be thicker than those of ordinary print fonts. I would also suggest calling the enhanced visual quality "readability" rather than "scannability", since the reality is that web fonts are going to be part of increased screen reading.

Consider other possible licensing models for web-native fonts. Plenty of marketing occurs, and will increasingly occur online, that depends on specific, exclusive fonts as part of brands and campaigns. The Guardian, New York Times, GE, and other entities want to communicate broadly and well, without freely sharing design assets that can be re-used by others. Facility in delivering web pages or other digital content in design-specific fonts isn't necessarily linked to free distribution, reproduction or remixing.

I might be misinterpreting some of what you have said, but I think you could be more specific about just what sorts of fonts you are discussing.

You should make a clear distinction between typefaces and fonts.
And address the issue of the relationship between web fonts and screen fonts.

A typeface is a general, fairly abstract design that may exist in different physical manifestations (fonts), for use in different output situations.

Thus, a typeface may be nuanced as more than one font, for use at different sizes in the same document ("text" and "display"), or for different media (e.g. smooth or glossy paper) in the same printing process. See H&JF's "grading".

Garamond, for instance, has been adapted from letterpress fonts, to phototype (ITC Garamond), to low-res LaserWriter output (Adobe Garamond). Which of those will the best web Garamond font be like?

Typefaces may be adapted for radically different media: hinting is one thing that accomplishes this in the digital realm.

One thing about typeface design is that the old styles have persisted across media changes, why should that change with the Web?

Large x-heights and open counters are not a necessary characterisitic of screen typefaces.
Why would a good screen typeface not vary x-height and counter size with pixel resolution, exactly in the manner of an optically-scaled print typeface?!

Look at how clumsy Verdana and Georgia become on screen at larger sizes.

Having said that, there are type design issues which are screen-specific. But that's getting into the relationship between sub-pixel hinting and curve shape. You can see this happening in the ClearType faces.

With all due respect I reject the biological analogy because there is a common biological entity at the end of both print and web processes. The different expectations of text and display, by that common biological entity, are congruent across media. E.G. (as Nick says sorta), differences you site like openness, are in a spectrum, i.e. the font desired by the person at 9 point for print, is "the same as" what the person wants for 13 point on the screen.

The biological entity is "only human" though so you can't trust it. E.G. there is a thread here where a type designer outputs a font in 7 different renderings and then picks the lightest and blackest as his 1st and 2nd choices, leaving others to wonder what the heck he's thinking about criteria-wise. ;)

Cheers!

@garrick

Having had a few days to ponder:

1) Not crazy about comingling the criteria of licenses PLUS the onscreen look of a font to pronounce it "Web Native".
Licenses are categorizable, so are fonts based on certain visual features. I think you *should* point out these distinctions on Kernest but independently of each other.

2) Personally, I don't like the phrase "Web Native". Too ethereal for my taste. If you have to explain it - as you have done - then I would argue it doesn't mean anything because you have to explain it. But that's me.

Plus, as you and I have discussed elsewhere, what happens when print stylesheets (and other @media categories) start getting used for serious publishing purposes (like Prince's HTML to PDF conversion stuff does now)?
Are the fonts we'll be looking to use in that context any less "web native" or are we going to label them as something else?

It seems to me you're allowing the limitations of LCD displays to define that which is "web" and that which is not, now and forevermore.

rich

David: ....there is a thread here where a type designer outputs a font in 7 different renderings and then picks the lightest and blackest as his 1st and 2nd choices...

What thread is that, David?

John>What thread is that, David?
lol. . . I'm sorry, were you trying to make a font family from a single master?

If you were looking for graphic images of text for design work, as you show, you perfectly well can feed a single master into the web's 'font software' and get a family of weights, (and a grunge style of two), somewhere in the output. My pardons if that was the intent.

Furthermore, I'd support convincing someone to make something — a browser, OS subsystem, or page descriptor, that could... uncontrollably auto-oblique all the web type for some users. Then the web could 'give us' a full family of weights with italic and grunge from a single style.

But seriously, with formatting, font identification, selection of style, sizing, scaling, and rendering relatively consistent in print, I think we're seeing the effects of making all this 'different', and each different in its own unique way, on the web.

Granted, the web and print are "two completely different things", but the 2d web needs to be a lot like 2d print, so often. I don't think 2d web design can be 10x the complexity of 2d print design as a result of this kind of 'different'.

Nor do I think quality web typography can be 10x the complexity of quality print typography.

Place Chinese proverb here.

Cheers!