W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > April to June 2005

Re: [Techs] Divide Techniques docs into chapters?

From: Jason White <jasonw@ariel.its.unimelb.edu.au>
Date: Thu, 14 Apr 2005 15:39:27 +1000 (EST)
To: John M Slatin <john_slatin@austin.utexas.edu>
cc: w3c-wai-gl@w3.org
Message-ID: <Pine.GSO.4.58.0504141526040.65@ariel.its.unimelb.edu.au>



On Wed, 13 Apr 2005, John M Slatin wrote:

>
> One suggestion was to adopt anapproach similar to the I18N group: put
> important user agent information at the beginning of each technique, so
> readers could decide right away whether to bother reding that technique
> or not.

An alternative would be to state at the beginning of each technique
in which baseline or baselines it was supported, then to provide user
agent information for each baseline in a separate section, including any
qualifications needed in relation to specific techniques.

>
> I had a thought about dividing the larger Techniques documents into
> chapters corresponding to the three "baselines" that have been proposed.
> I took an action item to write it up, so here it is.  There really isn't
> much more to it than that.  On this model, each Technology-specific
> Techniques document would have three chapters (or call them Sections if
> you prefer).   Each chapter or section would cover one baseline (e.g.,
> Basic, Transitional, Advanced or whatever).  All the techniques that
> could be used for each of the baselines would be contained in the
> chapter for that baseline.  Each chapter could begin with an Overview
> section that would describe the baseline and considerations relevant to
> it.  A good deal of user agent information could be addressed in this
> Overview section.

My concern here is that many of the techniques may turn out to be relevant
to all three baselines. You would either have to duplicate this
information for each baseline, thereby lengthening the document
unnecessarily, or provide lots of cross-references to techniques described
in connection with one baseline that are also applicable to the others.

>
> The possible advantages to this approach are:
> - might avoid duplicating large quantities of UA information in multiple
> techniques (and might therefore be easier to update as UA situation
> changes);

This can be achieved by assigning each technique to one of the baselines
and maintaining the UA information separately. If someone decides they're
going to write to one of the baselines, they won't need detailed UA
information after making that decision, but they will need it in order to
decide in the first place, which is why it would make sense to maintain
this material in a separate section of the techniques document.
> - could give developers a clearer view of what a given baseline does or
> doesn't allow for.
The same with a separate section on baselines.
>
> Possible disadvantages:
> - Putting the UA information up front might make it esier to skip over,
> and might also work against providing the granular detail that might be
> needed in some cases;
How would this happen exactly?
> - collecting all techniques relevant to baseline X in chapter X might
> unintenionally limit developers' creativity; they might not become aware
> of something in a different chapter that might work for them, either for
> the site they're working on right then or for some future project;
Yes.
> - might give *us* a false sense of completeness.
>
Given the collective analytical prowess of the techniques task force and
the working group as a whole, that's a pretty distant prospect!

To clarify, I am not trying to oppose John's proposal here; if it turns
out that in most cases it wouldn't lead to massive duplication of
information then it's a perfectly fine proposal.
Received on Thursday, 14 April 2005 05:39:36 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 23:39:36 UTC