Category: Technology

Categories
Technology Web Weblogging

WordPress 2.5 releases

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.

Firefox's YSOD kills kittens

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.

Categories
Technology Web

IE8 and breaking the web

Recovered from the Wayback Machine.

Another break between IE7 and IE8 is the support for opacity.

In previous versions of Internet Explorer, Microsoft used its own custom filters in order to implement opacity. This has been known for some time and libraries manage opacity for old and new browsers by using code like the following, in JavaScript:


// cross-browser adjust opacity function
function setOpacity(obj,val) {
  obj.style.opacity = val;
  obj.style.MozOpacity=val;
  obj.style.KhtmlOpacity=val;
  val*=100;
  obj.style.filter = "alpha(opacity="+val+")";
}

It’s a trick that takes advantage of JavaScript’s dynamic prototyping to “set” any possible combination of opacity properties, including the CSS3 opacity, the older Mozilla opacity, as well as IE’s opacity filter. Of course now, we can pretty much drop anything but the CSS3 opacity, and the IE filter:


// cross-browser adjust opacity function
function setOpacity(obj,val) {
  obj.style.opacity = val;
  val*=100;
  obj.style.filter = "alpha(opacity="+val+")";
}

This will work with IE6 and IE7, but not IE8. The reason why is that Microsoft dropped implementation of a proprietary functionality called hasLayout, which the company’s opacity filter was dependent on (at least, that’s what I’ve read). This is good, because hasLayout is a Bad Thing.

Unfortunately, this also “broke the web” in that Microsoft, in IE8 beta 1 at least, didn’t bother to replace the now missing opacity filter with support for the CSS3 opacity filter. True, CSS3 isn’t a “released spec” yet, but every other browser–Firefox, Safari, and Opera–supports CSS3 opacity.

I’ve explored the online discussions related to IE8 and opacity, and there are rumors that the long handled Alpha opacity filter will work, but I’ve not found that this to be true, and I’ve not found anything at Microsoft on a workaround.

At this time, and to the best of my knowledge, to get opacity to work with IE8, you’ll have to add the IE compatibility meta tag:



<meta http-equiv="X-UA-Compatible" content="IE=7" />

You put this meta element right after the title element. Of course, you lose the “good” standards stuff that comes with IE8 if you do this. It’s a damned if you do, damned if you don’t situation: either opacity doesn’t work with IE8, or you lose the stuff that does work correctly with IE8.

I’m also finding another problem with IE8: adding an onclick event handler to a DIV element seems to only be sensitized to whatever content is in that element, not the element itself. So if you have centered text in the DIV element, only the text is sensitized to the onclick event, not the entire block.

This impacts on many Ajax applications, including most accordion functionality, and not just on mine. For instance, Rico’s Accordion widget doesn’t work with IE8 if the person clicks anywhere but the text. To recapture this functionality, you’ll again have to use the compatibility meta tag.

Categories
Web

Grace in winning

Now, this is what I hoped to see when the Acid3 test was first announced. Not the macho posturing I saw yesterday.

The WebKit folks published a writing at the Surfin’ Safari site that details the challenges met by Cameron McCormack associated with the last test. To me, the story is a fascinating look into browser development. I hope we can see something similar from Opera about that organization’s own effort.

I particularly like, and want to highlight, the writing at the end of the post:

Web standards can often seem boring compared to super fast performace, whizzy new features, and even the basic Web compatibility work of making sites work properly. Interoperability is critical to the Web as an open platform, but it can be difficult to explain to regular users why it’s so important. The Acid tests make web standards fun, for browser developers, for Web designers, and for regular users. Whatever the intrinsic value of the tests may be, I think we should all thank Ian Hickson and all the test contributors.

I’d also like to thank Opera for giving us some serious competition and making this a real horse race. We have huge respect for their developers and all the work they do on Web standards.

As for Firefox 3 not “passing” the Acid3 test, I’d rather hear Firefox explain its future development goals such as when it plans on incorporating SVG animation and text-shadow and the like, than having to worry about the test. The test brought about awareness. We’re aware. Now, let’s move on.

It’s with relief that I can now say congratulations sans any reservations to WebKit/Safari and Opera. Below is my first 100/100 snapshot, using the WebKit nightly on my PC.

update

And Opera’s result, using the special Windows build:

(via Anne, who hasn’t quite decided to move on from yesterday’s querulousness, albeit defense of a friend is noble.)

Categories
Web

Google’s excanvas only works in quirks mode for IE8

Recovered from the Wayback Machine.

