The CSS Basic User Interface Module Level 3 (CSS3-UI, latest Editor's draft) defines user interface related selectors, properties and values.
CSS3-UI is deliberately scoped to what's been interoperably implemented, so it's a firm stake in the ground that implementers and authors can depend on.
CSS4-UI is for new features above and beyond CSS3-UI.
In somewhat order of priority:
Implementations may have found it useful to extend existing CSS3-UI features, but perhaps they are only experimental extensions or single implementations.
As these are most likely to be practical and minimal (and supported by a second implementation), these are the first features we'll consider.
Second, users and authors may have found that they wanted a CSS3-UI feature to work a certain way in their sites, and these real world needs are a second consideration.
Third, there are hypothetical requests for extensions to CSS3-UI features. As these are not real world proven (only theoretical) demands, they are purely tertiary. We may consider them optimistically and include them in working drafts to solicit feedback and additional interest.
Brand new features fo CSS4-UI. We'll follow the same prioritization as above.
Consider adding a new 'caret' property.
Name: caret Value: auto | <color> | invert Initial: auto Applies to: Any element that accepts textual input Inherited: Yes Percentages: N/A Media: Interactive Computed value: The computed value for 'invert' is 'invert'. For <color> values, the computed value is as defined for the [CSS3COLOR] 'color' property.
UAs set the color of the caret cursor to the value of the 'caret' property.
The 'invert' value is expected to perform a color inversion on the pixels on the screen under the caret cursor. UAs may ignore the 'invert' value on platforms that do not support color inversion of the pixels on the screen.
Note: The caret cursor (also known as the text insertion cursor) is distinct from the pointing cursor (typically called just “cursor” in CSS and controlled with the 'cursor' property). The caret cursor is usually displayed (often rendered as a blinking line segment perpendicular to the inline-progression direction) by the user agent in active text inputs without any selected text, where user entered text will be inserted.
Note: The 'caret' property could be extended to other aspects (e.g. caret width or style) and become a shorthand for a caret-color, if there is sufficient demand and use cases. Or alternately we could name it 'caret-color' to begin with.
Implementer feedback:
Consider incorporating a 'focusable' property (like in SVG)
http://www.w3.org/TR/SVGTiny12/interact.html#focusable-attr
Alternate syntax suggestion (because boolean properties are the devil):
nav-focus: _normal_ | ignore | focus
Moved from CSS3-UI editor's draft because it was the top source of issues for the 2nd CSS3-UI LCWD, and because it requires documenting previously undocumented web platform hit-testing model.
Incorporate spec text from:
Consider just specifying pointer-events:none, and reserving the other keywords as undefined in CSS (at this level of spec.
Consider use-cases, in particular for pointer-events:none;
Consider adding a 'paint-order' value, as per Tokyo 2013 discussion
Instead of an ellipsis character, apply a fixed width (e.g. 2em) linear gradient mask on the right-hand-end (modulo inline-progression direction) of the text conditional on the text overflowing.
Needs to work over non-solid color backgrounds.
Perhaps extend 'text-overflow' to take a value:
From this email thread:
Some mechanism to control ellipsing of text by allowing it to be ellipsed “in the middle” (somehow). See also other related text-overflow features dropped from CSS3.
See emails and GitHub issue:
The Pointer Events WD introduced a “touch-action” property.
Microsoft has shipped support for “touch-action” in prefixed form in IE10:
The CSSWG discussed “touch-action” in the 2013-01-16 telcon:
Issues from the telcon:
There's a subsequent discussion thread on the “public-pointer-events” list about “touch-action”:
Issues from the mailing list discussion:
Once the issues from the mailing list discussions are documented, and those plus the issues raised in the telcon are resolved, we should draft a definition of “touch-action” (or equivalent functionality) in CSS4-UI.
Features that were dropped from CSS3-UI (e.g. the 2004 CR) are eligible to be considered for CSS4-UI, but they will need a strong justification as having been ignored by implementations for 6+ years means there was likely something wrong with them and they need major revising. In addition, features dropped from other CSS3 specs or trimmed when bringing over to CSS3-UI are also considered here.
The System Appearance feature, including the appearance property, was in the 2004 CSS3-UI CR but never implemented as designed. It likely needs a complete rethink and redesign, perhaps even a reframing/reexploration of the problems it was designed to solve.
In practice, “appearance:none” is occasionally required in some UAs (like Gecko, WebKit) to turn off the native rendering of some controls and allow full CSS styling.
Some form of “appearance:none” may be worth exploring as a CSS4-UI feature.
At the time of the introduction and development of the 'appearance' property, it appeared that the limited set of specific UI elements in HTML were not going to be extended, and thus we tried going so (in a limited capacity) with CSS.
Since new input elements etc. have been added to HTML5, and there is clearly opportunity to add more as deemed practically necessary, it makes more sense now to pursue new specific UI elements in HTML5 first, and then design any new related CSS features subsequently.
I've archived the 2004 System Appearance feature spec source on the W3C wiki (it seems to support better escaping of embedded markup).
Suggestion that more values than just none and auto are useful: http://www.w3.org/mid/5127EB91.7000002@inkedblade.net
This has now been drafted here: http://dev.w3.org/csswg/css-ui-4/#appearance-switching
nav-index:
The string value for text-overflow should have the same syntax as the content rule.
Real-world use-cases:
Theoretical use-cases:
text-overflow: second <string> as an overflow visual hint after the element box. The visual hint after the element box only appears if there is content which is clipped because of the block-progression dimension of the block, not because the last line cannot fit. If the visual hint after the element box is enabled and would appear at the same location as the visual hint at the end of the element box, only the visual hint after the element box is rendered.
Originally text-overflow: second <string> was defined in CSS3 Text CR 2003-05-14 for after the element box in addition to the end of the text being overflowed - but no one implemented it. Thus any request for including this MUST include some justification as to why/how implementations would consider it differently than they did (and reject) for CSS3 Text CR 2003.
The current CSS3-UI text-overflow already uses two values for the start and end of the text, so another property (or another way of specifying the value) would be needed for this before/after the element box functionality.
In addition
Real world use-cases:
This should likely be done as a new property, e.g. 'block-overflow', as described by Tab Atkins here:
Also see:
Originally text-overflow permitted an optional second value defined in CSS3 Text CR 2003-05-14 “ <ellipsis>{1,2} ”
Status:
Real-world use-cases:
Theoretical use-cases:
Hypothetical reasoning:
Last seen in the 2000 era draft of User Interface for CSS3, the 'user-select' property controls the selection model and granularity of an element.
Implementation Status:
Spec Status:
The editor's draft is here:
For now, issues are primarily tracked inline, although this wiki contains relevant information that predates the creation of the draft.
The following issues were removed form css3-ui's issue list, as they pertain to features that were removed from that document. They are collected here, as these features may be reintroduced in css4-ui, and the issues would then still be relevant.