Admin->define_pages_editor.php form structure invalid html

[torvista]

I changed

FROM

<tr><?php echo zen_draw_form('language', FILENAME_DEFINE_PAGES_EDITOR, 'lngdir=' . $_SESSION['language'] . '&filename=' . $_GET['filename'] . '&action=save'); ?>
<td><table border="0" cellspacing="0" cellpadding="2">
<tr>

TO

<tr>
<td><?php echo zen_draw_form('language', FILENAME_DEFINE_PAGES_EDITOR, 'lngdir=' . $_SESSION['language'] . '&filename=' . $_GET['filename'] . '&action=save');
<table border="0" cellspacing="0" cellpadding="2">
<tr>

AND

</table></td>
</form></tr>

TO

</table></form></td>
</tr>

...there are more but I thought I'd test the water first....

[DrByte]

What functionality is broken by this? Which specific browsers are affected?

[lat9]

What functionality is broken by this? Which specific browsers are affected?

Like torvista indicated, the Define Pages Editor is the tip of the iceberg on this issue; there are many other admin pages that use a similar, invalid HTML structure when defining their forms. I've not (yet) seen the invalid HTML affect a browser's rendition of the page, but that's not to say that over time browsers won't tighten the rules (in a manner similar to the more recent versions of PHP).

[torvista]

What functionality is broken by this? Which specific browsers are affected?

None that I have seen, but since Zen Cart is 1.x is bug-free, there's not much left to correct except for these unimportant html errors. The catalog is 100% valid, unique among the carts that I've tried, why not the admin too, now it's gradually getting some attention.

I am always interested in correcting them as if the vanilla page is 100% valid, its easier to spot when my mods introduce new errors.
As it's such a low priority the community should be encouraged to find and fix them, to save dev time.
And in the end if something is wrong, it should be corrected whether it causes a problem or not.

[DrByte]

It's a massive change to incorporate into 1.5.2, so it won't be.

Many improvements are going into 1.6.0 though.

[torvista]

So, is there any point reporting these errors?

I would have said yes as they are things anyone can fix but can be time-consuming to clear (in the case of table errors) so better the community does them.
They could be all in one thread for trivial code-compliance/non-breaking functionality rather than cluttering up the forum with threads per minor error.

[DrByte]

So, is there any point reporting these errors?

Sure. One post saying that there is (technically) an HTML structural error in various admin pages is fine.
Since the same constructed element is used consistently throughout, a single report is sufficient.

If I recall correctly there was a very specific reason why the HTML was ordered that way, because certain browsers were rejecting the "correct" way and actually breaking. But that was many years ago, and I've forgotten which one, and to be fair the problem may no longer exist with reasonably modern browsers.

As a team we'd rather not touch any of those nested-tables at all, unless it's to rip them out and replace the entire page with modern markup. This may explain some of the reluctance I'm expressing here with respect to this type of report.
But the problem with massively ripping out and replacing code is that it breaks plugins, and then the masses of people complain that their plugins are all broken or have to be rewritten. So, we have to be selective about "when" we inflict that pain, while still attempting to maintain forward motion so that things aren't terribly outdated.
But now I'm waxing philosophical. Sorry.

I do appreciate your careful eye and your reports of your findings. Please don't take my feedback as negative. I have to be mindful of the 200,000 live shops that are affected by changes :)