W3C home > Mailing lists > Public > www-amaya@w3.org > January to March 2003

Feature suggestion re validation

From: elfin <elfin@elfden.co.uk>
Date: Tue, 25 Feb 2003 18:03:33 -0500 (EST)
Message-ID: <00db01c2dd07$17b76640$0200a8c0@junior>
To: <www-amaya@w3.org>




It has been suggested that this may be of interest as a possible feature, I
am directly quoting from a usenet message with the authors permission.

I for one would think it very useful, and as I can't see such a thing being
developed for the other browsers out there, it may be an interesting
addition. (assuming of course it isn't already there!!).

elfin
post follows:

From: murky@lspace.org
Message-ID: <1fqxleu.1ov4j7q1h5yav4N%murky@lspace.org>

If the tables are correctly formatted (e.g. with headers etc) then it
should be possible for the text to speech to sort it out.

The ideal fix would be if tables were not used for formatting at all,
but that the visual look was attained using a style sheet. These have
the great virtue that software that doesn't understand style sheets[1]
will not bother interpreting them, and we are left with a useable page.

http://diveintoaccessibility.org/

CSS will also allow you to have 'tables' that don't break visual
browsers when they're resized.

http://www.alistapart.com/stories/practicalcss/

There is still the issue of getting people to seperate out the
formatting and content. This will be an uphill battle, as well, it
works, doesn't it? It will only really happen when and if a) CSS has
fully stabilised and b) browsers take to adding a sentance to each page
when it is rendered saying 'this page does not use the design principles
discussed *here*' <link to page about CSS> or c) This page does not
contain valid HTML/CSS, go *here* <link to w3c validators>. This
sentance would probably appear in big bold text in the status bar or
similar.

This could be sold by including this as an option wich is on by default
but which which can be turned off. This would be a valuable tool for
webmasters when designing pages - and could rapidly mean that HTML
problems are trapped quickly. To avoid slowing d.load times, the checks
would only be performed when the rest of the information is in and the
page is rendered. Until then the status would read some holding message.

Status bar posibilities:
HTML: <check> CSS: <check> Access: <Check>
HTML: FAIL    CSS: FAIL    Access: FAIL
HTML: Pass    CSS: Pass    Access: Pass (subject to manual check)

(Accessibility cannot be fully automated)

Clicking on these would yield more infomation, e.g. Accessibility would
give details of the manual checks needed.

All three of these checks have validators out there already, and it
could be a nice little moneyspinner for the people who write the code to
produce a browser plugin.

Murk

[1] This is not the same as buggy software which claims to understand
them, but does not. This was at one point the majority, but is a
decreasing category.
--
Despite lapsing in recent days, an afper since I had to
make a national rate  phone call to get online.
Received on Wednesday, 26 February 2003 03:08:16 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:53:27 UTC