Re: Evaluation results: Priorities

Helen is on her way to CSUN, so any comments posted from this address are
just from me!

My comments = CC::, Wendy's comments = WC::

WC::
>The Guidelines document need to be as "timeless" as possible thus we need
>to avoid creating a laundry list of who supports which elements at the
>time of the writing of the document.

CC::
That makes sense to me, but was a concern of the participants in the study.

WC::
>That's why we included the section in the techniques document about
>browser support - so that people could use the sites that keep track of
>that information.

CC::
Are there plans to expand the browser support section? There is a link to
the W3C TR site, but I couldn't (immediately) find anything about browser
support. Is there a specific document (TR) that the Techniques could link
to?

WC::
>Also, we don't have know who will support which elements/attributes, nor
>can we predict if all of the new elements/attributes will be supported by
>main stream browsers or only special devices.

CC::
Maybe it's worth making these unknowns more explicit. Then authors may be
less surprised if they are informed that elements / attributes are not
supported by the browser they use, and will understand that this is not
predictable.

WC::
>Where possible we have tried to say, "until user agents...."

CC::
Checkpoint 7.4 doesn't currently say this. What should authors do until
user agents support the association of headers and cells? I seem to
remember that there used to be a Technique of using <P> or <BR> in table
cells to to make tables easier (if not accessible) for screen readers.
Could this be recommended until user agents support the association of
headers and cells? Otherwise, an author "must" use attributes that are not
supported by either the main browsers or current screenreaders (I don't
know about other special devices).

WC::
>In the techniques we state
>that certain elements or attributes are supported in HTML4, 3.2, 2.0 or
>deprecated in HTML4, etc. If your participants did not find this
>information or it was not presented in a way that made sense, then I think
>our first step is to modify our current presentation of that information.

CC::
None of them were observed to use this information (if it was available in
the version they used).  I think more links to this section would be
useful, particularly in the section of the Introduction which indicates
that not all elements / attributes are currently supported.

WC::
>Did any of the authors say why they removed an element or attribute once
>they found it was not supported? Was it because they were frustrated that
>they had "wasted time" implementing it and no one was going to use it? Or
>were they afraid it might conflict with an older browser?

CC::
Particpants seemed to be concerned that they would have something 'unknown'
in their page, which didn't work 'now', and they didn't know how a user
might interact with, or whether it might break an older browser.

WC::
>If the answer is the second option, then we need to highlight that using
>new features now won't hurt anything (except where noted, e.g. OBJECT).

CC:
I think this would definitely be worth highlighting.

WC::
>I suppose it might also help to point out (in the Techniques document)
>known user agents that implement newer HTML4 language features.

CC::
If these are known I think it would be useful.

Regards,

Chetz

Received on Tuesday, 16 March 1999 05:25:28 UTC