Posts Tagged ‘Validation’

Valid Flash Embed – Make That YouTube Embed Valid!

Hola! It’s been a while. I’ve got another gripe, and this time it’s with Flash embed code!

Most of the embed code I see for Flash movies is invalid, usually containing the non-existent embed element or some-such. Even the code provided by YouTube for embedding videos contains embed. This can easily be thrown out and will—probably most of the time—instantly make your code valid.

Here’s an example (in XHTML) of a valid Flash embed that works in at least IE6+, Firefox, and Safari:

<object data="flash.swf" type="application/x-shockwave-flash" width="320" height="240">
<param name="movie" value="flash.swf" />
</object>

That’s all there is to it. Adjust the parameters and add additional param elements as necessary. If your Flash movie requires variables, just add an extra param as follows:

<param name="flashvars" value="arg1=foo&amp;arg2=bar" />

If you place additional elements inside the object element, it will act as a fallback, displaying if the Flash plugin isn’t installed. For example:

<object data="flash.swf" type="application/x-shockwave-flash" width="320" height="240">
<param name="movie" value="flash.swf" />
<img src="fallback.jpg" alt="Flash Didn't Load!" />
</object>

That’s all for now. Happy coding!

—Kyle Blizzard

SEO and Validation

I was reading The Truth About Validation and I felt the need to respond. First off, Tim makes some valid points but only if the article is renamed “The Truth About Validation and SEO”. I agree, if a web developer tells you that you can’t be much of an SEO if you don’t write valid code then that developer is a clown and should be ignored. If they are just saying that you are not a valid coder then that would be true. From a coder’s point of view they could go as far as saying that you are a hack, would they be wrong? That said, there are many other reasons to write valid code.  Some of the best SEO gods, gurus, evangelists, provide detailed change requests to web designers and this is often preferred on a valid site so the SEO does not break the valid code. Maybe SEO specialists should inform the client that there is such a thing as validation and let them decide. It’s similar to an auto mechanic letting the customer decide if they want a factory replacement part or an aftermarket part, is it worth the extra money? Determining that invalid pages are ranked high for certain terms does not tell the complete story but it does tell most of the story. What if a search bot reaches a certain point on a page that is so invalid it stops parsing? At that point the rest of your content would be ignored. What if the next algo revision applies more weight to valid code or is modified so that it halts when a missing end tag is encountered (is Bing already doing this)? You would have partial page results in the index which means you have wasted copy.  More important is the fact that invalid code might not render properly on the next update to your audience’s preferred browser. At some point the invalid code will probably rear its ugly head and then you will need to pay the piper to write valid code, or at least new code, so why not let the coders get paid for what they do?

We could argue that having a shade tree mechanic use bailing wire to fix a dragging muffler will allow you to use the car again but for how long? Yes it will cost more money to order the new muffler hanger and have a muffler shop install it properly but when you hit that big speed bump at the grocery store which one do you think will hold up? At that point did it really cost more money to have it done right?

I agree if you charge someone to do SEO work and you don’t write valid code then you aren’t ripping them off. What if you are upfront and tell them, directly, I am going to make the changes using invalid code, will they care? Should they have a choice or is OK to leave them in the dark since it is to your advantage?

One point Tim implied that I disagree with is that it’s more expensive to work on valid sites. It is much easier to work on a properly designed CSS and XHTML site than a hacked, table infested, monstrosity. We charge a lot more, well actually, we usually require a complete redesign before we start working on a hacked site but this is strictly related to design work, not SEO. Let me repeat here that I agree that validation has little to do with SEO if anything. I say if anything because we don’t know if any search engines pay greater weight to valid code and there can be a case made for a parser getting stuck or stopping after a bad or missing tag. Maybe not Google but can we guarantee this won’t happen with any search engine?

I give the thumbs up to valid code because without validation then you have to set some other standard for when the code is acceptable. It would be much more difficult to create a list of what code is bad or invalid but acceptable. Why not follow the standards that are used to design every web browser?

I also read “source code validation common sense” over at SEOBook by Aaron Wall. Wow! He really goes off and I don’t blame him but I have never personally heard a good web designer that is proud of his ability and trade claim that validation is an integral part of SEO work. I say ignore those monkeys but let the design experts maintain their status of elite, or cream of the crop, by writing valid code and proving they are at the top of their game just as you are at the top of yours. Here are some of the top reasons to validate.

