Forum OpenACS Development: Re: Checks for HTML standard compliance

A tcl/xotcl brand new validator is something I didn't want to put in the mix for now, as it would require efforts and many tests before we can rely on it. Unless someone says and proves it is very easy...

I think I can come up with something that does what I proposed, but I need a little tip.

Resuming my proposal:
into Developer Support I would put a new feature which could be turned on and off at will. When turned on, for every request which mime/type is 'text/html' (or other kind of markup subject to validation, but we could start just with HTML/XHTML for now) produced text will be sent to a validation command. Such command could be a callback or be specified by a parameter, what matters is that it is capable of telling if page is invalid and where/why.

The result of the validation will then be logged into a table. There will be a UI to inspect/manage this logging into DS and also to configure what to log. We could, for example, log only request issued by a certain user, or into a certain package, or on a single page, so one could test a page without putting server to its knees.

I would log:
- user issuing request
- timestamp
- package_key of the request
- package version
- url
- page parameters (GET/POST)
- actual script being executed
- page content
- row/column of validation error
- description of the error

I know some of this information is already logged/collected by the request processor, but I still don't understand where exactly.

What I need to know from someone with some more insights is:
- where can I intercept page content just before it is served?
- are there already tables collecting some of the stats I described?
- is this something worth trying in the first place??

building an own validator - no matter in what language - is a longer project on its own and not feasible.

One of the best HTML validators is from w3c, available as a service [1] and as a standalone program [2]. The service is very nice for many applications, but comes short when authentication is required (such as on admin pages). However, the resulting HTML file can be saved from the browser, and the standalone version works on this.

Note that this just validates the HTML code, flagging invalid and deprecated markup, but it does not flag e.g. tables. For the acs-admin/apm page, the tag "center" is deprecated, but table is not. The change [3] makes this page validating (4.01 strict). For HTML 5, it flags 12 errors (e.g. don't use "align" in tables, use CSS instead, etc.) for this page. In a further step it would be nice to pull out some of the style attributes and place these to a common CSS file.

The examples of acs-admin/apm and acs-admin/developer show that it is very hard to come up with an automated change script to fix table based designs, since different techniques are necessary for centering, right-aligning, etc. depending on the context.

-g

[1] https://validator.w3.org/
[2] https://validator.w3.org/source/
[3] http://cvs.openacs.org/changelog/OpenACS?cs=MAIN%3Agustafn%3A20150529090902

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?

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.

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

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

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.