I’m in the process of proofing Painting the Web, including testing all of the examples with the new IE8 beta. Yeah, fools rush in where angels fear to tread.

I was frustrated that all of my canvas examples weren’t working with IE8, even if I picked IE7 emulation mode. From a Google group I discovered that if I used quirks mode (ie, removed the DOCTYPE), the applications do work in IE8 and in IE7 mode, both. (Well, some of the applications–but at least I see some of the pieces with the ones that don’t work.)

I tried the meta tag and using IE7 strict mode, but it doesn’t work, though it doesn’t break as badly as IE8 standards mode. You see a box where the canvas rendering should be.

So, what this demonstrates is that Microsoft is dropping support for VML, but hasn’t implemented the HTML5 canvas element. More importantly, Microsoft doesn’t support VML in strict mode even if you’re running in IE7 mode. Jay-sus Microsoft, could you possibly leave things in worse shape?

However, further checking finds for us a Silverlight version of excanvas.js. Well, we knew that one was coming. Still, the problems with using Silverlight is that your page readers have to install Silverlight. Previously, all of the effort to translate canvas to Microsoft speak occurred without the reader having to install anything. This is a better approach that we no longer have. In addition, I don’t believe that Silverlight works with IE6, though I don’t know for sure, since I don’t have IE6 to test.

More importantly, this new JavaScript library works in IE7 emulation mode, but is pretty buggy in IE8 standards mode, though at least it works in Strict not Quirks. And, as long as you name the JavaScript files differently, you can include both JS libraries, which should enable the canvas applications to work with IE6. I don’t have access to check this out with IE6–I’m just making a guess. Having both libraries doesn’t break IE8, whether as IE8 or IE7 emulation. I don’t know if having both will break IE7. The real IE7.

Who’s on first?

Jay-sus Microsoft.

update MS does still support VML, I tried out a couple of pages that use VML directly and they work. The problem is in the excanvas.js library, then. It should work in IE7 emulation, because the examples did work with IE7. However, it doesn’t unless you also serve up the application in quirks mode (with no DOCTYPE).

I tried an SVN snapshot version of excanvas.js, the older one that’s still being developed, but it’s worse than the released version. However, that doesn’t mean that there won’t be a release of the non-Silverlight excanvas that will work with IE8 at some point.

Until then, currently:

The released version of excanvas.js only works in quirks mode for IE8, including running IE8 in IE7 emulation mode. Using the new meta tag doesn’t work, unless I used it incorrectly. I’m assuming one would use the following:


<meta http-equiv="X-UA-Compatible" content="IE=7" />

Do I have that wrong?

The Silverlight version of excanvas.js works in IE8 standards, and IE7 strict mode, but it’s not released yet, is still under development, and requires your page readers to install Silverlight. In addition, I don’t know that this library works with IE6.

I have included both in web pages, and assume one can use IE6 conditional statements to wrap the non-Silverlight option to ensure only IE6 picks it up:


<!--[if IE 6]>
<script type="text/javascript" src="originalexcanvas.js">
</script>
<![endif]-->

I have found, though, that when running IE in IE8 standards mode, most of the sample applications I had partially failed with the Silverlight version of the library. The only reliable results I received with IE8 was using quirks mode with the older excanvas.js library.

last update

Another area impacted by changes associated with VML is the mapping APIs provided by Google and Yahoo (non-Flash version). I’ve found if you do add the meta tag above, the applications mostly work. Some of the routing is off with Yahoo maps, but it’s close enough.

Categories
Specs SVG Technology

State of SVG, state of the Bird

I was quite pleased to see all of the activity related to SVG in the HTML5 working group’s public email list. I agree with those who say that HTML5 needs to be able to work with any unknown vocabulary via namespaces, rather than try to coerce a HTMLized version of SVG and MathML. A case in point is the vocabulary items providing metadata information about the image that Inkscape puts into SVG documents. Creative Commons, Dublin Core, its own stuff–Inkscape believes in metadata.

In the meantime, I will continue using XHTML with my SVG design integration. I was momentarily peeved about the repetition of the “draconian” error handling of XHTML every time anyone even mentions the topic. However, I’ve since decided that rather than be peeved, I should feel flattered. According to the people who talk about the “draconian” nature of XHTML, I must then be some kind of superwoman to be able to support it. Hey, go me.

