How is adding support for EOT-formatted CFF fonts not adding a new feature?
The EOT format is supposed to be flavour-neutral; ergo, failure to support CFF-flavour EOT is a bug. The fact that there is nothing in the system level support that would make support for CFF fonts untenable in IE, while contemporary MS apps support CFF fonts, indicates that this is specifically an IE bug.
...the argument is being made that EOT-Lite is better because other formats can’t be supported for “years”.
It's not an argument I've made. I've heard everything from one year to ten years cited as the time it will take to implement a new format across new versions of all major browsers. I'm inclined to think it will be shorter rather than longer, for the reasons you identify.
I do think there are significant backwards compatibility benefits of EOT Lite even if one ignores the CFF font problem in IE. There are a lot of fonts in TTF format that are licensed for or ready to be licensed for EOT Lite. There are some foundries that are very PostScript-centric -- not just Adobe, but others whose primary market is professional graphic designers --, on the other hand most serious web designers already understand that TrueType renders better, especially on Windows. It is this backwards compatibility that I believe is the best argument in favour of EOT Lite. That backwards compatibility is far from perfect, but it is real.
I think it is web authors and designers -- not font developers -- whom you will need to convince that this backwards compatibility is not worth embracing. I think most font makers will be happy with any format that isn't naked font linking and which offers the minimal levels of protection against misuse that we have asked for on the W3C list.
John Hudson:I know a lot about fonts, but I couldn’t tell you off hand which of the fonts currently on my system might be legitimately uploaded to a web server under current licenses and which might not.
Oh, I can tell you, None you didn't make yourself and permit for such use, none you received from others are permitted for serving are they? That is how simple it is and what all of 'our side' must enforce. You won't get web fonts e-mailed, you get urls. Sans new format and until a new format is released, and after it has been undressed by time, we will always have to enforce this. Fonts today, and will be forever, licensed for a number of cpus and a number of embedding permissions. Print happens, and it must go on with licensed IP. Nothing technical is going to stop 'a nobody' from serving a cpu-licensed fonts contrary to print licensing agreements, but it is very legally prosecutable because locating and serving fonts from a server does not happen 'automatically', it's a human act. And as such, only 'nobodies' will be able to do it, same as print, where 'nobodies' copy and compose with unlicensed fonts. If they become somebody, we find 'em.
Until someone changes the rules or market and makes all the "IP somebodies" into "IP nobodies", there had better be a table to tell the difference in detail, a font format distinction will only last so long for this purpose, and probably not nearly as long as OT's undressing took.
Question: Is it possible to put in the web site code for specifying fonts to use one for one browser and one for another? If so, Firefox and IE could have their own preferences, and foundries could still have the 'garden fence' protection for their IP one more than one browser.
Is it possible to put in the web site code for specifying fonts to use one for one browser and one for another?
That’s how all these new font services manage to work cross-platform.
Thanks James. If it's not too complicated to specify, then Mozilla and Microsoft don't have to agree, which (above) I thought was the issue. Microsoft can use EOT or EOT lite, Mozilla can use .webfont or zot, Fontlab can give us output for both, and we're up and running. Not ideal, as a common standard is better, but still workable.
"Just curious why five years? Non-IE browsers are on 1-year replacement cycles, and IE8 is replacing IE7 at a similar rate. IE6 is it’s own, oh so very, very special case."
For days I've wondered "why hasn't anybody asked me to justify the '5 year' estimate yet?" It had to be you, naturally.
As I think you suspect, it's because 5 years is a nice round number that, (I truly do believe), is close enough to the truth to convey the severity of NOT acting on EOT lite. LOL! But it could actually be longer, depending. I find your own quick analysis a little loose-goosey, too.
When the first Ascender proposal appeared, Chris Wilson (former Platform Architect for IE) wrote this on the Ascender blog:
"* do the math - figure it's 2 years until the next version of IE comes out given current track record, and it takes 18 months for IE to convert 50% of its users to a new version (see adoption data from marketshare.hitslink.com). Even if you presume IE continues to drop share at 10% a year, AND IE puts support for the new (as-yet-not-defined) format into their next release, you're looking at 3.5 years to get support and get it deployed to the bulk of IE's market. (This presumes, of course, that other browsers implement it and get it deployed to 100% of their market in that time - then overall support would be 2/3 to 3/4 of the entire public.)"
What Chris didn't go into is that getting that new format out to the remaining 1/3 or 1/4 of the remaining public would be a long, drawn-out affair taking several years. And his analysis is also predicated on a new font format making it into the next cycle of IE, which is wildly optimistic, I feel. You have to add another two years for each cycle missed.
Granted, a better guesstimate can and should be generated. I'll take it on as homework and report. I'll be happy to change the "5" to "too damned many" in the meantime, if you so demand it. ;)
The separate code for different browsers is what these services currently do, and what web developers, whenever they can, want to avoid going forward.
Throughout these conversations here on typophile, I think I've lost track of all the parties goals/concerns.
Is this a valid summary?:
MS = not sure.
W3C = Want to avoid implementing proprietary MS-centric standards as much as possible
Mozilla = Want to avoid implementing DRM-esque features
Opera/Chrome/Safari/etc = not sure if they are part of the conversation
Type Foundries = various concerns ranging from various degrees of DRM (from slight file name obfuscation to full on DRM) and font formats (to accommodate various degrees of meta data [and other stuff?])
Web Developers = Want something easy that works now.
Font 'pirates' = They don't care one way or the other.
Web Font Delivery Service Sites (Typekit, Kernest, etc.) = They're happy with all of the debate as that gives them a reason to exist (simplifying the whole system via a service)
@aluminumWeb Font Delivery Service Sites (Typekit, Kernest, etc.) = They’re happy with all of the debate as that gives them a reason to exist (simplifying the whole system via a service)
Some people could also argue that this world is not the ideal one, so we should support a mission to Mars. An others will strongly defend that assumption saying "stop the Earth now!".
I tend to agree with Richard, maybe we should take another look at .WTF
Sorry, just trying to bring some humor back here. :)
Web Font Delivery Service Sites…They’re happy with all of the debate as that gives them a reason to exist
There’s more to it than that. These services would turn up anyway, because the web allows us to tip the scales of commerce a little more in favor of type designers. Until now digital type vendors have had little choice but to sell licenses that never expire and can be used for anything and had to rely on the honor system to ensure clients actually bought a license for every workstation. Web font services bring back a market in which type wears out, prolific users must buy more fonts, and for perhaps the first time, make catching pirates easy. After seeing what these new services plan to offer I’ve already decided that in the future I’ll be charging a premium for traditional licenses, allowing no web embedding, and require web use to be done via a service.
John, Web pages are made by Web developers, and the ones who are going to sign on to Web fonts aren’t using Internet Explorer for Windows.
Joe, who cares what browsers web developers use. What matters is what web browsers the customers of their customers use. Which in practice is any and all browsers.
Design isn't a masturbatory exercise for designers, it is a part of making things for people.
How many people do you think read the Guardian website in Internet Explorer? I mention the Guardian because they have done an impressive job in recent years of using custom typefaces to create an immediately identifiable brand across multiple media. They strike me as exactly the sort of client that will want to use their custom typefaces for their web presence also, and what matters is not what browsers their web designers use but what browsers their readers use.
Am I stating the really obvious yet?
Bill: Thanks James. If it’s not too complicated to specify, then Mozilla and Microsoft don’t have to agree, which (above) I thought was the issue. Microsoft can use EOT or EOT lite, Mozilla can use .webfont or zot....
The browser makers don't have to agree on an interoperable format, but they want to, and so do lots of other people for whom maintaining support for multiple formats is an expense: font makers and vendors, web designers, served typography services like Typekit. An interoperable format benefits everyone.
The most recent discussion on the W3C list indicates that everyone is agreed that a format along the .webfont or ZOT lines is desirable and people are willing to work together on this as a format. The debate now is whether EOT Lite will be an interim interoperable format.
"Web font services bring back a market in which type wears out"
The catch is that the web font services are based on non-service technology. So they are merely a convenience--not a requirement--from a technical standpoint.
Your 'licenses that wear out' comment is interesting though. I can certainly see the appeal from the foundry POV. But, alas, there is no inherent technical implementation at this time that would any way force the consumer to adopt that model.
"and require web use to be done via a service."
Ah! Now that's an interesting angle. It uses a EULA requirement rather than a technical one. I can see that being an interesting route to take. It might work.
I have to assume once the dust settles a bit MyFonts will implement such a system and we'll migrate back to that being the primary provider.
"and the ones who are going to sign on to Web fonts aren’t using Internet Explorer for Windows"
GRAPHIC designers are in the Mac-only club. We web designers are fairly platform agnostic. ;)
That said, it's often true that we really don't give a damn what a site does in IE6 anymore (at least, not until the client yells at us. ;o)
David: ...there had better be a table to tell the difference in detail...
...a font format distinction will only last so long for this purpose...
The font format distinction provides a minimal level of protection against casual misuse; it does not, and was never intended to, provide protection against deliberate cracking and intentional misuse, so your mantra about how easily it will be cracked is beside the point. The difference between naked font data on the web and wrapped font data is the difference between leaving a $20 bill on the hood of your car and leaving it on the driver seat with the window open. To a thief, there is no distinction, it's free money; to an honest person the status of the bill on the hood of the car may be in doubt, whereas they will understand that the money inside the vehicle belongs to someone else. The web font format wrapper is one way of removing the ambiguity about whether a font is licensed for use on the web. It is not the only way, nor will it always and and in all cases be a sufficient way, but it is part of an aggregate solution. I agree with you that font metadata is another necessary part of the solution. There are also optional things like server-side obfuscation such as Typekit offers that can play a role.
Thanks for the update, John. This is sounding more hopeful.
John> The difference between naked font data on the web and wrapped font data is the difference between leaving a $20 bill on the hood of your car and leaving it on the driver seat with the window open
Bla bla bla from a mere 30 days past.
What is now being offered in EOTL by MS, is that no "Embedding" permissions will be checked by IE, that all EOTL fonts that have been converted will be served regardless, that text somewhere will tell "the user" not to pay attention to embedding rights when seeking to serve a font, and the OT format will be revised to state what "Embedding" is and is not. This is the new "rallying point" for all other browsers to interface to EOTL as the web font standard.
Could you, john, please define for us the life cycle of an "interim web font format"?
David: What is now being offered in EOTL by MS, is that no “Embedding” permissions will be checked by IE, that all EOTL fonts that have been converted will be served regardless, that text somewhere will tell “the user” not to pay attention to embedding rights when seeking to serve a font, and the OT format will be revised to state what “Embedding” is and is not. This is the new “rallying point” for all other browsers to interface to EOTL as the web font standard.
No, David, this is not what is ‘being offered in EOTL by MS’. This is what I proposed to you, in the other thread, as a way of ensuring that EOTL doesn't carry ambiguous baggage around the OS/2 embedding bits, because you had identified this as a problem in EOT. I agreed that it was a problem, and that it is something that should be clarified in both OT and also EOTL because the latter, whether we like it or not, has a strong chance of being implemented by the major browsers on account of its backwards compatibility with IE6, 7 & 8. I also pointed out that the ambiguity re. the embedding bits -- do they indicate permission for web linking or only for document embedding? what does ‘document embedding’ mean given that MS used that term explicitly to refer to web linking in the EOT spec? -- is not in any way limited to EOTL, but is a general problem for any OT web implementation. Finally, it is an ambiguity that potentially gets in the way of your EPAR table by presenting duplicate and possibly contradictory permissions elsewhere in the font. So I was trying to find a way to help you by clarifying the status of embedding bits re. web linking so that they don't get in your way.
And now this proposal from me, for which I repeatedly asked your opinion in the other thread, has become in your mind ‘what is offered by MS in EOTL’? Must be strong stuff.
Could you, john, please define for us the life cycle of an “interim web font format”?
I'm sure there's some number of people out there with working Beta video players and recorders, so ‘life cycle’ doesn't seem a useful metaphor when talking about any technology: things don't die until a long time after they cease to be supported. The attractiveness of EOTL for web developers -- its only attractiveness as far as I can tell -- is that it is backwards compatible with more than 60% of all browsers currently in use. So the short end of ‘interim’ is IE9 with support for some other web font format, which is estimated at being between 18 months to two years. But of course not all users upgrade, so the long end of ‘interim’ is the slow decline in use of the older browsers and the gradually diminishing giving-a-fuсk our clients have in serving content to those legacy browser users.
>...I repeatedly asked your opinion in the other thread, has become in your mind ‘what is offered by MS in EOTL’? Must be strong stuff.
So what I'm hearing you say is that you don't represent MS, and they they don't either.
>But of course not all users upgrade, so the long end of ‘interim’ is the slow decline in use of the older browsers and the gradually diminishing giving-a-fuсk our clients have in serving content to those legacy browser users.
:-o oh my virgin ears. So, what I'm hearing you say is that OpenType, as an interim format, is not going anywhere?
So what I’m hearing you say is that you don’t represent MS...
...and they don’t either.
So far as I can tell, MS have a designated point person re. web fonts, and that's Sylvain Galineau, who is active on the W3C discussion list.
So, what I’m hearing you say is that OpenType, as an interim format, is not going anywhere?
And I'm left, again, searching for the connection between what I say and what you hear.
What do you mean by ‘OpenType’ in this context? The font data in all the web linking font mechanisms under discussion is OpenType. What's under discussion is how to package that data for dynamic loading by web browsers. The majority of web browsers now in use can dynamically load a file format that is compatible with their handling of EOT, hence the viability of what is currently labelled EOTL as an interim web font format with interoperability potential (the non-IE browser makers don't like it, but they're also testing code for it). In contrast, serving straight OTF/TTF fonts works in a minority of browsers in use, and has little or no interoperability potential (MS won't touch it).
I suggested on the W3C list that EOTL be re-named 'Compatibility Web Type' with the file extension .cwt, to distinguish it from EOT and also to make clear that it exists in order to serve a compatibility function with existing IE browsers. Ascender have indicated that they like the name, and no one has objected to it, so perhaps that will be it.
I think the CWT appellation works well for the intended purpose.
John>And I’m left, again, searching for the connection between what I say and what you hear.
Like I said before, OT is not going away as a web format. John, can you point us to web sites using some of your EOT fonts?
John>The font data in all the web linking font mechanisms under discussion is OpenType.
Can you show me an EOT that contains an OT font?
>What do you mean by ‘OpenType’ in this context?
We need to redefine OpenType?
Perhaps we should compromise; I will start from the very beginning, and redefine "Thomas" and come forward, and you start with a whole new definition of "OpenType" (and move backwards, needless to say), and we'll meet somewhere around "coffee."
> We need to redefine OpenType?
David, I don't think so. Rather we just need to clarify what you mean when you use the terms "OT" and "OpenType".
Like others, I get easily confused.
OpenType is defined as a font format that can contain either TrueType outlines (.ttf fonts) or PostScript/CFF outlines (.otf fonts). [[http://www.microsoft.com/typography/otspec/otover.htm]]
So I find it best to refer to .ttf fonts or .otf fonts rather than the more generic "OpenType".
> Rather we just need to clarify what you mean when you use the terms “OT” and “OpenType”.
Bill, OT is OT, TT is TT. There are two separate specs. I can point you to the two links if you are still confused.
What you need to tell people whilst going about your heckling, is that the only interoperable format acceptable today in all IE is EOT wrapped 'round TT 1.0. Or, show me an OT font wrapped in a EOT that's got an OT font in it and works everywhere.
Thomas, John, where are your EOTs? Come on boys, over the top!
David, Bill has a point. It's ambiguous to refer to "OT" when speaking about outline formats. Yes, "OT is OT", but "OT" does not mean CFF.
After hearing all your reasonable arguments here, I just can't understand why you give Franklin away nude in the world *wild* web. http://www.zeldman.com/dwws/
Could you explain us how do you plan to control its use now?
@john hudson, bill davis, and all:
"I suggested on the W3C list that EOTL be re-named ’Compatibility Web Type’ with the file extension .cwt, to distinguish it from EOT and also to make clear that it exists in order to serve a compatibility function with existing IE browsers. Ascender have indicated that they like the name, and no one has objected to it, so perhaps that will be it."
CWT for “Compatible Web Type” sounds too flattering. And with no indication that it's been, in W3C parlance, "deprecated" right out of the starting gate.
How about LWT for “Legacy Web Type”.
Variations:LFF - Legacy Font File/Format/FaceLTT - Legacy TrueTypeLWF – Legacy Web FontLET – Legacy Embedded Type
I like the word “legacy” – it brands EOT as what it is: a hold-over from a previous era and slated, ultimately, for obsolescence. It helps indicate that preference should be given, going forward, to .webOTF or WOFF or whatever it's going to be named.
(Maybe we should run this by a focus group scientifically. Where's kevlar?)
>David, Bill has a point.
Define that point.
Where are your EOTs?
>Could you explain us how do you plan to control its use now?
Define control, nude, and who you claim to represent.
Come on fellows. Or are you not?
Define control, nude, and who you claim to represent.
Control = To know where the fonts are being used over the web and if all of the websites have a proper licence for doing that.
Nude = OTF/TTF fonts that can be technically used on the web, but also can be technically installed and used in desktop publishing.
Who you claim to represent = I represent myself, as an independent type designer running a small one-man-foundry called Outras Fontes (click in my login name for more info).
Please do not take my questions in a personal or accusatory way. Everyone have different ideas of what can be the best model to offer fonts for web usage, and I'd like you hear yours, as a respected type designer running one of the most respected foundries in the world.
Is it clear now?
Rich: CWT for “Compatible Web Type” sounds too flattering....
CWT for “Compatible Web Type” sounds too flattering. And with no indication that it’s been, in W3C parlance, “deprecated” right out of the starting gate.
How about LWT for “Legacy Web Type”.
Good point, Rich. "Comaptible Web Type" could lead to a meaning that it is already compatible with most browsers, that is far to be be a truth.
"Legacy" suggests that it can be developed for obsolescence, not for the future that is better represented in .webOTF/WOFF proposal.
“Comaptible Web Type” could lead to a meaning that it is already compatible with most browsers, that is far to be be a truth.
That depends how you count browsers. The whole attraction of this format is that it is compatible with the majority of individual browsers in current use. If it were not, no one outside of MS would be remotely interested in it. It is a format that is compatible with IE6, IE7 and IE8, and hence with approx. 60% of browsers being used to view web content by users. That browser market share is declining (it used to be approx. 80%), but still constitutes ‘most browsers’ in the only sense that phrase is significant.
> That depends how you count browsers.
I know. Microsoft has a significant market that we just can't ignore if we wanna work serously on that for a big audience. By most browsers I mean the different browsers in the market that also have its usage that is significant enough not to be ignored. I think it strongly depends of the target audience of a web site. The readers of Rich's readableweb.com, for instance, is certainly not the same as the readers of bbc.com. :-) Just to give an exemple, in my foundry's site it's 57% Firefox, 21% IE, 9% Safari, 8% Chrome and 2% Opera.
I've replied to you on the list.
You say tomaytoe, and I say tomahto, but let's not call the whole thing off, OK? :)
Plus - and this is the last time I'm going to tell you this, my friend - Ascender and Microsoft are NOT plural nouns. It's Ascender *has* announced, not Ascender *have* announced.
I think I'm finally going to have to buy Joe Clark's book on Canadian English to get a handle on all this.
And is there a book or *anything* that will help me decipher Berlow?
> And is there a book or *anything* that will help me decipher Berlow?
Maybe I can suggest "The Super-Hinter-Man: histories and nomenclatures from the deep".
Just kidding, ok? ;-)
Rich: Ascender and Microsoft are NOT plural nouns
Yeah, I know that, but I tend to think of these companies in terms of the people whom I know who work at them, so they tend to pluralise themselves in my head.
>...in my foundry’s site it’s 57% Firefox, 21% IE, 9% Safari, 8% Chrome and 2% Opera.
Mine is even fewer IE than that and as I talk more about web fonts, it keeps going down, down, down.
Now, for the future, do you want everybody to go backwards to 1995 and wait for MS, or not? It's a simple question. ;)
Microsoft has a significant market that we just can’t ignore if we wanna work serously on that for a big audience
Segregating IE users to a less appealing version of the internet is really not such a bad thing. Maybe if developers gave IE pariah treatment it deserves IE users would realize what how awful Microsoft’s browser is and start using good software.
Now, for the future, do you want everybody to go backwards to 1995 and wait for MS, or not? It’s a simple question. ;)
Simple questions usually involve complex answers. ;)
For the future I think we have to look for what is the best we have now and improve it. *But*, in this case, I think some things are not only in our hands, but in browsers developers'. So, let's leave the browser wars for browser makers for a while.
Considering the type treatment, let's see the best we have in browsers and its rasterizers now. IMO, it's Mac OS Safari and Mac OS Firefox. But that conclusion is not enough to reach a big audience. In this case our clients are web designers and authors and they (the serious ones) always considered how their pages work under different browsers and OSs.
IE usage may be falling down in some cases (my site included), but it still strong enough not to be ignored also. Please, do not ask me to define "enough", but >5% would be OK (come on, long tail thinking)
So I think we don't have to *wait* for Microsoft, but *consider* Microsoft and give its users the best they can get.
I'm thrilled for you folk who can ignore IE because most of the Latin script using, design savvy, funky people who visit your own websites use Firefox. My clients have rather different needs.
It is worth pointing out that the biggest use of EOT over the past ten years has been in non-Latin and complex script usage, i.e. in situations where reliance on a couple of ‘web safe’ fonts that could be presumed to be on almost every user's system was never an option. It's a big world out there, and a lot of people are using IE because it supported EOT font solutions for their scripts. [The fact that the biggest use of EOT was in cultures that don't use italic and seldom use bold styled text probably also helps explain why the IE style linking bug has persisted so long.]
>so they tend to pluralise themselves in my head.
Good answer. I like that.
@all on the "IE" Question:
I run into this kind of debate all the time on web dev/design forums. I can't believe what I read sometimes.
When someone says it's pefectly OK to tell 25% of your visitors to take a hike and get a real browser, I just don't know what to say. Something about the concept of "respect", perhaps?
Certainly, there is no big commercially minded site that would dare to ignore IE. Or insult IE6 and 7 users with a truly crappy looking site. You lose money, it's that simple.
Are there significant inconveniences involved in accomodating IE6? Sure. But they're not that difficult to handle. Time and time alone will solve this. MSFT cannot shove upgrades down the throats of its corporate customers.
If tomorrow, by magic, every copy of Firefox on everybody's computer were to be disabled, it would cause a lot of inconvenience, yes.
But if tomorrow IE were to become disabled, many major financial and government instutions would have to shut down until the problem was fixed. That's the difference in the level of responsibility facing Mozilla and Microsoft.
There are those who feel Microsoft could be more agressive in forcing updates and upgrades. I don't buy it. If I was running MSFT (I suppose I could make myself available ;), I wouldn't handle it any differently.
Might as well complain about the weather.
> Might as well complain about the weather.
I couldn't hear you over the hail, howling winds and flying cows hitting the house, what did you say?
N o w it is quiet.
John>I’m thrilled for you folk who can ignore IE because most of the Latin script using, design savvy, funky people who visit your own websites use Firefox.
Safari actually. And I'm still going with the simple majority rules because the IE decline you cite is not an accident, but rather it is a true indication, along with the growth in the number of browsers and OS's, of the public's will. MS has non-standardized too many important fundamental standards in technical and visual ways for a full service foundry to pay attention to their web clients.
John>My clients have rather different needs.
What are those needs John? If you are talking about your custom extra-Latin-glyph-repertoire narrow-style-spectrum font clients? the type designer's whose work you publish? the users of these products? or a particular client[s]?
A thing I'm noticing, is that EOT fans are not broad-based founders in a design sense, a technology sense, and a client sense. And, that 'and' meant all those things... it should be this group for whom true standards are made, no?
John>It is worth pointing out that the biggest use of EOT over the past ten years has been in non-Latin and complex script usage, i.e. in situations where reliance on a couple of ‘web safe’ fonts that could be presumed to be on almost every user’s system was never an option
It is worth pointing out, that web interoperability is a different problem than that which EOT users have adopted it for, or the EOT format was invented for, or that stripped naked version which it is being proposed, for all browsers and all web users — exclusive of all other formats, effectively forever.
> [The fact that the biggest use of EOT was in cultures that don’t use italic and seldom use bold styled text probably also helps explain why the IE style linking bug has persisted so long.]
thanks! ...and that ain't all. The fact that no one has paid attention to this technology means that no one knows what happens when it's applied universally and exclusively to a different problem, until they do apply it.
Maybe you and many others should not only 'consider', but plod this 'web format's' development, deployment and employment. Or do you just want to keep 'steering' and never paddle oh great 'missionary'?
In any case, if'n ya ever steer to land, you'll meet potential converts on one side of the river who appear smaller and darker, and on the other side, the same converts appear taller and lighter. I hope you have some other relics that might be impressive to these natives.;)
@Richard Fink:When someone says it's pefectly OK to tell 25% of your visitors to take a hike and get a real browser, I just don't know what to say. Something about the concept of "respect", perhaps?
@dberlow:And I'm still going with the simple majority rules because the IE decline you cite is not an accident, but rather it is a true indication, along with the growth in the number of browsers and OS's, of the public's will. MS has non-standardized too many important fundamental standards in technical and visual ways for a full service foundry to pay attention to their web clients.
In general, I have to agree with Richard Fink's position.
But not because I think that computer newbies who would not know they could install another browser besides Internet Explorer on their Windows machines deserve respect. That is a bit difficult for me to sincerely repeat.
Instead, I would argue in a more practical fashion.
Like it or not, some people are going to treat their computers as if they were iPads - as locked-up appliances. We may not respect their computer skills, but we can still respect them as human beings.
But even if we don't, we will still like the money they have in their pockets.
So if I'm an on-line retailer, and some font vendor tries to sell me fonts that won't display on IE, I will find another font vendor, because expecting people to use a different browser is throwing away part of my target market, and hence is throwing away money.
If people can't understand that, they're in the wrong business.
Surely the re-appearance of this old chestnut of a thread must mean something, but if I could only figure out what!
(First of all - would the powers that be get rid of the bogus post that brought this thing back to the top of the queue.)
Anyway, for some reason the first thing that came to my mind was that Chrome has surpassed IE in browser share - a thing that, if someone had predicted it back when this thread was news, I would have said "nuts".
AND it also popped unbidden into my head that Chrome in Windows still doesn't use DirectWrite, it uses GDI still.
A happy New Year to all.