CMS Made Simple Forums

OK, let me show a practical example of what I mean. Here's the default output for the login form of the FEU module:
Note: I've removed URLs from the code for clarity.

Problems with this:

• No closing slash in
• Uses depreciated element
• No legend, fieldsets or labels
• Uses non-semantic presentational characters   &

At the very least, the output should be something like this:
This is now valid, for both XHTML Transitional and XHTML Strict, more accessible, with its associated labels for input fields, seperates content from presentation, and has more hooks for the front-end developer to attach styles to. It could go even further, but at the very least it should be like this.

This is a nice example.
But:

stopsatgreen wrote: No closing slash in

Input elements will be generated by the core since there are some functions in the CMSms API for it.
E.g CreateInputSubmit(some params).
(That means modules should use that functions to generate their output.)

These functions have been created

CMSms API Doc wrote: to make sure that id's are placed in names and also that it's xhtml compliant

Telling me that the FEUsers Module creates no valid input elements means that there might be an issue in that core functions.
But this is definitely not the case. (I checked out the source)
So this is just because the FEUsers Module provides several ways of creating output.
You can use {$input_submit} or Lang(\'login\')}" /> in your template to create the submit button.
Since the last one is kind of "hardcoded", it is indeed a "validation issue" of the standard FEUsers login template.
I don't understand why there is not the {$input_submit} tag used by default, since it would result in valid output of the button.

I agree with your opinion that modules should create valid output.
But i believe most developers think the ouput of a page is the job of the admin/designer not of the developer.
The module just provides some "content". The output is managed by the user.
So even if there would be a valid output of the module by default the admin of a page can change it in that way he wants it. And probably he makes some errors so that it results in non-valid output.

E.g. the standard example layouts of CMSms are always adapted and i've seen lots of (non-tec) users that remove the -Tag of the menu template because they don't know anything about accessibility or styling unwanted elements to be "hidden".

That means providing a fully valid, semantic and accessible output assumes also that the users know how to style a page correctly.
Most users would probably remove the of your example instead of "hiding" it.

To sum it up: I also don't know how/where to start with your idea.
My first question would not be if tables are valid or not but if templates are job of the user or of the developer?
I think at least the default templates of a module should be vaild. And this is definitly the dev's job.
So first we must change developers mind i guess.

NaN wrote:My first question would not be if tables are valid or not but if templates are job of the user or of the developer?

In this case, the user can't make the form accessible without modifying the module itself; that is clearly wrong. There is no way to add the closing / to the element from within the CMS itself, nor to add valid elements to the form; the only way to do that is to modify FrontEndusers.module.php (or other relevant) pages. We can't even discuss this being the user's responsibility if they have to make changes to the module itself in order to achieve it.

If a user wants to make any changes to his form, he should be able to do so in the templates in the CMS. We can't control what they do with the site after it's installed, but we should make sure that the mark-up the CMS & Modules generate is valid and accessible when it's first installed. That's common sense, isn't it?

stopsatgreen wrote:
the only way to do that is to modify FrontEndusers.module.php (or other relevant) pages.

In this example you just need to adapt the feu login template and add the slash or use {$input_submit} instead.
But this should not be neccessary by default.

All you can do is to report markup issues and hope that they will adapt their modules.
I think markup issues should also be filed as a bug like php or database issues.
Not just an info.

NaN wrote:In this example you just need to adapt the feu login template and add the slash or use {$input_submit} instead.

But this is what you don't understand; this IS using {$input_submit}; there is an error in the code which is output. THE USER CAN NOT CHANGE THIS IN THE TEMPLATE. This is why someone needs to take a look at all the code which is output by all the modules. This is what I am offering to do.

Unfortunately all I'm hearing is "let the users sort it out", which is a terrible way to think. I can't repeat it enough: the code that is output by the core and modules should be valid and accessible straight away; it is not the user's responsibility to correct the developers' oversights, errors or bad habits.

OK then you can download all modules and clean the code up and then offer them as cleaned up modules...

What I'm offering to do is to take a look at all the modules that are released, audit them, and provide feedback to the module developers. I really don't know why this offer has received the response it has: apathy or resistance.

Releasing software that produces invalid or outdated code is not good practice. New users who may not be completely familiar with standards will not fix the errors, and developers who care about semantic, accessible, valid code will have their experience of CMSMS diminished when they see it outputs bad code.

I want to help; I'm offering to help; but it looks like no-one cares.

Sure you can help us and we thank (it's just to many work and N stuff on dev-work), you have to understand the side of them also!

Like mark say try see what you can do, then, provide one feedback, but it's not a easy task looking all release modules

Nuno Costa

stopsatgreen wrote:
But this is what you don't understand; this IS using {$input_submit}; there is an error in the code which is output. THE USER CAN NOT CHANGE THIS IN THE TEMPLATE.

Well, this might belong to another thread but I'm using {$input_submit} in my feusers login template and there is no error in the output since {$input_submit} is generated by the core of CMSms (just take a look into the source of function.user_loginform.php at line 92). And this ouput IS valid.
The standard feusers login template uses the hardcoded inside its template without the slash at the end.
That means in the source the valid output element that you can call via smarty tag is provided.
But it isn't used in the default template.
And THAT is what I don't understand.

Ofcourse if you want to change the standard template you must get into the source and change it by yourself.
But no ordinary user wants to change the default template to make the changes to the default ones.
(Maybe this will be your job )

stopsatgreen wrote:
This is why someone needs to take a look at all the code which is output by all the modules. This is what I am offering to do.

Unfortunately all I'm hearing is "let the users sort it out", which is a terrible way to think. I can't repeat it enough: the code that is output by the core and modules should be valid and accessible straight away; it is not the user's responsibility to correct the developers' oversights, errors or bad habits.

That is why I said

NaN wrote:
I think at least the default templates of a module should be vaild. And this is definitly the dev's job.
So first we must change developers mind i guess.

And

NaN wrote:
I think markup issues should also be filed as a bug like php or database issues.
Not just an info.

I agree with your opinion.
But at the end it is the developers choice.
All you can do is to tell all developers "Hey guys! If you're lazy to create a valid output just let me join your project and clean up the template code and everything where output is produced!"

If you do want to clean up the output of eisting modules you may want to do it and test it thoroughly then contact the developer and show/discuss with them the changes you've made and there is a good chance it will be incorporated into the module...