W3C Validation
Permalink 1 user found helpful-Steve
-Steve
If you check the bug tracker you'll see that I've posted a few patches to fix these issues. My sites are mostly valid now...
I don't check each page, I'm not going to die if there's an invalid code. But feel free to report them in the bug tracker section (if it hasn't been reported before)
http://www.ie6nomore.com/
As for vetting all theme submissions, that might be impractical, as I parenthetically stated in one of my posts. Then again, I can imagine how the process might be largely, if not entirely, automated. The theme could be applied to certain select pages and the URL fired over to the W3C validation page. The response could then be parsed and a validation rating applied. I realize every page can't be checked, but knowing your submitted theme would be tested at some level would at least force theme developers (and block developers too I suppose) to pay more attention to the issue.
In lieu of the automated process, C5 could make it easier for their users to evaluate a theme's W3C compliance. What about a button on the theme preview that sent the contents to the W3C site and displayed the results. This would be relatively simple to implement but a major convenience for users evaluating themes. The user could then make a decision based on the nature of any validation errors. After all, one simple error can have a cascading effect that makes the validation problem seem worse than it is.
And lastly, I want to stress again the main point of my original post. The C5 site itself and the default theme in the installation do not validate. I just think that reflects poorly on C5. It should be straightforward to AT LEAST set a good example with your own site and the default configuration of the product itself.
-Steve
IMO you're getting a lot from concrete5 for nothing, if this bothers you enough and you aren't too greedy to keep the changes to yourself(not that MIT license can force ya to) it'll benefit thousands of developers for you to fix it. Fixing html and css isn't exactly rocket science.
Seems like the spirit of open source. If this bothered me enough i'd contribute time to fixing it, but frankly I don't care.
This is coming from a guy that helped concrete5 go from 1.2.6 to jquery 1.3.2 out of the kindness of my heart.
-Scott
Thanks for the reply. Kudos and good for you on your generosity. I'm just providing what I think is constructive feedback, having discovered C5 just a couple weeks ago. Folks are certainly free to disregard my comments. No big shakes!
Pasta lasagna...
-Steve
http://www.adeptool.com/grabs/c5w3cvalidation.png...
Attached is an image depicting W3C validation "before and after" for the home page of the default (Plain Yogurt) theme. Following is a list of issues I encountered and how I resolved them...
* The DOCTYPE declaration was incorrect. I simply pasted the correct declaration for XHTML 1.0 Transitional into the theme's header.php file.
* Nearly every embedded stylesheet (if not all of them) throughout the entire C5 CMS omitted the required "type" attribute from the "style" tag, which should of course be "text/css". I simply did a global search and replace of the entire C5 installation to change every occurrence of <style> to <style type="text/css">. One occurrence (in concrete/models/block_styles.php) was in a string literal, so I had to escape the double quotes there.
* Similarly, nearly every embedded script in the C5 installation omitted the required "type" attribute from the "script" tag, which should of course be "text/javascript". Additionally, none of the embedded scripts used a CDATA section for the script content, an XML requirement. So I searched for "<script>" across the entire C5 installation and changed every occurrence to "<script type="text/javascript"> _and_ added a CDATA section like so...
<script type="text/javascript">
//<![CDATA[
function myFunction() {
// Do stuff here...
}
//]]>
</script>
This was rather tedious and time consuming, as it required a fair amount of manual intervention because of where and how the script tags appear throughout C5.
* The YouTube block used on the page had a number of problems in its view.php file. First, a <param> tag was closed with </params> (note the "s"). Secondly, ampersands were used in the urls as part of the query string. Ampersands are special entities in XML and must be encoded as "&" when they appear as parsed character data - i.e. PCDATA. Even simpler and more concise is to use a semicolon instead of an ampersand to separate query string parameters. That said, I decided to scrap that whole approach and use swfobject.js instead. I mean, it's part of the C5 installation and used elsewhere, so why not. I don't know why it wasn't used for the YouTube block, but it is now on my installation. (See the flash_content block if you want an example from which to work. You'll have to include the swfobject.js file, which is probably best done using addHeaderItem from the on_page_view handler of the controller.)
* The slideshow had a problem with its view.php. Some embedded styles appear in the file (toward the end), which means they wind up being in the body of the document, and that's a no-no. Styles _must_ be in the document head. The solution was simple. I just created a view.css file and placed the styles inside, so they're now referenced in an external stylesheet that's included in the head automatically.
Anyway, the page now validates just fine. All of the issues were straightforward to remedy and were likely simple oversights or a lack of knowledge about how to comply with standards. I would suggest that the core be "cleaned up" a bit and that W3C compliance be mentioned and encouraged for theme and block developers. Geeks do look at this stuff and do care.
Regards,
-Steve
-Steve
It is so good to see someone else who is keen to have validated code.
I was just about to chuck Concrete5 on the 'full of errors rubbish heap'when I came across your observations.
I would like to take up your kind offer of looking at an archive of your modified C5 installation, but don't know where to find it.
I've literally spent the last few weeks downloading and testing CMS programs and have been going INSANE over the sloppy code results!
Congratulations to Concrete5 all on the hard work so far, but please don't get stubborn over validation, because if and when the tide turns, there will be many programs left high and dry on the beach.
Peter
"When I try to edit my site it keeps giving me warnings. I tried to ignore them until I tried to add a page and now this is coming up in my header:
Warning: fopen(/home/barriela/public_html/files/cache_objects/object_65f4665d8012005a4688d42dcd2f3f95) [function.fopen]: failed to open stream: Disk quota exceeded in /home/barriela/public_html/concrete/libraries/cache/default.php on line 44
Warning: fputs(): supplied argument is not a valid stream resource in /home/barriela/public_html/concrete/libraries/cache/default.php on line 45
Warning: fclose(): supplied argument is not a valid stream resource in /home/barriela/public_html/concrete/libraries/cache/default.php on line 46
Can anyone tell me what this means and how I can continue to edit my site without these warnings being posted."
Thanks so much.
C5 is trying to write to your cache, but it's getting the error:
Disk quota exceeded
So, looks like you need to clear some stuff off your hosting account, or up your hosting plan to have more server space.
Most of it depends on your theme and the block views.
I would be interested if screenreaders can handle a c5 site, anyone has tested this already?