W3C home > Mailing lists > Public > www-voice@w3.org > July to September 2003

[apologies] Re: forms terminology in CSS3 Basic UI

From: Al Gilman <asgilman@iamdigex.net>
Date: Thu, 31 Jul 2003 10:37:23 -0400
Message-Id: <5.1.0.14.2.20030731103507.02728270@pop.iamdigex.net>
To: www-voice@w3.org

Sorry, I mis-addressed the previous message which should have gone to 
www-style. - Al

At 09:53 AM 2003-07-31, Al Gilman wrote:

>[individual comment, not reviewed in PF group.]
>
>General Reference:
>
>http://www.w3.org/TR/css3-ui/
>
>1. :out-of-range
>
>In
>
>  3.1.3. :in-range and :out-of-range
>  http://www.w3.org/TR/css3-ui/#pseudo-range
>
>there appears to be a mis-use of XForms terminology.
>
>Where it says
>
><quote
>cite="http://www.w3.org/TR/css3-ui/#pseudo-range">
>
>    v... In summary: an element is
>    :out-of-range when it does not accurately reflect the state of the
>    model.
>
></quote>
>
>..should it not say "the state of the instance"?  Suggest you cross-check 
>with XForms.
>
>A possible re-wording of the whole paragraph would be:
>
><draft
>class="possible clearer">
>
>The :in-range and :out-of-range pseudo-classes are defined with respect to the
>limitations of the rendered or concrete interface, as opposed to the :valid
>and :invalid pseudo-classes defined above which reflect the logical 
>limitations
>imposed by the application or business logic through the model.
>
>A rendered element is :out-of-range when the value in the bound instance that
>it should display is beyond its capability to display.  For example, a slider
>which can show values from 1-10 when the value in the instance is 11 would
>have :out-of-range true and :in-range false.
>
></draft>
>
>2. What's a form element?
>
><quote
>cite="http://www.w3.org/TR/css3-ui/#pseudo-required-value">
>
>     3.1.4. :required and :optional
>
>    A form element is :required or :optional if a value for it is,
>    respectively, required or optional before the form it belongs to is
>    submitted. Elements that are not form elements are neither required
>    nor optional. This spec does not defined what is a form element.
>
></quote>
>
>The last two sentences taken together form a semantic hole in the 
>specification.  This will lead to semantically-incompatible use by 
>different users and implementers and the feature will become disreputable 
>and will be avoided in practice.  Unsuitable in a specification.
>
>Consider instead:
>
>Cite specifically the items in the XForms schema and HTML specification
>which have the intended semantics, and extrapolate gracefully from there.
>
>Say things like
>
>processors MUST recognize the following conditions as :required and :optional
>where the XForms schema applies:...
>
>processors MUST recognize the following conditions as :required and 
>:optional where HTML 4.01 semantics applies by specification:...
>
>processors MAY recognize these pseudo-classes in formats which use clearly
>equivalent semantics
>
>processors SHOULD NOT recognize either :required or :optional in the 
>absence of
>any of these conditions.
>
>Al
Received on Thursday, 31 July 2003 10:37:28 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 30 October 2006 12:48:58 GMT