Forum OpenACS Development: Re: Checks for HTML standard compliance

Collapse
Posted by Antonio Pisano on
I've started bumping my head on the task, starting from /admin UI. Right now the following pages look ok:

- /admin/applications/
- /admin/configure
- /admin/permissions
- /members/
- /shared/parameters
- /admin/subsite-add

Headaches start at /admin/site-map/ though... in there you may find that forms are being nested into a table in an illegal way from HTML 4.01 Strict perspective.

It is really not obvious how to get out of that without redesigning the page. We could use a <div> instead than a <table> layout for the list for example.

Another strategy which COULD be easier is to remove all nested <form> tags and wrap the entire list into a unique form. It is not easy though, because there are 3 different actions that can be taken based on which button has been pressed. Buttons that trigger different actions for a single form require either a little javascript or HTML5.

This is just for the sake of keeping current UI unaltered for the user, of course. We could just have forms handled in their respective page.

Which is best for you?

Collapse
Posted by Antonio Pisano on
(Put markup in the message and got messed up, sorry)

I've started bumping my head on the task, starting from /admin UI. Right now the following pages look ok:

- /admin/applications/
- /admin/configure
- /admin/permissions
- /members/
- /shared/parameters
- /admin/subsite-add

Headaches start at /admin/site-map/ though... in there you may find that forms are being nested into a table in an illegal way from HTML 4.01 Strict perspective.

It is really not obvious how to get out of that without redesigning the page. We could use a div instead than a table layout for the list for example.

Another strategy which COULD be easier is to remove all nested form tags and wrap the entire list into a unique form. It is not easy though, because there are 3 different actions that can be taken based on which button has been pressed. Buttons that trigger different actions for a single form require either a little javascript or HTML5.

This is just for the sake of keeping current UI unaltered for the user, of course. We could just have forms handled in their respective page.

Which is best for you?

Collapse
Posted by Benjamin Brink on
Antonio, you write:

"Buttons that trigger different actions for a single form require either a little javascript or HTML5."

Is this because of how ad_form works?

Using html (or the q-forms package ), multiple submit buttons can be embedded in the same form.

Submitted forms can then take action according to the name and value returned with the submit button; other submit button's name and value attributes are ignored.

Collapse
Posted by Benjamin Brink on
To be clear, I'm referring to the INPUT tag where type is "submit", not the BUTTON tag.
Collapse
Posted by Gustaf Neumann on
Antonio,

the page was easy to fix by wrapping the input fields into a div (see [1]). Validation-wise there is no need to revamp this page.

-g

[1] http://cvs.openacs.org/changelog/OpenACS?cs=MAIN%3Agustafn%3A20150609071032

Collapse
Posted by Antonio Pisano on
Much simpler! Thanks, didn't think about that. I will keep it in mind for next similar cases!
Collapse
Posted by Gustaf Neumann on
actually, HTML attribute quoting seems to have changed over the years. as i remember, during the accessibility reform of dotlrn, quotes around HTML attributes were required. Nowadays, HTML5 does not require quoting attributes, HTML4 seems to recommend quotes, only XHTML requires it.

anyhow, i've added quotes to the HTML attributes of the admin pages of acs-subsite were i found it missing, since for variable attribute values omitting quotes is always dangerous.

-g

[1] http://cvs.openacs.org/changelog/OpenACS?cs=MAIN%3Agustafn%3A20150609075752
[2] http://cvs.openacs.org/changelog/OpenACS?cs=MAIN%3Agustafn%3A20150609072638
[3] http://cvs.openacs.org/changelog/OpenACS?cs=MAIN%3Agustafn%3A20150609084041

Collapse
Posted by Gustaf Neumann on
Actually, saving the content of the pages via browser has apparently some disadvantages, since - at least for firefox - the browser rewrites some parts - and fixes some invalid markup.

Therefore, i've implemented some support to capture the server output optionally [1] and fixed with that tool a few more validation problems of the admin pages. The problem with the site-map page is actually a nasty one, since the old code implemented a form starting in one table cell and ending in another one, which is invalid HTML. The fixed version [2] does not look exactly as before, but i think it is still sufficiently easy to understand. Other options would be to start the form before a <tr>, but i have no idea to achieve this with the list template.

[1] http://cvs.openacs.org/changelog/OpenACS?cs=MAIN%3Agustafn%3A20150613202408
[2] http://cvs.openacs.org/changelog/OpenACS?cs=MAIN%3Agustafn%3A20150613200556

Collapse
Posted by Antonio Pisano on
This is going to be hard work, and currently my time has shrinked...

Anyway, I have looked at your technique to log ns_return and maybe I will come up with something to reduce some passages.

Collapse
Posted by Gustaf Neumann on
yes, it is some work.

I've set up a wiki page [1] for the pages I've fixed (and checked) so far to avoid duplication of work. please update this page as well (also, everybody else is invited to help). I found as well several public pages which needed some fixing.

-g

[1] https://openacs.org/xowiki/oacs-5-9-html-validity