Re: [css3-ui] PFWG comments on CSS Basic User Interface Module Level 3

On Thu, Feb 23, 2012 at 12:44 PM, Michael Cooper <cooper@w3.org> wrote:
> Below are comments from the Protocols and Formats WG on CSS3 UI, draft of 17
> January 2012 http://www.w3.org/TR/2012/WD-css3-ui-20120117/. These comments
> have not all been vetted by the PFWG, but we are mindful of the extended
> deadline you gave us, which we appreciate and acknowledge we are slightly
> late to that. Thus not all comments may rise to the status of WG-to-WG
> comments but we appreciate you taking a look, and can give input on relative
> priority in follow-up discussion if needed. PFWG discussion allowing me to
> send these comments in their current form is archived at
> http://www.w3.org/2005/02/minutes#item08 (Member link). Thank you for your
> deadline extension.
>
> 4.1.1 :active Details
> [http://www.w3.org/TR/2012/WD-css3-ui-20120117/#active]
> Does this only apply during click, or also during keypress (enter/space) on
> focused elements?

The host language defines how to activate elements.  In the case of
HTML, the HTML spec defines that keyboard activation also counts.


> 4.1.4 :valid and :invalid
> [http://www.w3.org/TR/2012/WD-css3-ui-20120117/#pseudo-validity]
> What is the difference between “lacks data validity semantics” and “has no
> constraints”? An example would be good here.

A plain <input type=text> has validity semantics, but no constraints.
Adding @required, though, would introduce a constraint.  A <div> has
no semantics at all - it can't ever be "valid" or "invalid" no matter
what you do.

I agree an example would be useful here.


> 4.1.7 :read-only and read-write
> [http://www.w3.org/TR/2012/WD-css3-ui-20120117/#pseudo-ro-rw]
> What is the difference between these state and text input fields attribute
> "disabled"?

A <input type=text disabled> is :read-only.  A <div contenteditable>
is :read-write.  These pseudos just capture the distinctions in a
host-language-agnostic way.


> 4.2 Fragments
> [http://www.w3.org/TR/2012/WD-css3-ui-20120117/#pseudo-elements]
> This could really help accessibility by allowing authors to style real form
> elements to look as desired, rather than creating their own controls with
> similar functions. Can you add some examples of how this would work with
> HTML?

Such functionality would be nice, but is not yet actually present in
any meaningful way.  It's expected for a later version of UI, if I
understand Tantek's goals correctly.


> 5.1 'content' Property Addition
> [http://www.w3.org/TR/2012/WD-css3-ui-20120117/#content-property-addition]
> Can the icon property be used to replace regular icons with high contrast
> versions? If so, please provide an example of that.

I think you may misunderstand the purpose of this property.  It exists
solely to replace an element with an image.  You can provide whatever
image you want, but this doesn't have anything to do with icons in the
browser chrome.


> The content property in CSS 2.1 is problematic for accessibility, and is the
> subject of a WCAG failure.
> http://www.w3.org/TR/WCAG20-TECHS/failures.html#F87. Are there any plans to
> address accessibility issues with content? This may be out of scope for this
> review.

Yeah, out-of-scope.  This would be appropriate for the Content spec
when someone has the time to actually edit it.


> 7. Outline Properties
> [http://www.w3.org/TR/2012/WD-css3-ui-20120117/#outline-properties]
> Outline-width=none is an accessibility problem, as it can be used to remove
> the focus rectangle from elements. Can we suggest that it be deprecated?  Or
> not allowed on focusable elements?

If you can't set outline-width to 0, you can just change the color to
transparent, or close enough as makes no difference.  If you want to
force certain elements to have an outline, this is best done in the UA
stylesheet with a UA !important rule.


> 8 Resizing & Overflow
> [http://www.w3.org/TR/2012/WD-css3-ui-20120117/#resizing-amp-overflow]
> The resize property is good. Users can resize elements that have clipped
> their contents so that the content can be viewed. This sort of clipping is a
> common bug when users resize the font in browsers or operating systems, and
> having a mechanism to adjust is a good thing. Zooming has made this bug less
> common, but it still occurs with some OS settings. Any chance this could
> default to ‘both’ so that users can resize things when the author hasn’t
> thought of it?

You don't really want a visible resizing mechanism on most elements by default.

~TJ

Received on Thursday, 23 February 2012 22:58:05 UTC