Small, nitpicky request concerning XHTML compliance…

[Alhadis]

Hey folks,

Something I noticed while working with this plugin; I’m developing an XHTML 1.1 site for a client that’s using PixoPoint Menu plugin, and noticed badly formed markup in the Search form:

[code:x8aot137] <form method="get" action="http://b2b2.com.au/si" > &nbsp;
<input type="text" value="" class="pixo_inputsearch" name="s" /> <input type="submit" value="Search" /> &nbsp;
</form>[/code:x8aot137]

The non-breaking spaces – as well as the rest of the form’s contents, should be nested inside a block-level element to separate it from the containing form tags (otherwise, it won’t validate).

Now, this is probably triggering a chorus of groans and "Who cares?" from people (and indeed, it really is only a small nitpick for those of us who develop sites to meet XHTML compliance), but the fact this could easily be circumvented by replacing the delimiting non-breaking spaces with a [tt:x8aot137]<fieldset>[/tt:x8aot137] element prompted me to point it out. It could easily be edited out in the plugin’s core (as I’ve just finished doing) but that’d naturally mean every installation of the plugin would have to be edited – sloppy work.

On the other hand, changing the form’s output in a future release might have consequences to themes who have style rules applied to fieldset tags, which suddenly change without warning… Couldn’t there be an option to define the search form’s markup? Or better yet, a way of executing PHP code inline through the "Custom Code #" menu item?

I’m aware how banal the issue is, but my underlying suggestion is that the form could always supply a greater amount of control to the user for the other elements…

– J

[imported_Ryan]

Thanks for the report. And yes, that is important. I hadn’t realised that would trigger a validation error actually and I’ll add it to the list of corrections for the next version.

Thanks ” title=”Smiley” />

I’m not sure if it’s of any use, but I’ve given you a free advanced features subscription for our [iurl=https://geek.hellyer.kiwi/suckerfish_css/]menu CSS generator[/iurl] as an extra thank you for your bug report. These sorts of bug reports are had to come by and I really appreciate them.

[Alhadis]

Oh! And here was I was worrying I was being too meticulous.

Happy to have been of service then – and thanks! ” title=”Smiley” />

[EDIT: While I’m here, may I also suggest a minor enhancement to the "Custom Code" item being used? I think it’d be helpful for developers if an option was supplied to trigger a callback or action specified by the function’s name. I noticed that inline PHP code wasn’t working, which made it all the harder to integrate custom content into the menu. If you had an option for specifying a callback, it’d open up a lot of doors for theme developers. ” title=”Smiley” /> Just a suggestion.)

[imported_Ryan]

Hmmm, interesting idea. I’d ruled out allowing PHP directly in there due to security concerns, but a callback function might be doable.

And no, definitely not nit-picky. I’m surprised I let the one slip through myself, I’m quite pedantic about such things, albeit I’ve gotten rather lazy these days and more and more bugs like that keep slipping through the cracks.

[imported_Ryan]

Sorry for the delay. I just got to this today and have fixed this validation bug in my current test version ready for the next release.

[Author]

Posts