More XHTML Compliance Issues in ColdFusion 8

I ran into a problem recently where a completely valid XHTML 1.0 transitional site was rendered incompliant by the addition of <cfmenu>. It seems that <cfmenu> causes compliance to fail in two ways:

First, it adds JavaScript to the “OnMouseOver” and “OnMouseOut” attributes of its menu items. To be compliant, it should be adding them to the “onmouseover” and “onmouseout” attributes. There’s an easy fix to this. Inspired by Ben Nadel’s post on altering the output of the writeToBrowser feature of <cfimage> I just used <cfsavecontent> to capture the menu, and then alter it, as listed below:

<cfsavecontent
variable=“menuContent”>

<cfmenu
name=“menu”
type=“vertical”>


<cfmenuitem
name=“home”
href=“index.cfm”
display=“Home”/>

</cfmenu>

</cfsavecontent>

<!— These calls help bring page to XHTML compliance. —>

<cfset menuContent = Replace(menuContent, “OnMouseOver”, “onmouseover”, “ALL”) />

<cfset menuContent = Replace(menuContent, “OnMouseOut”, “onmouseout”, “ALL”) />

<cfoutput>#menuContent#</cfoutput>

But that doesn’t hit the other problem, which is that any of the Ajax capable tags seem to add the following bit of code to the top of a page:

_cf_loadingtexthtml=”<div align=’center’><img src=’/CFIDE/scripts/ajax/resources/cf/images/loading.gif’/>”

This screws up compliance on two fronts:

  1. The div created in that code isn’t closed.
  2. The img created in that code doesn’t have a alt tag.

Now the interesting thing here is that isn’t actually a div that’s created, it’s only JavaScript that will at some point create those elements. I think technically the compliance test is falsely marking this as a violation. But try explaining that to a client who demands compliance without understanding the theory behind it.

Anyway, I can’t find a single way around this. Using the OnRequest method of application.cfc was my best bet. I figured I would use to call <cfsavecontent> and replace the offending code like I did above. Unfortunately, this spot of code is directly written to the buffer when <cfmenu> gets called.

I also tried a few getPageContext() functions, but to no avail. I’ll be stuck trying to explain this to the client. In the meantime, I filed a bug report with Adobe.

17 thoughts on “More XHTML Compliance Issues in ColdFusion 8

  1. Adobe has got to get more xhtml-conscience peeps into the CF Beta/Alpha. I think this is one of the issues. We’re all so focused on new features and such, we forget about the standards.

    Like

  2. In regards to passing validation, Adobe also need to keep in mind HTML 4.01 and, in the future, HTML5. I haven’t played with validating any of the generated code yet, but if Adobe went down the path of only generating valid XHTML it could be a bad thing (even though the parsing of HTML is a lot more forgiving).

    Like

  3. I’ve been arguing about this for years, going all the way back to the fact that paragraphFormat() still adds a single closing <P> tag. The auto server-side form validation adds an unclosed input tag. Now, cfimage provides no way to add alt text. And so on and so on. It’s always seemed to me that these shouldn’t require major rewriting of things, but when I have raised these issues with folks at Adobe, the response has always been “do you want us fixing things like this, or adding new features?” We need to get the message out that yes, we want these fixed!
    And Justin – I would argue that adding XHTML support would not in any way mess up HTML 4.01 pages, since technically, XHTML is valid HTML (but not the other way around), and potentially having to support a theoretical future version of HTML isn’t a valid reason to not support a current version of XHTML. However, if that is a real issue, then maybe we need to have something like a cfdoctype element that lets us control these types of things.

    Like

  4. @Rob: That’s what I was throwing out there; we might want to have better control over the output in the future, especially if HTML5 and XHTML2 are butting heads 😛 XHTML1 should be covered since HTML5 will be backwards compatible.

    For now though I hope Adobe can fix validation issues fairly quickly, since the last thing we’d want is for some tags to become unusable in certain situations. Good post Terrence 🙂

    Like

  5. @Terrence,

    I am curious as to what went wrong with the OnRequest and the CFSaveContent. Other than not being able to flush any of the content to the browser until the whole page has rendered, it should have worked. What CFMenu actually writing to the primary content buffer from within the CFSaveContent tag?

    Like

  6. @Ben, somehow cfmenu is writing the javascript includes to the buffer independent of the way the rest of the content is created. If you wrap the call in a cfsavecontent, but don’t output it, it still adds that stuff to the html head. (Dumping the source of the ensuing blank page will reveal that. )

    Like

  7. I’m glad to see that there are other CF developers out there as concerned as I am with the lack of XHTML validation in code generated by ColdFusion. I recently posted a similar rant on my web site at http://www.richarddavies.us/archives/2007/08/coldfusion_is_the_next_frontpage.php

    If enough of us start complaining about this, hopefully Adobe will do something about it!

    BTW, I really liked the suggestion of using savecontent to fix some of the invalid code.

    And regarding the “invalid” HTML in the JavaScript string. You are correct that it should not be flagged as invalid because technically it’s just a string. But you’re wrong in assuming that the validator is flawed. JavaScript code blocks should be nested inside CDATA tags (i.e. “// “) to tell the validator not to parse the contents of the script tags.

    Like

  8. I am curious as to what went wrong with the OnRequest and the CFSaveContent. Other than not being able to flush any of the content to the browser until the whole page has rendered, it should have worked. What CFMenu actually writing to the primary content buffer from within the CFSaveContent tag?

    Like

  9. A worthy topic. I see that CF 8,0,1 adds the alt attribute. So there’s one problem fixed.

    The other issue still stands. And I am so disappointed in Adobe for not fixing such a simple and important issue. One year on, it still exists!

    Good post, Terrence.

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s