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.

Categories
Burningbird Technology Weblogging

WordPress 2.5: Looks

Recovered from the Wayback Machine.

Though I will be using Drupal for portions of my site, I’m still debating whether to continue using WordPress for purely weblog activities, such as at RealTech. I decided to download the WordPress 2.5 release candidate 1, give it a run.

I’ve moved most of my XHTMLating work to plug-ins, so I didn’t have the problems with overwriting source code. The plug-ins I do use worked without a hitch, including the one that XHTMLates comments (though the commenter’s name field doesn’t support internationalization at this moment).

I like the new dashboard, which does a good job of putting important information at the top. I don’t like the fact that you still don’t have a lot of options–or at least I can’t see them–for eliminating all of the crud that gets pushed at you. I don’t care about top plug-ins. I don’t care about other WP weblogs of note.

As for the new site design, I like the coloring, but I do not like all of the design changes. Case in point is the Write Post page, with post in process.

Look at all that wasted space. There are four headers above the Write Post page, and in the Write Post page, we now have to scroll down to control comments, pick categories, add tags. Yet what takes up the valuable real estate to the right? Related items, ie how to manage comments, posts, etc. When you’re writing a post, what are the items you’re most likely to edit for that post on a regular basis? I would say tags and categories, as well as comment status. You’re not worried about managing categories or comments.

I do like that the Delete button is now more obvious, rather than buried at the bottom of the post. In addition, I was happy to see a link to draft entries rather than forcing us to filter on draft to find a post in process. There’s also only one Save button for a post now, equivalent to the older “Save and Continue editing” function.

I also like the fact that you can edit the permalink, though the creators didn’t go far enough–you should also be able to pick which category goes into the formal permalink. I had hoped that the developers would also list existing tags in the tag area, but you still have to guess what tags you have if you don’t want to add new ones.

On the other hand, I do think the media management capabilities are superior in this version. If you serve video, you can now more easily manage your video, as well as music and image files. For instance, you can click on more than one file to upload, rather than have to upload individually. The application will then upload all the files, and for photos, attempt to use the photo’s EXIF file to fill in the relevant information, though the application doesn’t seem to like my photos’ EXIF sections.

However, if you’re tempted to have WordPress 2.5 create an in-page gallery, think again if you’re serving your pages up as XHTML: the generated gallery HTML is not valid.

This is a trivial error to fix, and I’ve sent the error information into the special feedback email address. However, this does demonstrate something I find a little disquieting–the WordPress developers are not running their sites as XHTML, themselves, in order to ensure WordPress provides both valid HTML and XHTML. Nor are the developers validating what they generate. If they did, they would realize that their sites don’t validate.

Worse, the validation errors are such blatant errors that even relatively inexperienced web developers–and web designers–should have caught them early, and prevented their occurrence at this late stage of WordPress 2.5 development. The only assumption I can make is that form is taking precedence over function with this release. Definitely not an attitude I would have expected considering the involvement in the development of WordPress 2.5 by known standards luminaries.

The page containing the gallery does not open in Firefox, Safari, or Opera because these browsers read the page as XHTML, and the page has invalid markup. However, the page does open in IE8. Perhaps the underlying issue is that IE8 is the browser of choice for the WP development team.

In the other sections, if you make any updates in the user page you have to type in your password again, or it tells you that you only entered it once. That’s annoying. The rest of the pages seem the same, except for a new Media Library, which shows what images are used where. Handy if you want to track down in which posts a specific image has appeared.

Overall, the interface is cleaner and media file management has definitely improved, but the usability has, in my opinion, taken a couple of major hits. I include in this category the freedom to serve our pages up as valid XHTML without having to struggle with invalid generated page markup.

Now, I’ll publish and see what happens to the feeds.

Categories
Specs Web

Joel Spolsky: Crap is good

Recovered from the Wayback Machine.

Joel Spolksy just spent several thousand words and accompanying diagrams saying one thing: we did things crappy in the past, and we should continue doing things crappy in the future because crap is easy.

Where do I start?

This upcoming battle will be presided over by Dean Hachamovitch, the Microsoft veteran currently running the team that’s going to bring you the next version of Internet Explorer, 8.0.

At a minimum Microsoft can go off and do its own thing in total isolation, and in the long run, Microsoft will end up being the loser. The more I work with SVG and the new CSS, the more I find that I can develop using the new technologies, and the page still works for IE but I don’t have to make it look the same for IE. As long as the page is clean, legible, and accessible via IE, it doesn’t have to look the same for IE as it does for the Big Three (Firefox, Safari, and Opera).

