The book draft is finished, and it's time to wrap up the lessons I've learned while writing.
I love web graphics
I love web graphics. I always have, and always will. I make no pretense to be an expert, or the best. You'll not find me in lists of people known for either their web designs or their use of web graphics; nor for photography, art, or virtually any other creative category. This doesn't lessen how much I enjoy working with both the concepts and the tools, or with trying out new things.
For everything I write, here or in the book, there will be people saying I could have done it better. They will, most likely, be right. We will then have the added advantage in we'll all learn something new, or a better way of doing things.
Regardless, nothing will change my enjoyment with working with the tools, technologies, and specifications, and trying to pass along my own sense of joy and wonder to others. That's the great thing about creating for the web: no one can get in your way and tell you that you're not good enough to have an audience.
Web Graphics are a Whole Brain Activity
Popular learning theory assigns behaviors to one hemisphere of the brain or the other. One hemisphere, typically the left, is responsible for analytical thinking, communication, problem solving, while the other hemisphere is responsible for creativity, including art and music. One would assume, then, that web graphics are a right brained activity, since it involves creativity. However, web graphics is a whole brain activity, because the field is not limited to just the purely creative. Science, logic, and problem solving are just a important to the field of web graphics.
The book covers such things as creating for the web, including photos, graphics, and web design. These are topics one would expect to find in a book on web graphics. It doesn't end with with the purely creative, though. The book also covers the use of tools to do these activities, including many that require some exposure to the Linux command line, or programming with PHP and JavaScript, not to mention specifications such as CSS and SVG.
The use of SVG, which is an XML-based format is just as important to web graphics as being able to draw a cool swirl, knowing what colors work best together for a web page, or how to take a great photo and post it online. There is no separation between the mechanics of the web space, and the creative elements of art: web graphics encompasses both.
Of course, this philosophy plays havoc with defining the audience for the book.
We have such wonderful tools
There are so many ways to create web graphics, from Photoshop to ImageMagick. Some of these ways are dependent on specifications, including ones such as SVG that has had limited early support.
I have used SVG in my site, and will continue in the future, not just because I'm enamored of the specification, but because there are three important parties associated with any specification: the originators of the spec, the implementers, and the users. The implementors won't know that their implementation of the specifications are incomplete if we don't use the specification to discover the problems, and then submit the problems as bug reports.
Speaking of specifications…
Freezing Specifications
Not long ago, a discussion broke out about Chris Wilson from Microsoft making a suggestion about "freezing' effort on ECMAScript 4, until all the players had caught up implementing the existing version. This somewhat echoed what Molly Holzschlag wrote about freezing discussions on HTML5 and XHTML 1.1, until all players had caught up with the existing specifications.
There is some validity with this point of view. After all, what good does it do to continue to make progress on new specifications when the relevant players are inconsistent with meeting the needs of existing specifications.
As was pointed out in those discussions, though, and repeated here: progress on new versions of specifications does, in no way, prevent anyone from meeting the requirements of existing specifications. If anything, attempting to freeze development of specifications could be seen more as a way of holding others back, while one company or another progresses in doing its own thing. Whether there is truth to this or not, the perception exists, and so it's best to let the specifications continue to grow, and demand that implementors at least make a reasonable attempt to keep up.
Which leads to…
IE Must Catch Up
I couldn't believe when I finished the book, how many times I had to enter a caveat about Microsoft's IE in all of the chapters. From support for PNG to support for CSS, SVG, the Canvas element–it seemed as if there were two worlds in web graphics: the one where Safari, Opera, and Firefox lived, and the one where IE lived, so far behind the others that the situation becomes almost laughable. Laughable, except when trying to create sites to work cross-browser, and being handicapped, at every step, by this albatross of a browser.
The program manager may brag about IE's security features but I would say the reason it gets less support calls because fewer people, every year, are using IE. Rightfully so, too, because it really is a silly little piece of software.
I, however, don't blame the creators of IE. After all, Microsoft is a company that specializes in lock-in, and why waste time on open specifications when it can create Silverlight and lock people into its own proprietary standards? Obviously, pride in one's products is not an overly important corporate imperative at the company, so one can't blame the IE team for putting out such a foolish little piece of crap.
No, I put the blame more on the Microsoft supporters: the VB fanboys and girls; the MVPs; the .NET groupies. You are the ones who could really push Microsoft to get its act together and catch up to the other browsers. Instead, you treat Silverlight and .NET like they are gifts from heaven; more boards from which to build your club houses.
Which leads to…
Open Specs
The book does not cover the proprietary specifications such as Silverlight or Flash. Flash helped provide an interactive environment while we battled out the early cross-browser wars, but in doing so, it probably helped delay full specification support in all of the browsers. The current Flex version may be nifty and sweet for Adobe, but it is an Adobe creation, and frankly, I get tired of buying each corporation's view of the Way We Should Do Things.
There was no reason for Silverlight, none at all. If a version of IE was out that implemented SVG, the Canvas element, was fully CSS 2.1 compliant, implemented the current ECMAScript version, and above all, supported XHTML, than yes, Silverlight makes sense. It makes no sense when IE is so obviously deficient in so many ways.
Even now, you can't search on anything to do with the Canvas element, because Microsoft called its element 'Canvas', and has tainted this term in search results. No one can tell me this wasn't done deliberately.
But, IE's time will come….
Full spec support by 2010
I will no longer compensate for limited or broken specification support in browsers after January 1, 2010. This gives IE, and the other browsers, time to fully implement all of the specifications that have been out as recommendations for years now. This includes support for XHTML 1.1, CSS 2.1, SVG 1.1, in addition to any other specification not listed. This isn't part of a movement, and there is no badge. This is just my personal choice that I will no longer compensate for browsers not implementing standards, beginning January 1, 2010.
I read the post about transparent PNGs with IE 6 and thought of my own recommended workarounds scattered through the last three books I've written, most having to do with IE. At the same time, I've seen Microsoft spend time on specifications such as Silverlight, and something snapped: no, no more.
I will design my pages to take advantage of all of the specifications currently in recommended status, and if the page is no longer viewable by a person using IE (or other browser, if it comes to that), so be it. I may lose audience, and I may frustrate people, and piss others off, but there has to come a time when you hammer a stake in the ground and tell yourself and the world, you'll go this far, and no further.
For over 10 years now, I've written on cross-browser issues, and published books detailing how to compensate for multiple browsers, and think to myself: how much more could I have done if I didn't have to spend so much time compensating for the tools delivered by companies, who frankly don't care?
I will continue to compensate for another two years, which will give such companies time to catch up. If they don't, and if people still continue to use these broken tools, well, I figured my bandwidth costs will drop, if nothing else.
Now that I've managed to chase away several potential customers for the book…
Speaking of books
We know the book will have a main title of "Painting the Web". We're not in agreement on tagline. I preferred, "Painting the Web: Explorations in Web Graphics", but the marketing staff wasn't too happy about the use of 'explorations', so we're still negotiating that part.
Whatever it ends up being called, this is, most likely, my last book.