Burningbird currently demonstrates my new philosophy of design, though not necessarily using a specific design I will keep–though it is bright and cheerful in a “Horton Hears a Who” way, and I need bright and cheerful with all the rain and flooding we’re having. As I’ve mentioned in a couple of earlier posts, the site uses a relatively simple SVG image as flexible background, in addition to other SVG for decorative accents. For IE or other user agents that can’t process SVG, I provide a tiny repeating blue striped background, so that they don’t get a plain page. Different but decent.

Though I use the rgba function to set the semi-transparent background of the center column and sidebar, I first define a background color using hex notation:


.column
{
        background-color: #fff;
}
.column
{
        background-color: rgba(255,255,255,0.8);
}

Browsers that don’t support the rgba function yet will pick up the hex notation, getting a nice coordinated blue center column, with white for content and sidebar; otherwise, they’ll pick up the rgba notation, with a completely transparent center column, and semi-transparent sidebar and entry area.

Safari and Firefox support rgba, but Opera doesn’t at the moment (it most likely will in the next beta release). However, again the design is such that it degrades gracefully and looks decent even without support for this CSS3 color module attribute. Or I think it looks decent, though lord knows I’m not a web designer. Let’s say my use of the technology is sound, but my design sense may suck, depending on your perspective.

I’ve also implemented text-shadow, in this weblog and at Burningbird. The sub-headings have a very tiny text-shadow, which really makes the text pop out nicely:


        text-shadow: #ccc 1px 1px 2px;

Opera and Safari both support text-shadow, but there’s no adverse impact with browsers that don’t. It adds a nice polish, but that’s all it is, polish. I really like it, though, and can’t wait until Firefox implements it.

All in all, Safari is currently the browser with the most advanced support for my design concepts, with Firefox a close second.

Another interesting point on the design is the flexibility as to scale. The background scales large for larger monitors, but the entire content will resize based on browser window size, as well as font size and resolution. If you resize the window small enough, the sidebar pushes to the bottom. This is not a bug–the sidebar gets pushed out of the way when the web page is accessed by a smaller device, such as an iPhone. It’s still there, but not taking up valuable real estate.

In fact, the photo and the bright yellow box currently showing also demonstrate the scaling–the yellow box is a SVG element that is constrained to size to the parent container, but preserve aspect ratio; the photo will display at its maximum width, but scale down as the window scales. All in all, the site can scale to an infinite width or down to a minimum 40em in width, and still be readable. The site even works with my Kindle, either using the mobile CSS, or when using the Kindle’s advanced web browsing, the scaled down width and the blue stripe background (though in gray tones, of course).

Best of all, you can zoom the text and the whole site zooms out, so that the words per line length is consistent.

That’s the key to my site designs in the future–not trying to get the sites to look the same in all devices, but looking good for each. Or at least good enough while still giving me the opportunity to try out new technologies. We’ve fixated too much in the past on making sure a site looks “the same” in all browsers. We’ve crippled our creativity trying to make sites look “the same” in all browsers. This was someone’s anal design “rule” set out long ago, and it’s time we toss the bugger aside.

I promised Bud a writing on SVG and performance, especially as compared to raster images (such as PNG, JPEG, and GIF). I actually checked out the WebKit code to see how it manages graphics, and was surprised at how easy I was able to follow the code considering that I haven’t worked with C++ since my old Windows programming days. The WebKit code is well organized and documented, with a minimum of tricksy coding. It really is an excellent product–not the least of which that it will probably be the first browser to pass Acid3. It or Opera, they’re both very close.

Anyway, the writing will be coming after my site redesign, after I finish proofs, after I get the next book started, but I wanted to quickly mention my discovery, in the course of my explorations, how committed Apple is to the use of SVG–in browser and out–because of the scalability. Think of it: if you have a desktop icon that you want to look good in a tiny screen, as well as a monster 60 inch television, would you want to use raster images? Of course not. OK, then, would you want to invent a graphics format, or use one that already has extensive tool support, as well as earning you brownie points with the development and open source communities?

*beep* time’s up

Apple chose wisely. Still, I was surprised at the strength of commitment Apple has to the integration of SVG into its products. And this despite HTML5 disapproval. Hey, go fruit.

Update Opera is stating they’ve reached 100/100 on Acid3. Congratulations Opera! Can’t wait to get my hands on a working tech preview. When I do, I’ll run it against the *Firefox Minefield edition, and the latest WebKit build and we’ll see how they’re all doing. The real test is getting 100/100 with a publicly accessible browser version.

I will declare a winner in my Acid3 races once I’ve seen the 100/100 with my own little eyeballs. Being as I’m superwoman and all.

*Oh, and IE8, too.