So I’d say that Hachamovitch is a player, but only to the extent that Microsoft wants to be a part of a larger community.

In practice, with the web, there’s a bit of a problem: no way to test a web page against the standard, because there’s no reference implementation that guarantees that if it works, all the browsers work. This just doesn’t exist.

Question: can you see this page?

There is no practical way to check if the web page you just coded conforms to the spec.

Question: can you see this page?

There are validators, but they won’t tell you what the page is supposed to look like, and having a “valid” page where all the text is overlapping and nothing lines up and you can’t see anything is not very useful. What people do is check their pages against one browser, maybe two, until it looks right. And if they’ve made a mistake that just happens to look OK in IE and Firefox, they’re not even going to know about it.

I’m trying to untangle this one mentally and failing. What Spolsky seems to be saying is that standards don’t matter, because people don’t test in all browsers, and standards somehow make lines not even up. Or something.

He can’t possibly be saying that standards break the web. Can he?

Actually, he can.

Standards are a great goal, of course, but before you become a standards fanatic you have to understand that due to the failings of human beings, standards are sometimes misinterpreted, sometimes confusing and even ambiguous.

The precise problem here is that you’re pretending that there’s one standard, but since nobody has a way to test against the standard, it’s not a real standard: it’s a platonic ideal and a set of misinterpretations, and therefore the standard is not serving the desired goal of reducing the test matrix in a MANY-MANY market.

DOCTYPE is a myth.

A mortal web designer who attaches a DOCTYPE tag to their web page saying, “this is standard HTML,” is committing an act of hubris. There is no way they know that. All they are really saying is that the page was meant to be standard HTML. All they really know is that they tested it with IE, Firefox, maybe Opera and Safari, and it seems to work. Or, they copied the DOCTYPE tag out of a book and don’t know what it means.

There’s at least four separate thoughts in these few seemingly related paragraphs. First: there really are no standards, because standards are a thing of the mind. Second, because standards are a thing of the mind, one can’t test pages against a standard. One such standards thing is DOCTYPE, which really doesn’t exist because no one knows what it does, and people just copy it, anyway. Therefore…

I must admit to getting lost at this point. Who’s on first?

And so if you’re a developer on the IE 8 team, your first inclination is going to be to do exactly what has always worked in these kinds of SEQUENCE-MANY markets. You’re going to do a little protocol negotiation, and continue to emulate the old behavior for every site that doesn’t explicitly tell you that they expect the new behavior, so that all existing web pages continue to work, and you’re only going to have the nice new behavior for sites that put a little flag on the page saying, “Yo! I grok IE 8! Give me all the new IE 8 Goodness Please!”

And indeed that was the first decision announced by the IE team on January 21st. The web browser would accommodate existing pages silently so that nobody had to change their web site by acting like the old, buggy IE7 that web developers hated.

A pragmatic engineer would have to come to the conclusion that the IE team’s first decision was right. But the young idealist “standards” people went nuclear.

It’s been a long time since I’ve been called a “young idealist”. I wonder how Sam Ruby likes being called a young idealist? I’m surprised Spolsky didn’t pat us all on the heads, offer us a cookie. But wait, it gets better…

Almost every web site I visited with IE8 is broken in some way. Websites that use a lot of JavaScript are generally completely dead. A lot of pages simply have visual problems: things in the wrong place, popup menus that pop under, mysterious scrollbars in the middle. Some sites have more subtle problems: they look ok but as you go further you find that critical form won’t submit or leads to a blank page.

Fancy that…this young idealist’s web sites both worked with IE8, right out of the box. In fact, the only problem I’ve had with IE8 is with Netflix and that’s because of the ActiveX controls and nothing to do with standards.

I think we’ll find that most web sites don’t break with IE8, or if they do, they’re just as likely break with Firefox 3b, and Opera 9.5b, and the latest WebKit. There’s a reason you have a long beta period for a browser–to give people time to make any necessary fixes in order to have the browser work with the page once the browser is released out of beta.

True, there are sites that will continue to break with IE8 once it’s released. If you want to find them, go to the geocities.com web sites, and search on muscle cars. Better yet: “Unicorn rainbow pony”. Heck, even most of them will *probably work.

Some of those pages can’t be changed. They might be burned onto CD-ROMs. Some of them were created by people who are now dead. Most of them created by people who have no frigging idea what’s going on and why their web page, which they paid a designer to create 4 years ago, is now not working properly.

