fusionsite.co.uk

Update

Due to the limited benefit of Google's AdSearch in my case, I have since removed the code. I will keep this page here, though, in case anyone finds it useful.

AdSense and XHTML Strict

Okay, I think it's a fair question why someone would ask why some of these pages don't classify as XHTML Strict and yet I have the XHTML Strict logo at the bottom.   Well, in my defence, the problem only occurs on the home page, and the gallery page: the only pages with Google's SiteSearch for AdSense.

I have gone to great lengths to ensure that this website now uses XHTML Strict and CSS throughout.

In the code I have written for this website, with only one exception being in the code generated by my PHP script for the Fretboard Navigator (it has a font tag, and table, and some formatting), there are no instances of:

• tables,
• font tags,
• cookies,
• javascript,
• pop-ups,
• or any other formatting attributes, other than an imported CSS file.

There are several good reasons for this, including, but not limited to, accessibility, speed (download and execution), and portability (both of browser visibility and flexibility for alternative designs, without touching the original XHTML code).

The only other exceptions to these is in AdSense.

It has taken a great deal of effort to get this site to work without tables, and it works fine in Internet Explorer 6 and FireFox 1.0 (haven't been able to try other browsers at this point though). Realistically, I guess most people wouldn't know the difference browsing to this website, whether it's got tables or not, so largely the effort will go unrecognised.  That's fine, but from a web-developer's point of view, I know I've made the right decision as HTML will slowly become out-dated.  JavaScript, while it's often an invaluable tool, is also generally taken for granted.  I also find that working with JavaScript, most things are working against standards, and are "hacks", as opposed to sticking strictly to the rules, which the most commonly used browsers should also be doing.

I personally blame Frontpage, DreamWeaver and Internet Explorer for poor general coding standards. 

Don't get me wrong, I do like DreamWeaver, and still use it (check the source!), but it's easy to let it do all of the work, and I don't think it always can make the right decision.  Code re-writing can be a real pain too (if you have it enabled), especially when incorporating affiliate code.

Internet Explorer still has problems with some basic CSS2 (for example, like margin-left:auto and margin-right:auto for centering a layer; no :hover support for tags other than <a>, and the lack of adequate PNG alpha transparency support).

It may have changed since I last used it, but rule of thumb, don't use FrontPage! FrontPage 98 had a particularly infamous bug, which could result in users deleting the entire content of their hard-drive.

I've recently bought TopStyle Pro, and would heartily recommend it.  It's the best thing that I've bought for web development.

Anyway, a bit of digression.  Back to AdSense and XHTML!

What is wrong with the code?

Firstly, there is a strange one.  The <input> and <img> tags aren't closed with the standard <img src="..." alt="..." />, but with <img src="..." alt="..."></img> this is really incorrect, because the img and input tags aren't container tags (there should be nothing within them). This doesn't throw up a Strict error, though, because at least the tags are closed.

The actual errors

• Line ??, column ??: there is no attribute "target"
  ...d="get" action="http://www.google.com/custom" target="_top">
  
  An unfortunate disadvantage of XHTML Strict from a web author's perspective is the lack of ther target attribute.  Originally I had made quite a lot of use of it, to open external sites in separate windows.  This is a cheap trick though, to artificially keep visitors in your site, but mainly serves to annoy them.
  
  Google using target="_top" is needed in the instance of the page being framed, and I guess framing the results could artificially make the output look like it's generated by the containing site, rather than Google.
  
  I personally don't think it should be required if your site doesn't use frames though, and I think it's against Google's policy to put the Google Search box within a frame anyway.
• Line ??, column ??: there is no attribute "nowrap" ... attribute "height"
  <tr><td nowrap="nowrap" valign="top" align="left" height="32">
  
  With XHTML you really should use CSS for all formatting, but Google has strict policies on the appearance of its adverts.  I guess this is required, as it's the only way to guarantee over-riding all default or coded styles for this attribute.
• Line ??, column ??: there is no attribute "border"
  border="0" alt="Google"></img></a>
  
  As above, all formatting should be done with CSS.
• there are no attributes "size" and "color", and element "font" undefined
  <font size="-1" color="#000000">fusionsite.co.uk</font>
  
  The font tag is actually deprecated in XHTML, and subsequently, all of its attributes. It shouldn't be required anyway, there are standard tags for most textual scenarios, and you can use span or div to add additional formatting where required.

So, I can technically see why Google's SiteSearch code fails, but I don't know of any reason why they couldn't have used inline CSS to remedy all of these problems, and why they used </img> and </input> at all is beyond me.

Has Google commented on these problems?

Yes, they have, and some sites claim to have had responses from Google that allow them to encapsulate the SiteSearch code inside an <object>, refering to the offending HTML in a separate page.  This would indeed enable the page to work, and even with relevant adverts still showing, while validating correctly.

I got the following feedback from Google support:

Thank you for your message. Unfortunately, the arrangement you described would not be permissible by our program policies. In addition, with this arrangement Google ads would not be targeted to the specific page as the actual ad code is in an other HTML page and referred to from the actual XHTML page.

We appreciate your taking the time to offer us this feedback and encourage you to continue to let us know how we can improve Google AdSense. For additional questions, please visit our AdSense Support site at https://www.google.com/support/adsense or feel free to reply to this email. 

I replied with:

"I have since read that one possible work-around is to link to the AdSense code within an <object>, tag as a separate (HTML) page: http://keystonewebsites.com/articles/adsense.php

I found the link to that page here:

[http://www.workingwith.me.uk/blog/13872/]"

and got the following reply:

Thank you for your email. As previously noted, unfortunately, we are unable to provide support for XHTML at this time. We are currently only able to provide the AdSense ad code and the AdSense search code in HTML form as located in your AdSense account and are unable to recommend means of code implementation onto your pages aside from directly placing it onto the source of your pages. We appreciate your understanding.  

Fairly standard replies, and although they seem keen to improve the AdSense service, it looks to me that XHTML compliance is not high on their list of priorities.

I think this is a shame, because I think XHTML will take websites into the next generation of design.  I've had a look at XHTML 2, and the new standards, and there are some really smart changes (just a couple of good ones, as I see it, listed here):

•  <h1>, <h2> and <h3> will be deprecated in favour of <h> and <section>: nesting them to get the level.  I think this is an excellent idea, as <h?> tags are pretty confusing, and it isn't always obvious which you should be using. <h> tags would fall much more naturally.
• Any element will be able to contain a hyperlink with the href attribute - very useful, should save some faff with formatting <a> tags repeatedly.
• A new tag <nl> for navigational links - should improve the incorporation of nested menus.

It's still early days for XHTML 2.0 (spring 2005), and I think it's still being drafted, and support is only started to be written into browsers, so it will be quite some time before it can be used generally.  However, I've been waiting a long time to be able to use CSS to this extent.  It's been worth the wait.

Anyway, back to my XHTML and AdSense dilemma.  I think I'll keep the AdSense search facility for a while, and see how it goes.  At this point in time it doesn't seem to be particularly useful, but time will tell.  I will keep my pages XHTML Strict upto the point that I have 100% control over them, and only Google's SiteSearch is falling short.

Maybe sometime, they will address this...  Maybe...