added: I would be considered a hack when it comes to XHTML and CSS. If I perform onpage SEO I check to see if the client site is valid. If it is then I make sure it’s valid when I finish. Often I find errors that I have caused and then I have to employ someone from our design team to fix it. I have been known to render this site invalid just by blogging 🙂

—David Blizzard

ASP.NET and XHTML Validation

If you’ve ever created an XHTML 1.0 Strict page containing an ASP.NET form element and ran it through the W3 Validator, you’ve undoubtedly noticed it’s reported as being invalid no matter what you do and no matter how valid the code actually appears. This is because ASP.NET adjusts the way it renders markup according to the requesting user agent. ASP.NET pities the W3 Validator and sends it bad code. This can be fixed with a “browser” file. The file and instructions on its use are available from that page.

However, that’s not all. The validator will now see your pages the way you see them in your browser, but ASP.NET is still rendering an invalid name attribute on your form element! You need to add a line to the system.web section of your web.config file:

<xhtmlConformance mode="Strict" />

Now ASP.NET plays nice with the W3 Validator and renders a valid XHTML Strict form! Now you can stop using the XHTML Transitional doctype and start using the XHTML Strict doctype on your ASP.NET pages!

—Kyle Blizzard

Logical Structures and Happy Designers

While valid markup and CSS are necessary, they’re not the only things we web designers require to keep our sanity. One can create a valid page that is still difficult to work on. For example, using absolutely positioned elements for page layout is even worse than just using tables. When you add content to one element, the ones below it are not pushed down because they are no longer in the “flow” of the page. This causes overlap of content and makes it extremely difficult and frustrating to add anything to the page. Utilities such as Yahoo! SiteBuilder create pages like this.

A markup structure that is built to logically represent the content of the page and not to facilitate the appearance of the page is much more easily edited and future-proof than the “HTML soup” sites of old. I wistfully say “old”, but the truth of the matter seems to be that HTML soup is still the preferred meal of the majority of so-called web designers. A lot of the web sites we’ve moved to our servers are a pain to work with and rarely validate, and they were, sadly, created by professional web designers!

Another couple things that are bad practice but not invalid are the use of inline style and CSS classes with names that tie them to a particular stylesheet such as “red-text” or “left-side”. What if you change the stylesheet some day and that “red-text” is now supposed to be blue or the “left-side” spans the bottom of the page? The World Wide Web Consortium themselves discourage the naming of CSS classes like this. They also have some other useful tips that all web designers should read and keep in mind.

If you’re a fledgling web designer or perhaps someone who is just looking into having a web site created and wondering what valid code and good design practices can do for you, check out the CSS Zen Garden site, an excellent example that is logically structured and able to accept stylesheets of wildly different appearances without the need for markup changes.

—Kyle Blizzard

Valid code and happy designers

Writing valid XHTML and CSS takes a little extra time but can save a client money and a designer their sanity. In the relatively brief history of web design there has been a great deal of controversy concerning web standards. Designers like to make money and making money means completing projects quickly. Typically, if the client liked it and it rendered correctly then the project is done. The major browser manufacturers carry some of the blame in their efforts to have the latest and greatest features they have implemented web page design elements in their own way. Rather than engendering innovation they have had the effect of creating a Tower of Babel of incompatible tags. In the old days,  some designers used any hack necessary to get a page to display properly in the the most popular web browsers of the time. However, in the past several years, the web standards community has been increasingly vocal about incompatible code and rendering problems. This has been especially true with IE-only sites that will not render properly or at all in alternative browsers such as Firefox, Safari, Opera, and Chrome. However, a standards compliant site provides greater interoperability for the same content on different platforms.

Another additional benefit of writing valid code is that it is easier to read, edit, and redesign. Separating the presentation of a site from its content using stylesheets seems like a no brainer. Theoretically you could redesign an entire site just by editing the stylesheet and the graphics without ever touching the XHTML. We have a number of clients who move to us from other hosts and the amount of spaghetti code that we are asked to edit sometimes makes us want to pull our hair out.

The point is, you can write sloppy code if you want to. You could even use <blink> tags in a site designed entirely in tables and transparent gifs if you were so inclined. But where is the return on investment for the client? There is a high probability that you are not the last one that will ever touch their website. So have a heart and validate your XHTML and CSS. You will get faster at making lean, mean standards compliant sites that look good on any browser.

—Alan