So the web has to stop because a web site has been burned on a CD, or the person who created the site is dead? Isn’t that equivalent to saying, “No, you can’t have blu-ray, because I still have VHS tapes”? Or maybe more in line with, “No, you can’t have that vaccine because there are people in the world who think the plague is caused by evil spirits, and we have to halt our practice of medicine until they catch up.”

You know, it is OK to let old pages break. There is nothing so valuable online today that we have to halt all further progress of the web because of the off chance a page won’t be viewable in a modern browser. If it were truly that valuable, it wouldn’t be that vulnerable.

Leaving aside vapid, sexist twaddles such as, Mmhmm. All you smug idealists are laughing at this newbie/idjit. The consumer is not an idiot. She’s your wife. So stop laughing (speaking of which, it doesn’t matter where the quote arises, Joel, only your use of it to prove a point), Spolsky’s whole pitch is basically a race for the bottom. Crap has happened in the past, and therefore we should continue supporting crap in the future. Not only support old crap, but encourage new crap because, frankly, people are too stupid to learn how to do things right. She’s your wife, indeed.

In response to Spolsky’s writing, Sam Ruby wrote, If people want web browsers that work with actual web sites, they still have three choices. Three good, solid choices, created by three organizations populated by people who don’t believe we have to be stuck with muscle cars, unicorns, rainbows, and ponies forever.

*Do scroll down the page and look at the comment annotating the page view counter.

Categories
Technology Weblogging

Upgrading to WordPress 2.5: First, install Drupal

Recovered from the Wayback Machine.

Anil Dash had a clever and humorous, as well as telling, guide titled, A WordPress 2.5 Upgrade Guide. His advice?

As you might know, WordPress 2.5 is about to be released, and we wanted to encourage WordPress users to upgrade. To Movable Type.

I wasn’t even aware that a 2.5 upgrade was on the horizon until I read Anil’s posting. Why on earth do the WordPress people embed a link to the WordPress weblog in the Dashboard if they don’t use it to give people a head’s up? Especially since I gather this upgrade is making some major modifications. Modifications that will probably trash some of the changes I’ve made to XHTMLate WordPress. I am now faced with a decision: do I upgrade to 2.5, and continue to XHTMLate? Or move to Drupal? Or increase my pain, and use both?

Moving to another tool sounds about as much fun as having dental implants. However, now is the time to make this movie if you’re considering it. Though using minor version numbering, from what I can gleam, WP 2.5 is a major upgrade.

For me, the logical move is to Drupal. The tool has just come out with a major new version, which means I don’t have to go through major upgrade blues for a long time. I’ve written in the past about the tool’s support for both SVG and RDF, as noted in the keynote at DrupalCon (thanks, James!). And now Laura Scott writes on the number of women involved with the Drupal development, which I did not know about. Probably because of problems with visibility of women associated with open source, generally. According to Laura:

Part of the problem lies not in macho coding culture, but rather in the woeful state of computer and software education in our schools. Most of the people involved in open source are there in spite of their formal educations (or lack thereof). Computer work is pretty much taught only in Computer Science departments, which usually are subsets of Mathematics departments. Despite the fact that nearly every student will be working with computers in whatever field they enter, they likely will never have even one class where they study any sort of computer science or algorithm theory.

Is it any wonder that women especially are not likely to end up in an open source software community? As I noted before, the leading women involved with Drupal came to it from other vocations and educational backgrounds.

I’m not surprised about women coming in from other vocations. I’ve long thought the problem with the Computer Science degree programs in college is that there are Computer Science degree programs in college. I was pleasantly surprised, though, about the significant women’s involvement in Drupal. This involvement becomes yet another reason to make a move to Drupal.

All appreciation to Laura for her kind words about yours truly, I doubt I’ll have any visible impact on the growth of Drupal, and Matt at WordPress will attest to the fact that I can be a real pain-in-the-butt to have as a user. To be honest, I think Drupal, itself, with its forward moves into semantics and SVG and related technologies, and the community around Drupal are what will have a positive impact on the growth of this tool. Enough to be a threat to WordPress? That’s a silly way of looking at it, because there’s plenty of business for WordPress AND Drupal, and yes, even Anil’s Movable Type. Everybody has different needs.

But, oh, I hate having to go through yet another tool switch.

Manilla->Radio->Blogger->MT->Wordpress->Drupal.

In the meantime, if you are a WordPress user, heads up, as change is coming at you. And if you see strange happenings around here…well, come to think of it, you always see strange things happening around my web sites, so, never mind.

Categories
SVG

ACIDBird

Recovered from the Wayback Machine.

Today’s design is based on the Open Road SVG image that was just uploaded. This SVG image is ideal for a background, because it lends itself to morphing. It’s also a horizontal image, which works better for a background image.

