BurningbirdWeb technology
Recovered from the Wayback Machine.
I have Windows XP SP3 installed on my Dell I was therefore more than a little taken back about the instructions to follow to install IE8 beta 2:
If you don’t follow this path, you’ll have permanently installed IE8 on the machine. You know, you can’t make up stuff like this.
Looks like someone forgot to pay the domain renewal fee at Weather Underground:
update
The Weather Underground issued the following statement:
Hello Wunderground users. We first want to apologize for the connectivity issues that many of you are or have been experiencing. The problems were caused when someone at our domain name registrar inadvertently made a change to our domain name record. This essentially means that in the yellow pages of the Internet, they got our address wrong. Most people were left unable to the find our site and were instead presented with our registrar’s default page.
We’ve been working frantically here trying to do anything we could to minimize the damage. We’ve just received word that in about 2 hours most of the connectivity should be restored thanks to some quick work by our registrar. In the meantime if you’re in contact with individuals who cannot access the site through the wunderground.com domain name, please let them know that they can still access the site through weatherunderground.com.
Amazing how vulnerable we are to a slip in the DNS, eh?
With the addition of support for color profiles built into Firefox 3, it’s time to take a closer look at how the popular browsers support color management. First though, a quick refresher on the importance of color profiles.
If you’ve every worked with a photo in a photo editor, only to have the rich colors leach out when the photo shows in your web page, you’ve run directly into what happens when your editor supports color profiles, but the browser does not. Color profiles are a mapping between device and color space, in such a way that a photo that looks richly colorful in Photoshop, still looks richly colorful in your browser, across multiple operating systems and devices.
The following are two sets of photos, each incorporating different color management. The first in the series shows the photo as I would normally create a photo for publishing on the web: I’d calibrate my monitor, set the gamma half way between PC and Mac, and then set my tool’s color space to the LCD. Then, when I work with the image, the result I get will end up looking relatively decent in both Macs and PCs. The second photo in the series hasn’t been manipulated at all. The third was created after I set the photo editor’s color settings to sRGB, and then converted the photo to this color space. When I saved the photo, I incorporated the color profile.
The first sequence of photos are screenshots taken when the photo is loaded into Firefox without color management. Though a screenshot doesn’t necessarily capture the nuances of color, I think you can see that the color of the last photo from the first sequence of three differs from the color of the last photo in the second sequence of three, which consist of screenshots from Safari 3.x, which does have built-in support for color profiles.
The following are the actual photos used for these screenshots. The first shows the photo without any color manipulation and not using color management.
The second photo was made using my old LCD color trick.
The last photo was not manipulated in the photo editor, other than to scale the image. The sRGB color profile was embedded into the photo. I could have also embedded the Adobe RGB color profile, but I stayed with the popular sRGB color profile.
If you look at this page using a browser that doesn’t support color management, the first and third photos should be very similar. However, if you look at the photos using Firefox 3 with color management enabled, Safari 3, or other browser or device that supports color management, the last photo should appear more colorful than the first. To get an even better idea of the color variations, the following are screenshots of color swatches in a web page— opened in both a color managed browser, and in a browser that doesn’t support color management. The difference should be noticeable.
Currently, I know of only a few browsers that support color profiles: Safari 3.x, in both Windows and the Mac, supports color management; supposedly Omniweb also supports color management, as did the older version of IE for the Mac (IE 5.5), though I’ve not tried either tool. Now, Firefox 3 supports color profiles, but not without a caveat: color profiles are disabled by default.
The reason Firefox 3 is releasing without color profiles on by default is primarily because of performance issues. Turning on color management in Firefox 3 can really slow load times of a site that uses color profiles embedded in pictures, especially larger pictures. In addition, according to John Resig there are some real concerns about plug-ins, such as those for Flash and Silverlight, that don’t do color profile support, and which can lead to incorrect renderings.
I can understand the issues, though I am disappointed. Support for color profiles with Firefox 3 would go a long way to encouraging color profile support in other browsers. I hope that Firefox 3.1 works through the performance issues and we get support for color profiles by default. You can still take advantage of color profile support in Firefox 3, now, but you either have to set a custom option using a less than friendly procedure, or make use of a color management add-on.
Do I use embedded color profiles in images at my site? I have started to, though not across all sites. If I use color management, I won’t use my LCD trick, which means that the photo won’t look as good for those people using browsers that don’t support color profiles. At the same time, I would really like to encourage better graphics support in our browsers, which means using the functionality we want the browsers to support. We’ll never progress if we keep designing for the lowest common denominator.
For more on color profiles, check out the International Color Consortium web site.
Recovered from the Wayback machine.
Again, I congratulate the browser teams who have passed the Acid3 and have only one more thing to say:
Don’t ever do that again.
I’m right in the middle of going through the proofs for Painting the Web, and I’m having to make proof modifications to code and writing because both Safari and Opera are feverishly changing their source in order to “meet” the Acid3 test. However, I don’t know, for sure, if all the changes will end up in the next released version of the browsers, or if they’ll be shunted off as a branch for inclusion in a later browser version after further refinement.
A better approach would be to list out all of the Acid3 tests and create a roadmap of planned implementation, ie the functionality in test 1 will be included in Opera 9.5, the functionality in test 2 in Safari 4.0, and so on. It may lack the glamour of displaying a passed test results, but it plays less havoc on those writing documentation, testers, book writers, and other people who have ended up being tossed about, like so much flotsam, by the Acid3 hurricane, and are now feeling particularly bruised and battered.
Please don’t do an Acid4. I don’t know if I can survive it.
Recovered from the Wayback Machine.
WordPress 2.5 has released, including the bad markup generated with the Gallery option. If you serve your pages up as XHTML, the gallery won’t work for you. You will get invalid markup errors, the page will fail to load. Whether this can be fixed with a plug-in or not, I don’t know.
I’ve been told that if I don’t like the code, shut up, and *fix it myself. Leaving aside the “shut up” part, the issue isn’t just one problem in one piece of code–it has to do with a mindset. Last time I looked, you can’t submit a bug patch to change a mindset.
I did turn in a bug about the Gallery markup, and really did expect it to be fixed. Two people involved in WordPress 2.5, Jeffrey Zeldman and Matt Mullenweg have professionally benefited by their association with WaSP and the standards movement. If I seemed harsh in my previous writing on this, it is because I really did expect better from both Jeffrey and Matt. I think, though, my expectations don’t match today’s reality. Today’s reality is XHTML is out, HTML5 is in. HTML5 is much more marketable. HTML5 is sexy, HTML5 is hot, HTML5 sells.
I know many of my readers are tired of me bringing up standards and XHTML. On and on–I have become dull with repetition. Heck, I’ve just become dull. Several people have pointed out the draconian error handling of XHTML, how HTML5 is friendlier, and will “make things better”. HTML5 will make the web more “semantic”. HTML5 is the way of the future.
How can the web be better, though, when people who do know how to create valid web pages, choose to not do so because frankly they just can’t be bothered? How can HTML5 make the web more meaningful, when it can’t even guarantee something as simple as accuracy of syntax? As the spec is now, HTML5 is also a closed box, with no way to add something new, something different. With XHTML, I can add SVG, or RDF, or NextBigVocabulary, or ShelleysSecretSauceVocab, and it works, out of the box. You can’t do that with HTML5. Is HTML5 really a way forward? Or just a way for application developers to continue dishing out crap–but gee wiz, look, you can store data on the client now. And if you make a mistake, you won’t kill kittens, because goodness knows, every time Firefox displays the Yellow Screen of Death, God kills a kitten.
I once before referred to today’s attitude about standards as being a race to the bottom. I made this statement because standards support is seemingly a thing of the past, a quaint relic of a previous web generation. The new web, the 3.0 web, the semantic web can’t be bothered with the old, the measured, and the fusty, when now is a time of quick ideas and even quicker implementations. Open Social! Open Data! Microformats! All you need now, is an idea and an audience. It doesn’t have to be a good idea, either, but it does have to have a big audience.
It is what it is, and I don’t have enough audience to impact much beyond my immediate vicinity. Thankfully for the riders of tomorrow’s web, when they do reach the bottom, HTML5 will be there, waiting for them. And who knows, I could very well be all wrong about all of this. Rather than a race for the bottom, perhaps this is a race for a baseline, and I just perceive the baseline to be less than what I think it can be. Perhaps I do reflect an era that is dead and gone and either I should adapt to move with the tide, or get out of the boat.
Well, I’ve not been particularly good at floating with the current in the past, so the only option for me is get out of the boat–or at a minimum, go find my own boat to row. I am going to do the WordPress folks a huge favor: I won’t continue using WordPress, no matter how pretty the new look, or how cool the new features. The WordPress developers have made too many decisions about how I should run my site, including HTML5 over XHTML, microformats over RDF, the canvas element over SVG, and so on. I find I just don’t want to follow the course they’ve deemed appropriate for the future. Or, to continue my nautical metaphor, we’ve reached an equatorial point, and WordPress wants one horizon and I want another and now, regretfully, we must part.
I am not unmindful of how much I owe the WordPress team for an application I’ve benefited from for several years. To the WordPress team, my sincere thanks for the use of your application, and your hard work in the past. WordPress has been both fun, and useful. Good luck with your future voyages.
*If you want to use the Gallery yourself and you serve your pages up as XHTML, you can fix the gallery page so that it doesn’t break in the browser with this PHP file. Just rename it to media.php and overlay the one in wp-includes. You’ll also have to turn off automatic entry formatting, too, because WordPress will insert paragraph elements erroneously. The Text Control plug-in will help you with turning off auto formatting, and it works with WP 2.5. The generated layout also plays havoc with IE8, at least with my layout. Your mileage may vary.
The generated markup still isn’t valid because of adding a stylesheet into the gallery within the page body, but with the changes I just detailed, at least it doesn’t kill a kitten.