Aarrgghh!!

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.


September 11, 2007 Posted by Terrence Ryan at 1:29 PM

ColdFusion, Web Development,



Comments

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.


Posted by: Todd Rafferty at September 11, 2007 2:14 PM

I agree - all these 'features' aren't going to do me a bit of good if they don't generate valid, compliant code.


Posted by: Jim at September 11, 2007 2:53 PM

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).


Posted by: Justin Carter at September 11, 2007 8:08 PM

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.


Posted by: Rob Huddleston at September 11, 2007 8:29 PM

@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 :P 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 :)


Posted by: Justin Carter at September 11, 2007 10:04 PM

@Rob,

We are working on the issue to add alt text with cfimage. We maybe posting a patch for this, but no promises.

@Terrence

I saw your wishlist posting and have logged a bug for the same. We will try to resolve it for the next release.

Please let us know any feedback/specific issues using

http://www.adobe.com/cfusion/mmform/index.cfm?name=wishform

so that we can review and track the issues.

Thanks, Hemant


Posted by: Hemant Khandelwal at September 12, 2007 1:53 AM

@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?


Posted by: Ben Nadel at September 12, 2007 8:22 AM

Aarrgghh Guy! @Hemant Thanks, the only issue I have with the wish form is that lack of feedback from it. I don't know if my replies go to the either or are being seen by someone.




Posted by: Terrence Ryan at September 12, 2007 9:18 AM

Aarrgghh Guy! @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. )




Posted by: Terrence Ryan at September 12, 2007 9:21 AM

This is one of the main reasons I refuse to use Spry.


Posted by: John Hodorowicz at September 12, 2007 10:38 AM

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.


Posted by: Richard Davies at September 12, 2007 12:29 PM

Terrence, I posted a comment yesterday, but it appears your spam filter flagged it as junk (possibly because I included a link).


Posted by: Richard Davies at September 13, 2007 12:08 PM

Aarrgghh Guy! @Richard, I've restored your comment, and I'm glad I did. That's some good information. I can't take credit for the cfsavecontent idea though, I stole that from Ben Nadel.




Posted by: Terrence Ryan at September 13, 2007 12:25 PM

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?


Posted by: gimmgyut at February 24, 2008 8:53 PM

Thanks for posting this. Has anyone figured out how to make it compliant?


Posted by: Jeff at August 15, 2008 7:56 PM

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.


Posted by: Miles Jordan at September 15, 2008 3:52 AM

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?


Posted by: tower defense at May 9, 2009 4:03 AM

Posted by Who at February 8, 2010 11:02 PM

Post a comment











Remember personal info?