Re: Ascertaining the user's needs and preferences: implications for the spec

James Craig <jcraig@apple.com> wrote:
> > 1. If the value of a proposed variable in the need/preference profile is not
> > ascertainable at all in any user agent at the time the spec enters Last Call,
> > should the variable be omitted from the current version of the spec, e.g., 1.0
> > for the first release?
> 
> Yes.
> 
> > Why or why not?
> 
> Because we have to prove implementability in two user agents.
> 

I think this is an important clarification (here and at the meeting).

Note the implication regarding our conformance requirements: supporting the
fields defined in the API isn't enough. there must be an
implementation-defined mechanism for setting the value. For example,
supporting the "transcripts" preference by always returning false wouldn't
qualify.
> > 3. If there are expected to be two interoperable implementations of a
> > given feature, but not all user agents would support it (lacking the
> > mechanisms to obtain the need/preference value), how should the working
> > group respond?  Should the spec be modularized, or should the proposed
> > feature be omitted? Are there other possibilities?
> 
> If there are two implementations of a feature, the approach for the others
> that do not support said feature is to file bugs in the user agents'
> respective bug trackers, and expect them to implement the feature at some
> point in the future.
> 

This implies that every user agent must support every feature in order to
conform, hence no modules.
> > 4. If the value of a proposed need/preference variable is not currently
> > ascertainable, should the spec recommend a mechanism for obtaining it, for
> > example that user agents add a configuration option to their user
> > interfaces?
> 
> That’s a slippery slope. If we suggest anything, if may be that the browsers
> implement a configuration file for these, rather than specify something like
> a graphical user interface option. Each browser can then determine if or how
> they want to expose those configuration options to the end user.
> 
> Given that some of these will likely end up being media queries, it may make
> sense to define these similarly to a user style sheet.
> 

This seems entirely reasonable.
> > Should any guidance for collecting needs/preferences from the
> > hardware/software environment be given? what are the interoperability
> > issues here, if different UAs collect the information differently?
> 
> I think that’s squarely outside the scope of IndieUI, since it affects
> platform and browser implementations.

I think it would be hepful at this point to determine whether everyone agrees
about what the browser conformance requirements should be.

Received on Thursday, 3 October 2013 08:53:45 UTC