W3C home > Mailing lists > Public > public-svg-wg@w3.org > January to March 2012

CSS3 Basic UI review

From: Chris Lilley <chris@w3.org>
Date: Thu, 23 Feb 2012 20:09:37 +0100
Message-ID: <1101684515.20120223200937@w3.org>
To: SVG WG <public-svg-wg@w3.org>
Hello ,

 Reviewing

CSS Basic User Interface Module Level 3 (CSS3 UI)
Editor's Draft 18 January 2012
http://dev.w3.org/csswg/css3-ui/

This module states specifically that it applies to SVG. Its mostly about form elements, but explicitly doesn't define what a form element is - so it could be graphical.

My review is specifically looking for things that affect SVG (1.1SE, 1.2T) or might be considered for inclusion in SVG2, or might be a problem for SVG2.

1) :active

SVG 1.1SE requires that a user agent that supports CSS style sheets support s dynamic pseudo-classes :hover, :active and :focus and pseudo-classes :first-child, :visited, :link and :lang.

CSS2 Basic UI defines additional requirements on :active. It requires that active is only triggered with the primary mouse button, if the mouse has more than one button. Unless there are SVG implementations that trigger :active with right-click (and want to continue doing so) that doesn't seem to be a problem.

2) New user interface state pseudo-classes

The descriptions seem generic enough that they could apply to graphical form elements.

3) User interface element fragments: pseudo-elements

These seem designed to work around limitations of xforms and not to apply here. ::repeat-item and ::repeat-index might apply if we were to adopt the replicate proposal.

They are all marked as at-risk.

4) Element icons

This is a new 'icon' property plus an addition to the 'content' property, which SVG 1.1SE does not require to be supported. SVG2 might want to support it. Usually content is used to ad text before or after an element (which does not really work, for SVG). Here though the icon replaces the element.

It is at risk.

5) Box Model additions

(no impact on SVG).

6) Outline properties

We might want to look at supporting these. CSS3 Basic UI says that outlines 'don't take up space' (by which it means that their presence or absence does not cause reflow; obviously they must take some space if they are visible).

It also states that outlines can be non-rectangular, but gives no indication when this might be so or how to control the shape.

7) Resizing & Overflow

This controls whether a user can resize an object and if so whether they can resize vertically, horizontally or both.

This might have been applicable to svg, but the property says that it  only applies to "elements with ‘overflow’ other than visible". It might be useful for mixed html and svg however.

8) Overflow Ellipsis

This adds a ‘text-overflow’ property, to indicate that not all the text is displayed, by putting ... towards the end of the diplayed part.

This might have been useful in SVG, for example for text on a path that does not fit. However the definition is specific to the box model - "when inline content overflows its block container element " and so on.

If we care about this we could ask for additional spec text to cover the SVG, non-box model case.

9) ‘cursor’ property

SVG 1.1SE has a cursor property.
http://www.w3.org/TR/SVG/interact.html#CursorProperty

with these values

        [ [<funciri> ,]* [ auto | crosshair | default | pointer | move | e-resize | ne-resize | nw-resize | n-resize | se-resize | sw-resize | s-resize | w-resize| text | wait | help ] ] | inherit



CSS3 Basic UI has this value list

[ [<uri> [<x> <y>]?,]*
[ auto | default | none |
context-menu | help | pointer | progress | wait |
cell | crosshair | text | vertical-text |
alias | copy | move | no-drop | not-allowed |
e-resize | n-resize | ne-resize | nw-resize | s-resize | se-resize | sw-resize | w-resize | ew-resize | ns-resize | nesw-resize | nwse-resize | col-resize | row-resize | all-scroll | zoom-in | zoom-out
] ] | inherit 

This is a superset of the values in SVG 1.1SE, except that funcIRI (here using uri, but I think it is still using the url() notation so equivalent)  adds optional x and y parameters for the hotspot.

In SVG 1.1SE these parameters were provided by linking to a cursor element, which had @x, @y and a link to an image (which might be an svg image).

The approach in CSS3 Basic UI is more applicable to HTML/CSS content and could serve our purposes as well so I suggest that SVG2 adopts it.

The x and y are coordinates, and are numbers, not lengths (thankfully) so would apply to SVG without change.

This section has a reference to SVG 1.0 for some odd reason rather than SVG 1.1.

10) Sequential navigation order: the ‘nav-index’ property

This is a replacement for the html4 and xhtml1 @tabindex and controls focus order.

It seems similar to the SVGT 1.2 @nav-next (but there is no equivalent to @nav-prev) - it is a one way ring.

The values are auto | <number> | inherit  while SVGT 1.2 used "<FuncIRI>" | "auto" | "self" so the way it is used is different. SVGT points from one element to another while CSS3 Basic UI numbers elements.

I didn't see anything that would conflict with SVG, if we adopted it. nav-index is marked as being at risk.


11) Directional focus navigation: the ‘nav-up’, ‘nav-right’, ‘nav-down’, ‘nav-left’ properties

SVGT1.2 had an eight-way navigation feature, using attributes.

This seems to be a property-based equivalent, but is only four way. The values are auto | <id> [ current | root | <target-name> ]? | inherit so unlike SVGT1.2 it is an IDREF not a URI. Howevert the ID is disambiguated by prefixing with # so effectively it is a fragment identifier.

target-name is for navigation between frames.

If we wanted to migrate to this, and if we cared about eight-way navigation, we should raise an issue about it only being four way.

nav-* are marked as being at risk.

12) Input method editor: the ‘ime-mode’ property

I had expected this to have a way to switch to numeric input, but it dosn't. It does however let the author disable the IME! and gives a rather feeble warning not to do so:

"Authors should not rely on disabling IME to prevent extended characters from passing through a form"

whatever 'extended characters' are (i suspect non-ASCII is nmeant).

I guess I18n WG will have something to say about that.

13) References

Both SVG 1.0 and SVG 1.1SE are referenced, which seems odd. They are in the informative section, which is fine because searching through, SVG is used only in the scope section and a couple of examples.

There are some other outdated references, including [RFC1738]  and [RFC1808] which are obsolete. Its not clear why they are there, because RFC 3986 is also there.


-- 
 Chris Lilley   Technical Director, Interaction Domain                 
 W3C Graphics Activity Lead, Fonts Activity Lead
 Co-Chair, W3C Hypertext CG
 Member, CSS, WebFonts, SVG Working Groups
Received on Thursday, 23 February 2012 19:09:37 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:20:14 UTC