Just checked out 5.4.0 from the SVN repository and noticed that few (if any) of the issues I detailed here...
http://www.concrete5.org/community/forums/themes/w3c-validation/#31...
...appear to have been addressed.
They are all utterly trivial fixes, and I'd be glad to submit a patch for the changes I've made.
-Steve
Patch for W3C Validation Issues
Mar 05, 2010 at 5:39 PM
Okay, after a fair amount of mind-numbing tedium, I've managed to fix a number of validation issues in 5.4.0b1. I've added CDATA sections to numerous script tags (I think I got them all) and moved various block styles out of the body and into the head as well as some miscellaneous fixes involving unencoded entities. Anyway, these changes should go a long way toward W3C compliance.
After reading the code submission guideline, it's not clear if I'm supposed to wait for a request to submit the patch or just go ahead and submit it. I opted for the latter, so here it is (attached).
There are still remaining issues, such as unencoded ampersands in the "action" attribute of the "form" tag generated by the "form" block (it seems that issue might be in the "url" method of the "View" class), but that's another patch.
Anyway, I hope you can incorporate these changes sometime soon. I'd hate to think my efforts were for naught.
-Steve
After reading the code submission guideline, it's not clear if I'm supposed to wait for a request to submit the patch or just go ahead and submit it. I opted for the latter, so here it is (attached).
There are still remaining issues, such as unencoded ampersands in the "action" attribute of the "form" tag generated by the "form" block (it seems that issue might be in the "url" method of the "View" class), but that's another patch.
Anyway, I hope you can incorporate these changes sometime soon. I'd hate to think my efforts were for naught.
-Steve
x1 
Thanks for doing this Steve
Mar 05, 2010 at 6:51 PM
I agree with this, and would like to also emphasize that WC3 compliance, though hard to achieve often in any given CMS, is a REALLY great bragging point from a marketing perspective.
If this is achievable.... it should be done and made a priority.
has my vote.
If this is achievable.... it should be done and made a priority.
has my vote.
educate me.
Mar 08, 2010 at 2:30 PM
Why?
Our position today is this:
Having a view layer for concrete5 that is W3C compliant is important. It makes it easier to achieve ADA compliancy if that's a requirement and is generally a pretty achievable goal. I can see running a rendered page through a validator and having it pass without an endless amount of work or code added. Certainly the core blocks and themes that come with a concrete5 install should not introduce code that is not W3C complaint in view mode if at all possible.
Does that mean I'd deny an add-on or theme that wasn't W3C compliant? Nope. There's enough challenges for those developers already. ;)
Having the entire application in edit mode be W3C compliant seems like a completely misguided goal, and possibly un-provable/testable anyway. How do I send a page in edit mode through a validator? How can one test the various ajaxy modal states in concrete5? Moreover, to what end? Why does the editing experience need to be this clean? If it works in most browsers, doesn't it work? If our view layer is W3C complaint, can't we claim it on our about pages for marketing purposes - if that is the only real goal here?
Look, neither Andy or I are fans of sloppy code and short cuts. Both happen in life, but I don't believe concrete5 has much of either compared to other successful projects. As much as I frown on sloppy code, I also frown on perfection for perfection's sake. You'll hear the same argument from me with the CS majors who complain that concrete5 isn't as strictly OOP as it could be. It's OOP enough. There's a price you pay for over architecting something (go dig through Magento for an afternoon). The promise of OOP is that you'll be able to pickup someone else's code and work with it without having to understand every in and out.. I argue W3C compliance is the same thing - here's what perfection looks like, now get as close as you need to be. The last thing I want to do is add hundreds of lines of code for some CDATA parameters to the core that could introduce un-knowable syntax errors and new challenges.
As my Dad used to say: just because you can, doesn't mean you should.
but perhaps I'm missing something here?
Our position today is this:
Having a view layer for concrete5 that is W3C compliant is important. It makes it easier to achieve ADA compliancy if that's a requirement and is generally a pretty achievable goal. I can see running a rendered page through a validator and having it pass without an endless amount of work or code added. Certainly the core blocks and themes that come with a concrete5 install should not introduce code that is not W3C complaint in view mode if at all possible.
Does that mean I'd deny an add-on or theme that wasn't W3C compliant? Nope. There's enough challenges for those developers already. ;)
Having the entire application in edit mode be W3C compliant seems like a completely misguided goal, and possibly un-provable/testable anyway. How do I send a page in edit mode through a validator? How can one test the various ajaxy modal states in concrete5? Moreover, to what end? Why does the editing experience need to be this clean? If it works in most browsers, doesn't it work? If our view layer is W3C complaint, can't we claim it on our about pages for marketing purposes - if that is the only real goal here?
Look, neither Andy or I are fans of sloppy code and short cuts. Both happen in life, but I don't believe concrete5 has much of either compared to other successful projects. As much as I frown on sloppy code, I also frown on perfection for perfection's sake. You'll hear the same argument from me with the CS majors who complain that concrete5 isn't as strictly OOP as it could be. It's OOP enough. There's a price you pay for over architecting something (go dig through Magento for an afternoon). The promise of OOP is that you'll be able to pickup someone else's code and work with it without having to understand every in and out.. I argue W3C compliance is the same thing - here's what perfection looks like, now get as close as you need to be. The last thing I want to do is add hundreds of lines of code for some CDATA parameters to the core that could introduce un-knowable syntax errors and new challenges.
As my Dad used to say: just because you can, doesn't mean you should.
but perhaps I'm missing something here?
Absolutely correct, but you miss one point in fact
Mar 08, 2010 at 5:02 PM
that is accessibility.
Concrete5 gives the user a rich experience, and it should give users with limited abilities a rich experience too.
I mean I would never forgive myself, if I wrote an editor which can't be used by Steven Hawking.
We need an ARIA compatible back and front-end. I mean only for the concrete5 core. Addon makers are left on their own.
This is important imho for the c5 roadmap:
WAI-ARIA -http://www.w3.org/TR/wai-aria-roadmap/...
Concrete5 gives the user a rich experience, and it should give users with limited abilities a rich experience too.
I mean I would never forgive myself, if I wrote an editor which can't be used by Steven Hawking.
We need an ARIA compatible back and front-end. I mean only for the concrete5 core. Addon makers are left on their own.
This is important imho for the c5 roadmap:
WAI-ARIA -http://www.w3.org/TR/wai-aria-roadmap/...
W3C Compliance 101
Mar 08, 2010 at 5:04 PM
> Having a view layer for concrete5 that is W3C
> compliant is important.
And that's what I'm interested in.
> It makes it easier to achieve ADA compliancy if
> that's a requirement and is generally a pretty
> achievable goal.
There are a number of reasons to generate W3C compliant code, and I would go so far as to say it's actually quite easy to achieve.
> I can see running a rendered page through a
> validator and having it pass without
> an endless amount of work or code added. Certainly
> the core blocks and themes that
> come with a concrete5 install should not introduce
> code that is not W3C complaint
> in view mode if at all possible.
It is not only possible, it's quite simple. You just have to be familiar with the (fairly simple) rules - not a daunting task at all. And BTW, some of the changes I made are to core blocks and the default themes, which you specifically mentioned in your remark.
> Does that mean I'd deny an add-on or theme that
> wasn't W3C compliant? Nope.
You can do whatver you want, but I personally would not use/purchase a theme or package that I knew was not compliant. And I suspect developers would quickly fall in line and make the effort (small as it is) to get their code to validate if they knew how easy it was and that it was important to people. I have to say that your apparent nonchalance about the issue is, I think, unfortunate. I mean, you're in a position to AT LEAST encourage W3C compliance, yet it's mentioned nowhere in the dev docs that I can see.
> There's enough challenges for those developers
> already. ;)
I would hardly characterize W3C compliance as a "challenge". I get the impression you don't realize how simple it really is.
> Having the entire application in edit mode be W3C
> compliant seems like a completely misguided goal..
Whoa horsey! I'm not sure what prompted that statement, but if it's in response to anything I've said, it's misdirected. I'm not pushing for that at all. (That said, however, I see absolutely no reason it couldn't be, but you obviously have some aversion to it, so no big deal.)
> As much as I frown on sloppy code...
> It's OOP enough...
Ok, you seem to be digressing and getting a bit defensive. Look, my intention is not to ruffle your feathers. My comments, while critical, are constructively so. I mean, if I wasn't using your product or didn't care about it, I wouldn't have spent my time trying to help you improve it.
> The last thing I want to do is add hundreds of
> lines of code for some CDATA
> parameters to the core that could introduce
> un-knowable syntax errors and
> new challenges.
(As if there aren't hundreds of lines of comments in the code already - some of which are just lines of code that have been commented out.) Anyway, your statement implies a lack of knowledge about CDATA sections within script tags. It seems you have a fear of the unknown, but I think your fear is baseless. If you can explain to me how comment lines (two extremely short comment lines at that) within a block of embedded JS code can cause syntax errors, I'd be very interested to know. And the reasons I made changes to the core are twofold:
1) It was FAR easier to simply fix all the issues I encountered than try to determine on an issue-by-issue basis whether they would impact the view layer or were restricted to the core or admin layer.
2) There are places in the core that generate content which winds up on the view layer, so I just "fixed" everything I found (although I certainly don't claim to have found everything).
FWIW, I've been using my modified code base for days now (in and out of admin mode) with no issues whatsoever. That doesn't mean an issue won't crop up at some point, but I can guarantee that if/when it does, it'll be utterly trivial to fix. I mean, for all practical purposes, all I really did was simply add a bunch of comments!! At any rate, I've yet to hear a rational well-reasoned argument as to why these changes should'nt be incorporated into the code or why you choose not to mention (let alone encourage) W3C compliance in your dev docs. But of course, that's your decision, and I'm certainly not going to beat my head against a wall over it.
> As my Dad used to say: just because you can,
> doesn't mean you should.
As my dad used to say: If you're going to do something, do it right, or don't bother doing it at all. ;-)
Pasta lasagna, don't get any onya...
-Steve
> compliant is important.
And that's what I'm interested in.
> It makes it easier to achieve ADA compliancy if
> that's a requirement and is generally a pretty
> achievable goal.
There are a number of reasons to generate W3C compliant code, and I would go so far as to say it's actually quite easy to achieve.
> I can see running a rendered page through a
> validator and having it pass without
> an endless amount of work or code added. Certainly
> the core blocks and themes that
> come with a concrete5 install should not introduce
> code that is not W3C complaint
> in view mode if at all possible.
It is not only possible, it's quite simple. You just have to be familiar with the (fairly simple) rules - not a daunting task at all. And BTW, some of the changes I made are to core blocks and the default themes, which you specifically mentioned in your remark.
> Does that mean I'd deny an add-on or theme that
> wasn't W3C compliant? Nope.
You can do whatver you want, but I personally would not use/purchase a theme or package that I knew was not compliant. And I suspect developers would quickly fall in line and make the effort (small as it is) to get their code to validate if they knew how easy it was and that it was important to people. I have to say that your apparent nonchalance about the issue is, I think, unfortunate. I mean, you're in a position to AT LEAST encourage W3C compliance, yet it's mentioned nowhere in the dev docs that I can see.
> There's enough challenges for those developers
> already. ;)
I would hardly characterize W3C compliance as a "challenge". I get the impression you don't realize how simple it really is.
> Having the entire application in edit mode be W3C
> compliant seems like a completely misguided goal..
Whoa horsey! I'm not sure what prompted that statement, but if it's in response to anything I've said, it's misdirected. I'm not pushing for that at all. (That said, however, I see absolutely no reason it couldn't be, but you obviously have some aversion to it, so no big deal.)
> As much as I frown on sloppy code...
> It's OOP enough...
Ok, you seem to be digressing and getting a bit defensive. Look, my intention is not to ruffle your feathers. My comments, while critical, are constructively so. I mean, if I wasn't using your product or didn't care about it, I wouldn't have spent my time trying to help you improve it.
> The last thing I want to do is add hundreds of
> lines of code for some CDATA
> parameters to the core that could introduce
> un-knowable syntax errors and
> new challenges.
(As if there aren't hundreds of lines of comments in the code already - some of which are just lines of code that have been commented out.) Anyway, your statement implies a lack of knowledge about CDATA sections within script tags. It seems you have a fear of the unknown, but I think your fear is baseless. If you can explain to me how comment lines (two extremely short comment lines at that) within a block of embedded JS code can cause syntax errors, I'd be very interested to know. And the reasons I made changes to the core are twofold:
1) It was FAR easier to simply fix all the issues I encountered than try to determine on an issue-by-issue basis whether they would impact the view layer or were restricted to the core or admin layer.
2) There are places in the core that generate content which winds up on the view layer, so I just "fixed" everything I found (although I certainly don't claim to have found everything).
FWIW, I've been using my modified code base for days now (in and out of admin mode) with no issues whatsoever. That doesn't mean an issue won't crop up at some point, but I can guarantee that if/when it does, it'll be utterly trivial to fix. I mean, for all practical purposes, all I really did was simply add a bunch of comments!! At any rate, I've yet to hear a rational well-reasoned argument as to why these changes should'nt be incorporated into the code or why you choose not to mention (let alone encourage) W3C compliance in your dev docs. But of course, that's your decision, and I'm certainly not going to beat my head against a wall over it.
> As my Dad used to say: just because you can,
> doesn't mean you should.
As my dad used to say: If you're going to do something, do it right, or don't bother doing it at all. ;-)
Pasta lasagna, don't get any onya...
-Steve
not being defensive. just explain the value in this for edit mode.
Mar 08, 2010 at 7:13 PM
I think you may have over-read my tone - I'm not being defensive here, I'm just trying to understand something I fully admit I don't pay a lot of attention to.
I've been building websites since 95, but I've only ever worked on one project that had to be ADA priority 2 compliant. I found at the time the guidelines to be typically bureaucratic - sound great in the abstract but very difficult to implement in real life. What does "create meaningful content" mean.. etc. You're right, my job requires a fair amount of generalizing in order to stay on top of things, so in my mind, "compliancy" does fall into the same bucket as "strict OOP" - more often than not a good thing. A nice philosophy to keep in mind as you live in the real world and have to get things done on time and under budget.
I certainly don't mean to be dismissive of your efforts - and I obviously don't want to steer my own application in a way that it will be used by fewer people than it could, I'm just not hearing compelling detail here yet. "Do it right" assumes "right" is absolute and not relative. For us, few things are that absolute. We like to understand why we're doing something - so help me!
Steven Hawking using concrete5? I mean - "go team" and all but for real? Isn't edit mode pretty far from something that is going to work with a screen reader at this point anyway? How do I validate a page in edit mode? The title of my post was "educate me" for a reason.. When I have a bit more time I'll read that link you've posted Fernandos, and I'm sure my thinking is likely way out dated, but I'm dubious. ;)
As I said before, I think everyone here is in favor of anything we need to do to make the view layer of core concrete5 stuff validate as nicely as possible.
I continue to question the value in adding this step to the development process on edit mode. "Doing it right" in this context, to me, means keeping my team focused on adding big ideas that benefit lots of people as nimbly as possible. Last thing on earth I want to hear in rolling a change out is "well we need to spend an afternoon adding syntax for compliancy." I'm not trying to be defensive here, I'm just asking for some real world understanding of what W3C compliancy in edit mode really gets me.. so far I have:
1) Good for marketing to say you're W3C compliant.
(I argue a view layer that is complaint would give me room to make that statement in a way the PR folk will like)
2) Because Steven Hawking should be able to use concrete5.
(I argue this is unlikely because I don't think he's doing a lot of drag and drop. Does this mean we need to kill the move block UI?)
3) Because we can.
(Booo! This argument rarely holds water with me because I'm old enough to know that nothing comes without a price. Any complexity you add today costs you something tomorrow - may not be much, and may be worth it, but its not a reason in itself)
4) Because we should.
(I agree for view mode, I don't understand why for edit mode)
So help me out, what am I missing about this in edit mode?
I've been building websites since 95, but I've only ever worked on one project that had to be ADA priority 2 compliant. I found at the time the guidelines to be typically bureaucratic - sound great in the abstract but very difficult to implement in real life. What does "create meaningful content" mean.. etc. You're right, my job requires a fair amount of generalizing in order to stay on top of things, so in my mind, "compliancy" does fall into the same bucket as "strict OOP" - more often than not a good thing. A nice philosophy to keep in mind as you live in the real world and have to get things done on time and under budget.
I certainly don't mean to be dismissive of your efforts - and I obviously don't want to steer my own application in a way that it will be used by fewer people than it could, I'm just not hearing compelling detail here yet. "Do it right" assumes "right" is absolute and not relative. For us, few things are that absolute. We like to understand why we're doing something - so help me!
Steven Hawking using concrete5? I mean - "go team" and all but for real? Isn't edit mode pretty far from something that is going to work with a screen reader at this point anyway? How do I validate a page in edit mode? The title of my post was "educate me" for a reason.. When I have a bit more time I'll read that link you've posted Fernandos, and I'm sure my thinking is likely way out dated, but I'm dubious. ;)
As I said before, I think everyone here is in favor of anything we need to do to make the view layer of core concrete5 stuff validate as nicely as possible.
I continue to question the value in adding this step to the development process on edit mode. "Doing it right" in this context, to me, means keeping my team focused on adding big ideas that benefit lots of people as nimbly as possible. Last thing on earth I want to hear in rolling a change out is "well we need to spend an afternoon adding syntax for compliancy." I'm not trying to be defensive here, I'm just asking for some real world understanding of what W3C compliancy in edit mode really gets me.. so far I have:
1) Good for marketing to say you're W3C compliant.
(I argue a view layer that is complaint would give me room to make that statement in a way the PR folk will like)
2) Because Steven Hawking should be able to use concrete5.
(I argue this is unlikely because I don't think he's doing a lot of drag and drop. Does this mean we need to kill the move block UI?)
3) Because we can.
(Booo! This argument rarely holds water with me because I'm old enough to know that nothing comes without a price. Any complexity you add today costs you something tomorrow - may not be much, and may be worth it, but its not a reason in itself)
4) Because we should.
(I agree for view mode, I don't understand why for edit mode)
So help me out, what am I missing about this in edit mode?
making nails with heads
Mar 08, 2010 at 7:57 PM
Hi :)
I'm going to ask a friend who is using a screen-reader and braille next month (after semester holidays).
Gonna ask her to try concrete5 and tell me what she thinks about it, regarding usability and accessibility. Because I can't speak about this topic without having actual experience with screen-readers and stuff.
btw: I don't care if it's 100% valid html/css/js or only 80% as long as it works as intended. The validity of code isn't a plus for disabled people (sorry, in case of this is not the right term) it just makes the validator happy, that's it.
Valid html is nice. but shotster, we are not trying to transform XHTML to XHTML with XSLT, so it's not a high priority.
I'm going to ask a friend who is using a screen-reader and braille next month (after semester holidays).
Gonna ask her to try concrete5 and tell me what she thinks about it, regarding usability and accessibility. Because I can't speak about this topic without having actual experience with screen-readers and stuff.
btw: I don't care if it's 100% valid html/css/js or only 80% as long as it works as intended. The validity of code isn't a plus for disabled people (sorry, in case of this is not the right term) it just makes the validator happy, that's it.
Valid html is nice. but shotster, we are not trying to transform XHTML to XHTML with XSLT, so it's not a high priority.
Huh?
Mar 08, 2010 at 9:35 PM
> Valid html is nice. but shotster, we
> are not trying to transform XHTML
> to XHTML with XSLT...
Fernandos, what exactly does that have to do with the price of tea in China? I never said or implied any such thing. And by the way, compliant mark-up is good for more than just accessibility reasons.
Anyway, I've squandered enough time on this topic. Onward and upward...
Regards,
-Steve
> are not trying to transform XHTML
> to XHTML with XSLT...
Fernandos, what exactly does that have to do with the price of tea in China? I never said or implied any such thing. And by the way, compliant mark-up is good for more than just accessibility reasons.
Anyway, I've squandered enough time on this topic. Onward and upward...
Regards,
-Steve
To whom are you speaking?
Mar 08, 2010 at 9:20 PM
Franz writes:
> So help me out, what am I missing
> about this in edit mode?
Ok, I'm not sure I should respond since I've already addressed this question in my previous reply. Either you've not read my reply thoroughly, or you're asking this question of someone else, but I'm not going to waste my time repeating myself.
-Steve
> So help me out, what am I missing
> about this in edit mode?
Ok, I'm not sure I should respond since I've already addressed this question in my previous reply. Either you've not read my reply thoroughly, or you're asking this question of someone else, but I'm not going to waste my time repeating myself.
-Steve
weird.
Mar 08, 2010 at 11:15 PM
Nope, your point was lost on me.
I maintain that in-context editing is not well suited to disability focused interface, and if I had to solve that problem for a client I'd use Single Pages to build a custom UI that was perfect for them.
In the meantime keeping the edit UI happy on recent versions of IE/FireFox/Safari/Chrome is plenty of a challenge for us, so that's what we'll consider success.
I believe the most compelling analogy that came up in IRC when describing this problem was: "putting rocket fuel in a race car and expecting it to fly."
I couldn't be more on board with you about the view layer compliancy stuff however - if you've got a patch for that shoot it on down we'd really appreciate it.
best wishes
-frz
I maintain that in-context editing is not well suited to disability focused interface, and if I had to solve that problem for a client I'd use Single Pages to build a custom UI that was perfect for them.
In the meantime keeping the edit UI happy on recent versions of IE/FireFox/Safari/Chrome is plenty of a challenge for us, so that's what we'll consider success.
I believe the most compelling analogy that came up in IRC when describing this problem was: "putting rocket fuel in a race car and expecting it to fly."
I couldn't be more on board with you about the view layer compliancy stuff however - if you've got a patch for that shoot it on down we'd really appreciate it.
best wishes
-frz
You've already got it
Mar 08, 2010 at 11:58 PM
> I maintain that in-context editing is
> not well suited to disability focused
> interface...
First off, as I stated in my lengthy reply, I'm not pushing for that at all. Please reread my message - in particular, the paragraph that starts "Whoa horsey!" I'll paraphrase it for you here... I don't give a rat's rump about W3C compliance in edit mode. It's the view layer that I'm addressing. So all your yippin' about edit mode just makes me think that you didn't actually read my message.
Secondly, just FYI, W3C compliance is about much more than accessibility issues. I'm not sure why you keep harping on that one aspect.
> I couldn't be more on board with you
> about the view layer compliancy stuff
> however
Great, we're finally actually communicating.
> if you've got a patch for that shoot it on
> down we'd really appreciate it.
You've already got it! It's all part of the patch I submitted. In addition to all the CDATA section fixes for the embedded JS code, I also moved styles in a number of core blocks from the body to the head as well as fixed some miscellaneous issues such as unencoded entities, an incorrect DOCTYPE declaration in the default theme, malformed mark-up, etc. I've mentioned all of this previously in this thread. It's all simple stuff that was trivial to fix and which a simple pass through a validator would have caught.
Happy coding,
-Steve
> not well suited to disability focused
> interface...
First off, as I stated in my lengthy reply, I'm not pushing for that at all. Please reread my message - in particular, the paragraph that starts "Whoa horsey!" I'll paraphrase it for you here... I don't give a rat's rump about W3C compliance in edit mode. It's the view layer that I'm addressing. So all your yippin' about edit mode just makes me think that you didn't actually read my message.
Secondly, just FYI, W3C compliance is about much more than accessibility issues. I'm not sure why you keep harping on that one aspect.
> I couldn't be more on board with you
> about the view layer compliancy stuff
> however
Great, we're finally actually communicating.
> if you've got a patch for that shoot it on
> down we'd really appreciate it.
You've already got it! It's all part of the patch I submitted. In addition to all the CDATA section fixes for the embedded JS code, I also moved styles in a number of core blocks from the body to the head as well as fixed some miscellaneous issues such as unencoded entities, an incorrect DOCTYPE declaration in the default theme, malformed mark-up, etc. I've mentioned all of this previously in this thread. It's all simple stuff that was trivial to fix and which a simple pass through a validator would have caught.
Happy coding,
-Steve
Just fix it
Apr 24, 2010 at 7:49 PM
It seems to me that fixing these trivial W3C issues would have taken less time than conduction this elaborated dispute ;-)
Just to mention some more issues
May 29, 2010 at 3:57 AM
I'm working actually on our website and wanted to validate it to see where we stand with valid code and accessibility.
An issue with the image block i addressed in copying the controller to the root/block folder and modifying it (border="0" & align="X" are not valid), i added 3 templates for aligning the images.
The new cell based layout is great, but there is another issue : for shared style presets is only one ID (for example <div id="blockStyle26"...), therefor invalid for both HTML and WCGA (unique identifiers). Is it possible to change those IDs to CSS classes or to have a workaround to the same IDs ?
But all in all i am happy to see that C5 got more valid since the last release !
Marc-André
An issue with the image block i addressed in copying the controller to the root/block folder and modifying it (border="0" & align="X" are not valid), i added 3 templates for aligning the images.
The new cell based layout is great, but there is another issue : for shared style presets is only one ID (for example <div id="blockStyle26"...), therefor invalid for both HTML and WCGA (unique identifiers). Is it possible to change those IDs to CSS classes or to have a workaround to the same IDs ?
But all in all i am happy to see that C5 got more valid since the last release !
Marc-André
Shotster
Version 5.4.0?
Assuming I'm correct, there do in fact appear to be W3C issues that have been addressed in the new version (as indicated by Andrew in the fireside chat thread); so some progress has been made. However, issues remain - such as the fact that while the "type" attribute has been added to the script tags, CDATA sections have not been added for embedded scripts (of which there are many).
Therefore, my offer still stands. I can submit a patch with with these and any other validation issues I encounter fixed.
-Steve