W3C Validation
Permalink 1 user found helpful
I was a little disappointed to discover that pages in the default site of the C5 installation do not validate; nor do pages on the concrete5.org site itself. I'm still learning the C5 ropes (having committed to using it on a large project), but I'm assuming this is just a theming issue. If first impressions count for anything and C5 is truly aimed at "geeks" as well as marketers, I think an effort should be made to ensure that C5-generated pages conform to W3C standards. This is simply a matter of putting your best foot forward if you're trying to grow your audience and wish to be taken seriously by geeks. And yes I know, validation isn't "everything", but it seems C5 should be aiming not only to empower non-technical folks but to also help ensure browser compatibility and advance the state of the Web.
-Steve
-Steve
Understood, but my main point is that the folks at C5 surely have control over which themes they include in the default installation as well as their own website. I'm simply suggesting that at least those two sites should be W3C compliant. I know they can't control what other theme developers do, although I suppose they could make W3C validation a requirement for listing in the market place. (...although I don't know how realistic or practical that is.)
-Steve
-Steve
I agree that WC3 validation is a priority. m2c
no, it's not practical at all. There are some css tricks you have to do which aren't valid.. Due to Internet Explorer 6.0 and some other browsers you have to use invalid code.
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)
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)
The sites I've developed which support IE6 do validate. That's not to say that a disproportionate amount of time wasn't spent getting things to work properly on IE6. That's why I no longer support that antiquated browser and have chosen this approach...
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
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
fix it?
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
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
Hi 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
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
Ok, this message would probably be just as appropriate in the "Building With Concrete5" forum, but I'm posting it here as a follow-up to my original message. Hopefully, it will provide some useful tips and insights for theme and block developers.
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
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
BTW, I'm happy to archive my modified C5 installation and make it available to the C5 team (or anyone else who's interested). You can then diff the files with the distribution and incorporate any changes you deem worthy. I don't know if that would be more efficient than making the changes yourself, but I thought I'd extend the offer.
-Steve
-Steve
Hi 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
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
Steve, I'm also sure the Validation is a strong point and I believe your efforts should be maximixed by the C5 team as have no sense make this modifications on sigle implementations to see everything vanified with the next upgrade. I encourage to share your code with C5 developers. Thanks Steve!
So I came accross this one and was wondering if someone could tell me if W3C Validation is my problem or if not... what is my problem here:
"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.
"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.
So, this is a problem with your server:
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.
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.
Sabrina i answered that in your other thread
hey, i'm slightly confused here but is the actual core coding of c5 validated?
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?