The image is adding into the page in such a way that it expands to fill the page, regardless of how small or large the browser window is. It is resolution independent. I use two SVG attributes to manage how the images show in my sites, both set on the SVG element, itself.

The first SVG attribute I set is viewBox. The viewBox attribute is a way of capturing a specific section of the SVG image, and using this captured section to fill a given viewport. For instance, if the image naturally sizes to 400 pixels wide, 200 pixels tall, setting a viewBox to 0 0 400 200 is equivalent to how the image would fill the viewport by default without a viewBox. If you use different settings, say 50 20 350 150, then you’re modifying the viewport for the image, setting the beginning x at 50, beginning y at 20, the width at 350 and the height at 150. Since, by default, x increases from left to right, y increases from top to bottom, setting the beginning x and y clips the upper and leftmost edges of the image. If the width and height is less than what the image’s true width and height is, this clips the bottom and rightmost section of the image. You can use any combination, including negative for min-x and min-y, but you can’t use negative values for the width and height. If you use a negative value for the min-x and min-y, it’s about the same as using a margin–it pushes the image over and down.

The viewBox I put on the Open Highway SVG is 50 50 600 400. I decided I didn’t like the sun showing, so I set a smaller width, clipping the image on the right. I didn’t like as much blue sky, and I liked having the road focused a little off-centered, to the right, so I set the min-y and min-x accordingly.

Now, if I used the SVG, as is, with my expanded background, what would happen is the browser engine would attempt to fill my space, but still maintain the image’s original aspect ratio. The image would expand to fill the width at a 100%, but to preserve the aspect ratio, the height wouldn’t be enough to fill the space. The image expands in both dimensions until one fills the space, and then stops expanding along the other dimension.

This can work sometimes, and sometimes it doesn’t work. In this case, it doesn’t work.

I use the second SVG attribute, preserveAspectRatio, set to a value of “none” to tell the browser engine not to preserve the aspect ratio. Then the image expands 100% along the width and height–stretching the image, true, but filling in the space. If you choose the right background, such as Open Road, which works rather well, it doesn’t matter the perspective, it works. There are also other settings for peserveAspectRatio, but I’ll play around with those another day, with another design.

My two other images are not the same as the background, as I’m not demonstrating the resolution independent nature of SVG today. I used a coffee cup for the top image, and a little car for the bottom, both of which I think complement the “open road” scheme. Both have the viewBox set, otherwise the SVG images would not resize to fit the container. Instead, I’d be stuck with scrollbars (more on scrollbars later). The coffee cup viewBox creates a viewport big enough for the entire image. The car’s height is clipped, so that the wheels line up directly on the bottom of the page.

I used the object element rather than inputting the SVG inline for today’s theme, as I wanted to record another couple of bugs with WebKit and Opera.

Webkit stretches the image, but it doesn’t draw the content over the SVG until I scroll down and back again. In addition, WebKit also adds a white background for the SVG, which is something we can’t seem to control. This can really ruin a nice effect, such as the top coffee mug, and the bottom car.

 

Opera doesn’t stretch it at all, and also persists in putting scrollbars on the objects. No matter what I do to try and control the object overflow, the scrollbars get added.

I’ve turned in bug reports for WebKit about the drawing problem and the white background. I’ve also noted problems with pages for Opera, but I’m going to make sure formal bugs are entered for the gradient problem with yesterday’s design, and the object scrollbars and inaccurate resizing with yesterday’s and today’s design.

The work on the themes does demonstrate another important issue. Something like ACID2 and ACID3 are handy ways of seeing if key web technologies are supported, but they’re not comprehensive. Firefox 3b3 scores less than Opera 9.5b and the WebKit nightly on ACID3, but it has better overall support for SVG; especially as integrated into a web page. If the browser makers focus too much on the Acid tests, they may miss the overall picture, which is ensuring that SVG works well in a web page. I have confidence, though, that my reported bugs will generate activity.

I won’t keep this design for long–or at least, I won’t use the object elements–because IE does not deal well with SVG loaded into an object elements that are supposed to be in the background, no matter what version of IE I use. The content is pushed down with IE7, and gone altogether with IE8. I’m getting this behavior even when using the Adobe SVG plug-in.

In the meantime, since Microsoft isn’t welcoming bug reports from the general public related to IE8, my only recourse is to remove the Adobe plug-in. Once the Adobe SVG plug-in was de-installed, then the page opened just fine in IE. Well, it’s in black and white, but legible.

updated

Bud didn’t like the clouds.

*poof*

Clouds gone.