6 ms·
If you want to use CSS3 tools, even those that are widely supported across browsers, you often have to code up the same effect 3/4/5 times with slightly differe
by sid0 15y ago
If you want to use CSS3 tools, even those that are widely supported across browsers, you often have to code up the same effect 3/4/5 times with slightly different syntaxes.
Or you can wait a little until the standard goes through and the syntaxes are unified.
If you want to use HTML5 elements, even just the simple semantic ones, you need to incorporate backward compatibility fixes for IE before version 9 (which is a very substantial chunk of the browsing public, since WinXP only goes up to IE8).
The target is not the browsing public -- it is your audience. For instance, a site for hackers really doesn't need to support IE<9.
I agree with the <video> problem for sure. There are philosophically and commercially opposed interests involved there.
Firefox still doesn't get basic font rendering right on a lot of platforms, and the current version can't even look up locally installed fonts properly
Could you cite or give examples of these?
Obviously things are still in flux, but we've all learned to deal with bugs in software. We know our own code isn't immune to them, so I think it's too much to expect the platform we're building on to be immune to them either. I don't think bugs reflect negatively on the web standardization process, though.
- Silhouette 15y ago> Or you can wait a little until the standard goes through and the syntaxes are unified. The trouble is, the current standardisation processes are far too slow to be practically useful, while the breakneck pace of experimental feature development is too fast to keep up, so there is no useful definition of "a little" in your suggestion that we can use for planning new web projects and making decisions about which technologies we will rely on. > There are philosophically and commercially opposed interests involved there. It also doesn't help that both sides throw out FUD as if it's going out of fashion, and that some of the (acknowledged) patent encumbered formats are technically far superior to the (possibly) unencumbered ones. That means until either the software patent madness is fixed or organisations like Mozilla start putting up hard cash, their integrated video functionality will never be as good as what you can get in something like IE (or, apparently, Chrome, since Google seem to have quietly dropped their policy of discontinuing support for H.264). > Could you cite or give examples of these [font bugs in Firefox]? On Windows systems, the kerning is very odd in a lot of fonts since they moved to the new rendering engine a while back. The spacing following a capital T is usually way too tight, and in some fonts there are a few other examples as well. This can render pages completely illegible at typical body text sizes. Also, take a Windows 7 computer with a few Adobe professional OpenType fonts installed locally -- probably some that come with Creative Suite would do -- and just try selecting those fonts using CSS in recent versions of Firefox. It simply doesn't work and falls back to the next font family in the list, though the same page will find the fonts and render quite happily in other browsers on Windows 7, or in the same version of Firefox on Windows XP for that matter. Most currently available web fonts also seem to look terrible (poorly hinted, terrible aliasing) on Windows XP in Firefox, but since they don't look great in other browsers either and they look better in Firefox on Windows 7, I'm inclined to point the finger more at Windows XP than Firefox in that case.
- sid0 15y agoThe trouble is, the current standardisation processes are far too slow to be practically useful, while the breakneck pace of experimental feature development is too fast to keep up, so there is no useful definition of "a little" in your suggestion that we can use for planning new web projects and making decisions about which technologies we will rely on. If you're starting a new web project today, you look at what technologies the browsers you're targeting already support with unmodified syntax. (I'd argue that that development model's a poor fit for the web, but that's a different question.) On Windows systems, the kerning is very odd in a lot of fonts since they moved to the new rendering engine a while back. The spacing following a capital T is usually way too tight, and in some fonts there are a few other examples as well. This can render pages completely illegible at typical body text sizes. That is an artifact of ClearType subpixel positioning. Firefox 7 or 8 onwards (I don't remember which) turn subpixel positioning off for several commonly-used fonts, listed in gfx.font_rendering.cleartype_params.force_gdi_classic_for_families. Also, take a Windows 7 computer with a few Adobe professional OpenType fonts installed locally -- probably some that come with Creative Suite would do -- and just try selecting those fonts using CSS in recent versions of Firefox. I have a feeling you're choosing the font incorrectly. Note that with DirectWrite, any weight modifiers ("semibold", "black", "light") aren't part of the font name any more. Instead you need to specify weight using the font-weight property. So instead of saying Arial Black as you would normally, you need to say Arial with weight 900: http://www.neowin.net/forum/topic/971376-firefox-displays-my-site-incorrectly-other-browsers-fine/page__p__593634608#entry593634608 http://www.neowin.net/forum/topic/971376-firefox-displays-my... This is not a bug, though -- this is correct behaviour. Most currently available web fonts also seem to look terrible (poorly hinted, terrible aliasing) on Windows XP in Firefox, but since they don't look great in other browsers either and they look better in Firefox on Windows 7, I'm inclined to point the finger more at Windows XP than Firefox in that case. That's because most downloadable fonts aren't hinted for ClearType. DirectWrite with its subpixel positioning can cope much better with unhinted fonts.
- Silhouette 15y ago> If you're starting a new web project today, you look at what technologies the browsers you're targeting already support with unmodified syntax. (I'd argue that that development model's a poor fit for the web, but that's a different question.) If we really did that, we'd be back in the land of HTML4 and CSS2.1 and, ironically, Flash and Java applets. I think the reality for most projects today is that we make a decision about how much portability pain we're willing to accept in return for using newer technologies to alleviate other pain such as making yet another set of rounded corner graphics, and we make a decision about how much degradation in the user experience is acceptable for older browsers that don't support whatever non-portable technologies we choose to adopt. This is a far cry from what web standards should be, of course. > That is an artifact of ClearType subpixel positioning. That may be so, but the fact is that for several months lots of people using Firefox will have had difficulty reading lots of sites that worked perfectly well in older versions of Firefox and still work perfectly well today in other browsers (which makes me very suspicious of pinning the blame entirely on ClearType, BTW; no other software on these PCs has any trouble displaying those fonts). If you're going to cause that kind of regression, then IMHO a policy of trying to force all of your users to update continually and ignoring the needs of those who can't or won't is inappropriate. Particularly in a security-sensitive application like a web browser, I think forcing users to choose between recent versions with vulnerabilities patched or old versions that actually did their job properly is irresponsible. After all, isn't this one of the reasons plug-ins are supposed to be Very Bad Things? > I have a feeling you're choosing the font incorrectly. Given that there is no standard specification of how to choose fonts like this, I think that's perhaps a rather bold claim to make (no pun intended). (Go ahead, check any W3C recommendations you like, you won't find it. In fact, the CSS2.1 Recommendation specifically acknowledges the variations in things like font weights between different families. It also provides no specific advice on naming conventions for font families at all, because what would you say that makes sense anyway?) Again, it doesn't really matter though, because the point is that it worked on every other browser. Whether they are tolerant and Firefox is correct or they are correct and Firefox is broken doesn't change the end result. > That's because most downloadable fonts aren't hinted for ClearType. DirectWrite with its subpixel positioning can cope much better with unhinted fonts. Sure, but hundreds of millions of people are still browsing with ClearType, so I think trying to get professional sites to use web fonts that look rubbish in comparison to tried-and-tested screen-optimised fonts like Georgia and Verdana is one of those "Oooooh, shiny" policies that is more driven by hype than substance. And for the record, a lot of the fonts available on the commercial font rental services render poorly even on high-resolution screens using the latest browser versions on Windows 7. I suspect the font services and foundries are banking on higher-res screens of the kind we're seeing on the latest smartphones making the need for traditional screen-font hinting obsolete. But this is drifting off-topic so I won't follow that avenue any further.