Forum OpenACS Development: Re: Checks for HTML standard compliance

10: Re: Checks for HTML standard compliance (response to 8)

Posted by Antonio Pisano on 06/08/15 07:55 PM

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?

11: Re: Checks for HTML standard compliance (response to 10)

Posted by Antonio Pisano on 06/08/15 07:56 PM

(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?

12: Re: Checks for HTML standard compliance (response to 11)

Posted by Benjamin Brink on 06/08/15 08:46 PM

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.

13: Re: Checks for HTML standard compliance (response to 12)

Posted by Benjamin Brink on 06/08/15 08:56 PM

To be clear, I'm referring to the INPUT tag where type is "submit", not the BUTTON tag.

14: Re: Checks for HTML standard compliance (response to 11)

Posted by Gustaf Neumann on 06/09/15 09:14 AM

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

15: Re: Checks for HTML standard compliance (response to 14)

Posted by Antonio Pisano on 06/09/15 09:44 AM

Much simpler! Thanks, didn't think about that. I will keep it in mind for next similar cases!

16: Re: Checks for HTML standard compliance (response to 15)

Posted by Gustaf Neumann on 06/09/15 10:42 AM

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

17: Re: Checks for HTML standard compliance (response to 15)

Posted by Gustaf Neumann on 06/13/15 10:33 PM

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

18: Re: Checks for HTML standard compliance (response to 17)

Posted by Antonio Pisano on 06/14/15 04:27 PM

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.

19: Re: Checks for HTML standard compliance (response to 18)

Posted by Gustaf Neumann on 06/15/15 01:31 PM

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