Entries tagged ‘web’
Over the past few days I’ve been making some improvements to sIFR 3, resulting in r436. A quick overview of the important changes since r372:
- Now supporting Opera! Playing it safe with Opera 9.61, but there is not much reason to be using older versions.
sIFR.prefetch()has been merged withsIFR.activate().sIFR.callbacks()has been renamed tosIFR.replacements.- Now using ExternalInterface for Flash – JavaScript communication.
- Improved whitespace filtering before passing on the content HTML to Flash.
- Improved CSS Load detection, which is disabled by default, but helps in making sIFR replace elements faster in Safari and Opera.
- Changed how browser and Flash versions are stored in the
sIFR.uaobject. Please consult the changelog for r408 for full details. - Imitating SWFObject behaviour for inserting Flash movies.
Changes since r419 (which saw close to 12.000 downloads):
- Made some improvements to decrease the jumpiness on the page caused by the replacements.
- Dramatically simplified font size calculation, making it more accurate in Internet Explorer, and removing potential issues with IE 8. This also removes the need for specifying
line-height: 1emfor the elements being replaced. - Fixed 2 pixel cut-off from the
leadingproperty (caused by Flash). - Fixed ratio calculation when
leadingis specified. Theleadingis now removed before doing any ratio calculations. - Enabled Flash transparency on Linux with Flash 10, Gecko 1.9 and Opera.
- Font size of nested HTML elements can now be configured in pixels.
- Merged
sIFR-screen.cssandsIFR-print.cssintosifr.css, using the@mediaattribute to distinguish the media types.
There’s still a number of issues left to figure out, although so far I haven’t had any reports of these issues impacting users. For example, I still have questions about how browsers handle Flash movies that are outside of the viewport, I’d like to see if CSS Load detection could be improved, and what’s up with cross-domain Flash movies. These issues all need extensive research and browser testing.
As always, you can get the latest release from the nightlies.
Other useful links:
- sIFR 3 demo.
- Downloads.
- Nightlies RSS feed.
- Twitter.
- Announce mailing list.
- Development mailing list.
- Stack Overflow.
- Documentation Wiki.
These past few months have seen some interesting new developments. Most important of course is the support for Font Linking in Safari 3.1, as well as the upcoming Firefox 3.1 and Opera 10. Finally it’s becoming possible to embed existing fonts on websites, without going through hacks like sIFR or image generation. That said, the current problem with Font Linking is the required redistribution of original font files to web browsers, forbidden by many font licenses. This leaves many typefaces unavailable for embedding. Furthermore, Chris Wilson of Microsoft expressed that Microsoft (and, by proxy, Internet Explorer) should not support Font Linking in it’s current form. Microsoft does have its own EOT format, which it has proposed to the W3C for standardization, and would solve these issues. Mozilla, Apple and Opera however seem opposed to it, mostly out of fears for DRM. I believe these fears are unfounded, for if EOT is DRM, it’s DRM applied by the licensee, not the licensor. It’s like getting an MP3 from Apple and putting DRM on it before you pass it to a friend, instead of getting DRM from Apple preventing you from passing it to a friend. If we want cross-browser, legal font embedding in the short term, EOT is the way to go.
While we wait for cross-browser font embedding, we’re stuck with the alternative hacks. Some new ones have come up recently. FaceLift now seems to be the best way to use images rather than Flash for displaying the font. It uses server-side image generation through PHP, and cleverly provides a hosted service. In the past week Typeface.js came out, which is a devilishly smart way of actually rendering a typeface using <canvas> or VML, though given the complexity of that problem, Typeface.js probably isn’t ready yet for prime-time.
I’d like to point out that these solutions shouldn’t be seen as much as alternative to sIFR – no matter how eager they are to market themselves as such – but as alternative solutions for the real problem: reliable cross-browser font embedding. We’re merely trying to provide the best hack-that-shouldn’t-be-necessary.
That said, I do think that sIFR 3 provides a better solution in being completely client-side, providing actual selectable text, and supporting a subset of HTML and CSS rendering.
I’ve done a few sIFR presentations and workshops in the past few months, most recently at the <head> web conference. Slides are on Slideshare, however the footnotes have gotten lost in an JSON encoding mishap on their end. Therefore, I’ve put up a PDF with notes (17.3 MB). I’m speaking at DrupalCamp CPH, which takes place November 15th and 16th here in Copenhagen.
If you’re interested in a sIFR workshop at your company, or are looking for a weathered web hacker, please get in touch via Supercollider, my freelance alter-ego.
Now, go try out r436, and report back your findings!
Over on the IEBlog, Bill Hill recently posted about Font Embedding on the Web. In it, he discusses how Microsoft has submitted it’s Embedded OpenType (EOT) file format to the W3C for standardization. This could be an important development for web typography, and here’s why.
Web fonts as currently implemented by Safari 3.1, and supposedly supported in Firefox 3.1 and Opera 10, work by linking to the original TrueType Font or OpenType Font files on a web server. For all intents and purposes, this comes down to distributing a font file. In the case of commercial fonts, this is most likely a violation of the license agreement for the font, which means that you, as a web designer, will get your ass sued.
EOT, however, was designed to enable you to use TrueType or OpenType fonts on the web, without getting your ass sued. Quoting from the W3C submission:
Most commercial fonts have an end user license agreement (EULA) which specifies the rights a person who has purchased a license to use the font may enjoy. As the right to freely distribute the font to others is not normally granted, being restricted to installing within a limited set of parameters, there exists a need for a mechanism to allow people who have licensed the font for use with their documents a way to also use the font for their web content without violating the EULA agreement which they have accepted. The EOT file format was developed by Microsoft in cooperation with font creators for just that reason. The technology has been accepted for use by font makers for over 10 years.
EOT respects the flags in font files regarding embedding and can be limited to domains or full URLs. Another important feature is that it is able to compress the font data and lets you pick the glyphs you want to use – resulting in much smaller files than directly linked TrueType or OpenType fonts.
I believe this is a good, practical solution for having real web typography, which performs well and doesn’t violate font licenses. Some steps still need to be taken, obviously. First of which is cross-browser support for the EOT format, which should be in reach if EOT is accepted by the W3C. Another problem with EOT currently is that the software to generate EOT files is specific to Windows. However, given open formats, that’s a problem that can be overcome as well.
As, apparently, with every Microsoft announcement, there’s plenty of Microsoft bashing being done. Most of the bashing revolves around Microsoft pushing another proprietary format, people not being willing to respect licenses on typefaces, and a feeling that commercial fonts aren’t worth using anyway. I’ll let Chris Wilson reply to this:
As I also stated to the WG – I don’t personally even care that much if that system is EOT as it is today; I’d be okay with building a new system if the details of EOT were a sticking point. But I want to use commercial fonts on my web pages, I want that to work interoperably across browsers, and I want to not have to violate my license for the fonts I use (and get sued for it) in order to make that happen. A solution that only works for freeware fonts is not a solution.
So. The good news is that IE8 will be much, much better than anything before it. The bad news, Microsoft doesn’t dare release it and make it render existing websites, because there’s no way they’re going to render properly. Why? Because of the browser specific hacks put in to make the site render properly in IE6/7.
A “kill switch” is proposed, which will cause websites to render in the new or updated engine, whilst not breaking existing websites relying on IEs quirks.
Fair enough.
Except that, what if insert <meta http-equiv="X-UA-Compatible" content="IE=8" /> into this website? IE6/7 won’t recognize it, so I can’t really rely on the new CSS support in IE8. In fact, conditional comments are going to be needed so I can load the IE6/7 CSS, and the IE8 CSS, depending on the user agent.
Clumsy, but possible.
The really interesting bit is going to be a few years from now, when IE9 is released. Will I have to insert <meta http-equiv="X-UA-Compatible" content="IE=9" />?. What’s IE8 going to do with this switch? And how different will IE8 and IE9 be? Perhaps I’ll need to conditionally load CSS for IE6/7, IE8 and IE9.
And then IE10, IE11, et cetera…
Seems to me this meta switch is quite reasonable, as long as it kills off the old Trident engine, and activates a proper engine which sees continuous improvement. Much like, you know, modern browsers.
January 26th, Jeremy Keith describes the issue much better than I’d have the patience for. Recommended reading
- Let browser vendors innovate as fast as they can
- With the end-goal of interoperability through standardization
- Increasing pressure on other vendors to interoperate, since there are actually four major vendors now, which are all important to most developers
And thereby a better world can be had.
Case in point: Incredibly useful features that used to be IE only, but are now being standardized and implemented by other vendors, such as XMLHTTPRequest, getBoundingClientRect, getClientRects, innerHTML, contentEditable and support for XML/XSLT. Uhm, that basically explains why Xopus is still very much IE oriented – despite all its problems.
Addendum: Proprietary web development with the purpose of standardization is much better than proprietary, period. The latter is inevitable, so what do we do about it?
Christian Heilmann of the DOM Scripting Task Force published a long article called From DHTML to DOM Scripting today. In it, he claims that DHTML is awful and outdated and generally very bad, and that DOM Scripting is the second coming of Zarquon.
Okay, that was slightly exaggerated. Yet this line of thinking annoys me. DHTML is, like HTML before it, painted in a bad light, whereas XHTML and DOM Scripting are purportedly the best (and therefore only) way ahead. When you look more closely at the practices so easily associated with XHTML and DOM Scripting you see a different picture. Quoting from the weblog post:
DOM scripting assets:
- Progressive Enhancement – check if things are available, then apply those dependent on them
- Ease of maintenance – keep the maintenance as easy as possible via dynamic CSS classes and properties at the beginning of the script
- Separation of Presentation and Behaviour – add dynamic classes instead of changing the style collection
- Separation of Structure and Behaviour – use dynamic event handlers and generated elements instead of onclick and NOSCRIPT
- Using modern event handling – more than one onload please
- Avoiding clashes with other scripts – avoid global variables and encapsulate functions as methods in an object
That sounds quite reasonable. In fact, I’d say these are all very good programming practices, regardless of being used in “DHTML” or “DOM Scripting” scripts. The problem is that DHTML, and all of it, is being blamed for blatantly ignoring these practices. I consider myself to be a DHTML programmer – heck, I learned most of my stuff at the now dead DHTMLCentral – and yet I grew up to these practices. While I am aware of the type of DHTML hinted at by the DOM Scripters, virtually all of the provided scripts on DHTMLCentral fit the description, it’s not the DHTML I, and many others, know and write.
Seeing DHTML portrayed as evil pains me. It does not deserve to be used as a straw-man for good practices. I believe good practices should stand on their own merit, and the ones the DOM Scripting Task Force attempts to spread are perfectly capable of doing that.
Dear DSTF,
I applaud your effort to bring JavaScript into a better light, and teach people how to write scripts following best practices. However, I am worried that your focus on unobtrusiveness and best practices will result in less attention for code quality.
A recent example of this is your post about Image Previews. While the script you link to is certainly unobtrusive, I don’t think it’s a good example of code quality, or for that matter, DOM scripting.
I won’t complain about the coding style of the JavaScript, that’s entirely personal. (Although some more whitespace can’t hurt.) No, one of the problems is that the script, written by one of your members, even, does not use DOM events. For a script linked to from your weblog I find that disturbing. Another, and perhaps worse, issue is that the script leaks memory.
Things like memory leakage can be hard to grasp, but it’s fundamental that DOM scripters understand these problems and work around them. Promoting a script which does not use DOM events is giving the wrong example. By all means, link to a great unobtrusive script, but in that same post also point out what could be improved. Please check the code quality of the scripts you link to: people will try to learn from the code and it’s important they learn it correctly.
If all goes well, you’ll be a huge influence to many new developers. Let’s get the max out of that influence.
Kind regards,
- Mark Wubben
P.S. I realized during writing this letter that the script in question was written by and about by Christian Heilmann, one of your members. Please understand that this post is not meant as an attack on Christian, but as an expression of my worries. Again, I applaud you for your efforts.
When I wrote my short tutorial on how to use the DOM for :hover I tried to point out something else. It was between the lines, and the post was written in a hurry, so I suppose it didn’t caught much attention.
Basically what the JavaScript did was look for events so it could set a different class on the elements. Effectively, mouseover set the state of the element to “hover”, while mouseout set it to “none”. In other words: I wrote code to manage the state of the element, and the style of the element in that specific state is controlled via it’s class.
Thus, a.hover becomes the equivalent of a:hover.
This turns out to be key in understanding why CSS doesn’t define behaviour. The pseudo-classes are a special kind of classes, which aren’t set by some JavaScript code, but by hidden, low-level code in the browser. The browser manages state, detects you have placed the mouse pointer over the element, and styles the element following the rules in the applied pseudo-class [1].
Unfortunately Internet Explorer doesn’t support this behaviour for elements other than a. We need to write high level JavaScript code to manage the state. And since we can’t use :hover to style these elements, we need to use our own class.
This doesn’t mean, however, that CSS is behavioural. Nor does it mean that we should shy away from using :hover, because there are browsers out there which aren’t capable of managing the state of elements internally [2].
Footnotes
[1]: Of course this not only applies to :hover, but also to :active, :link, :visited and :focus.
[2]: Or, more likely, aren’t capable of exposing this state.
