eCart produces invalid markup

The latest version of eCart still produces invalid code. Given the idea of these extensions is to save time, more time could be saved quite easily with a few fixes. For example some of the forms close <input> tags correctly; others don't. Eg Add To Cart doesn't close these correctly and uses "POST", instead of "post". Given a page may contain many products, a product page may contain a large number of errors. I don't imagine these errors will prevent a page from working properly but it makes it more difficult to find more serious errors. In any case, I think it's good practice to produce pages which validate.

I've given some examples above, but it's easy to find these and other errors. Eg:
Products_Results.php
This page contains 79 errors and 42 warnings when run throught the W3 validator. I think both figures should be zero as this is meant to be a professional product.

I appreciate error results will depend on the DOCTYPE, but this is using the DOCTYPE you have chosen. The result is almost the same if Transitional is used rather than Strict anyway.

Tom Dupre

Tom,

On the power store page you mention, it actually is not invalid mark-up... what it is has to do with the fact that there are AJAX widgets on the page. This is a known issue that page validators cannot correctly read pages with AJAX and especially Adobe's Spry framework which the page in question does contain three Spry widgets. I know that Adobe has documentation on some additional code that can be placed in the Doctype declaration that tells the W3 Validator not to mistake the Spry code for HTML markup code - which is what happens. The code itself, however, is not invalid - it's just that the W3 Validator thinks it is bad HTML code when it actually has nothing to do with HTML code but rather the Javascript framwework which it calls to perform the tasks on the page.

Warmest regards,

Brian

Brian,

Thank you for your comments; while I don't agree with all of your points, the fact remains that eCart produces invalid code and the code is inconsistent in this respect. It is not difficult to modify the code but it becomes tedious to do say every time the extension is used, particularly when corrections are overwritten when using the eCart interface to make a minor change. It's often simpler to modify the code directly; with a little work from Webassist, the extension could produce valide code and the interface would be more useful (this applies to other extensions too).

>On the power store page you mention, it actually is not invalid mark-up...<

This illustrates well one of my points - that large numbers of errors make it difficult to spot what may be oversights on the developer's part (rather than shortcomings of the W3 Validator). This page is not valid - there are missing Alt tags, ampersands are not encoded, invalid attributes are used etc..

>This is a known issue that page validators cannot correctly read pages with AJAX and especially Adobe's Spry framework which the page in question does contain three Spry widgets.<

I haven't used Spry much, but I thought these issues had been addressed. However I did use Spry on a site I'm just finishing off, on the Advanced Search feature at the top left of the page on this site:
www.jarndyce.co.uk/
The page validates; I don't think I had to make any modification to make it do so. I use Ajax on a number of pages and they all validate too (these are in the admin section -I use Ajax to facilitate drag and drop sorting of tables, using a similar method to one you described recently).

Generally I think this is an area Webassist should take more care with. The WA homepage fails validation with a series of extremely basic errors - eg name attributes containing spaces, commas and colons. I don't know if any page is completey valid on the WA site or PowerStore. It doesn't give a very good impression, given the business they're in, and they could easily fix these issues. However I'm more concerned that their extensions should be more professional in this respect.

Regards,
Tom

Hi Tom,

I don't disagree at all that more could be done to overcome this, I just was making it known sure for people who use Spry and AJAX regularly that this still is an issue. I think it is more prevalent on some Spry widgets than others. I have seen it on several that I have created. I actually like the Spry framework but have always been baffled by how hard it is to get validated. I think the best option for anyone who uses Spry (or AJAX at all for that matter) is to look at Dreamweaver CS4's built-in JavaScript extractor which can convert each pages AJAX widgets to pure javascript. I know this is what Adobe experts have recommended doing after the pages have been built and are ready for production.

Regards,

Brian