- From: Tantek Çelik <tantek@cs.stanford.edu>
- Date: Mon, 28 Feb 2000 00:54:58 -0800
- To: "www-style@w3.org" <www-style@w3.org>
> From Matthew Brealey
> Date: Sun, Feb 27, 2000, 3:35 PM
>
> UI colours
> ----------
> Of the CSS2 system colours, only 5 survive (buttontext, menu, menutext,
> window and windowtext) - should or may UAs continue to support the rest of
> them?
Yes, we should add some language describing what to do with the others. This
will be a part of the CSS3 UI Module draft (so far, the CSS3 UI draft has only
contained *additions* to what was in CSS-2, the Module draft will be
comprehensive, and not just a delta).
> In addition, the four states do not accurately describe the rendering
> behaviour of modern OSs. Five states are in fact needed: enabled,
> disabled, focus, active and hover.
The focus state does not result in a different rendering of the control - it
typically results in the rendering of a focus outline surrounding the focussed
control.
> Without focus, the proposal does not
> even describe the CSS2 'highlight' colour - menu items for instance can
> have the focus (and be distinguished as such by the OS) without being
> hovered over or activated.
That state is already precisely described by CSS-2 :active which is different
than common notions of "activate" or "activated".
> Content
> -----
> There is an omission here:
> content
> New Values:
> normal | <uri> |
> check | diamond | menu-check | menu-diamond |
> radio | radio-on | radio-off | radio-ind |
> enabled-radio-on | enabled-radio-off | enabled-radio-ind |
> disabled-radio-on | disabled-radio-off | disabled-radio-ind |
> active-radio-off | active-radio-on | active-radio-ind |
> hover-radio-off | hover-radio-on | hover-radio-ind |
> checkbox | checkbox-on | checkbox-off | checkbox-ind |
> enabled-checkbox-on | enabled-checkbox-off | enabled-checkbox-ind |
> disabled-checkbox-on | disabled-checkbox-off | disabled-checkbox-ind |
> active-checkbox-on | active-checkbox-off | active-checkbox-ind |
> hover-checkbox-on | hover-checkbox-off | hover-checkbox-ind
>
> Missing are disc, square and circle.
These are currently handled by CSS-2 counters:
http://www.w3.org/TR/REC-CSS2/generate.html#counter-styles
If you think disc, square and circle should be added as explicit values to the
content property, that would be an excellent suggestion for the CSS3 Generated
Content Module (rather than CSS3 UI).
> What effect, if any, does color/background have on the diamond, radio and
> checkbox content types?
They are glyphs, just like any other font based glyph, and as such are
affected by color. Background shows through where the glyph doesn't draw.
> System fonts
> -----------
>
> I suggest that the states be allowed; for example, Windows allows you to
> distinguish between enabledwindow and disabledwindow.
We explicitly chose not to model the platform window layering model in CSS3
UI. See issue 5:
http://www.w3.org/TR/css3-userint#issues
> In addition, there is an inconsistency between the system fonts and
> colours - for the fonts only new values are listed, and as such both
> message-box and dialog are allowed,
In the CSS3 UI Module draft, all values for each will be listed.
> whereas for system colours the new
> values replace the old, and equivalent values are not allowed.
I believe from the comment made earlier that the issue of older/equivalent
values was unclear at best, which should be clarified in the next draft.
> Minor solecisms and typos:
>
> 'resizer'
> Currently it is possible to control the appearance of the scrolling
> mechanism (if any) on a window using the overflow property (overflow:
> hidden) on the HTML (root) element.
>
> No it isn't. The overflow property applies to the content area of
> elements, HTML can have margins, borders or padding. Therefore the
> scrolling behaviour is ua-specific and cannot currently be described by
> CSS.
Yes, that is correct. The scrolling behavior _of the window_ is ua-specific
and cannot currently be described by CSS (which is too bad, because that means
that it can currently only be controlled via javascript, e.g. window.open, and
cannot be overridden by a user style sheet for example).
There has been some discussion around adding a :viewport pseudo-element which
represents the notion of the "viewport" as referenced/documented in CSS. In
typical UAs, the viewport is the "window".
Then you would be able to say:
:viewport { overflow:hidden }
in order to hide the scrollbars from the window.
or in a user style sheet:
:viewport { overflow: auto ! important }
would guarantee that scrollbars showed up in a window when the content was
large enough to need them, regardless of what the author specified.
> In addition, the sentence is wrong (overflow does not describe the
> appearance of the scrolling mechanism; rather the presence or otherwise of
> it)
Actual, it does.
http://www.w3.org/TR/REC-CSS2/visufx.html#overflow
e.g. ( _underline_ emphasis mine)
scroll
This value indicates that the content is clipped and that if the user agent
uses scrolling mechanism that is visible on the screen (such as a scroll bar
or a panner), that mechanism _should be displayed_ for a box whether or not
any of its content is clipped.
and
hidden
This value indicates that the content is clipped and that _no scrolling
mechanism should be provided_ to view the content outside the clipping region
> @preference
> ...
> The @preference rule allows the content author to indicate which medium is
> preferred for rendering the content. It does this with the "media"
> property.
> ...
> The only property currently defined for the @preference rule is "media",
> which gives an ordered list of the media that the content was intended
> for.
>
> It seems odd to create a whole at-rule that will probably only ever
> support one property. Why not @viewport, which would also allow other
> properties such as resizer, overflow, etc., which don't currently (see
> above) have the desired effect. Other properties, such as background could
> be allowed, but it seems unnecessary - @viewport should be reserved for
> things that cannot be described at any other level.
Good concept, but more appropriate as a pseudo-element - see above :viewport.
As far as @preference, yes, we would like a better mechanism that didn't
involve a new "@" rule just for this single use. However, we need something
to capture the semantic of "suggestion" to the UA, instead of requirement, so
that the UA can accept/reject the suggestion in terms of what is appopriate
for the user.
> Box-sizing
> ------------
>
> border-box
> The specified width and height on this element determine the border box of
> the element. That is, any padding or border specified on the element is
> laid out and drawn inside this specified width and height. The content
> width and height is computed by subtracting the border and padding widths
> of the respective sides from the specified width and height. This is the
> behavior of width and height as commonly implemented by legacy HTML user
> agents for replaced elements and input elements.
>
> If one wishes to be able to describe the current sizing behaviour of form
> elements, one must also provide a way to describe the way that widths are
> calculated. At present, <button></button> or <input type="button">
> typically results in (in CSS 3 parlance) <span style="display:
> inline-block; border: 2px inset buttonborder; background: button; color:
> buttontext; width: 15px; box-sizing: border-box; padding: 2px; text-align:
> center"></span>. However, <button>Some text</button> results in <span
> style="display: inline-block; border: 2px inset buttonborder; background:
> button; color: buttontext; width: as much as is needed
There is a proposal underway to describe this "as much as is needed" width
behavior with "width:auto".
> Width of replaced inline block elements
> ---------------------
> A specified value of 'auto' for 'left', 'right', 'margin-left' or
> 'margin-right' becomes a computed value of '0'. A specified value of
> 'auto' for 'width' gives the intrinsic width as the width of the content.
>
> Width of non-replaced inline block elements
> ---------------------
> A specified value of 'auto' for 'left', 'right', 'margin-left' or
> 'margin-right' becomes a computed value of '0'. A specified value of
> 'auto' for 'width' gives the width of the content as the width of the
> element. For the purposes of min-width, this is treated as a width of 0,
> so if min-width is set to a value other than 0, this will override it.
Exactly. It seems like a few people are converging on similar solutions.
> Elements with intrinsic dimensions as inline elements
> --------------------------------------
> Although it is easy to see how text elements can behave as inline blocks,
> it is less easy to see how elements with intrinsic dimensions, such as
> images, can behave as inline elements. The answer is that, as with all
> inline elements, the height of the element is provided by line-height and
> the width by the content width, the width property having no effect (it is
> invalid on inline elements). Note that this means that content might
> overflow its element; for example if an image is taller than line-height.
>
> [Is this right?]
Not quite. It makes much more sense to treat elements with intrinsic
dimensions (e.g. replaced elements like images) as inline-block elements.
> tab-index
>
> Tab index presents very serious accessibility problems.
all we need is the right initial value, and those problems (introduced by
HTML4) are solved (by CSS).
> For example, one of the things about Opera that makes it a very accessible
> browser is that tabbing tabs to the next visible anchor, so if the
> viewport looks like this:
>
> ---------------
> | Text ANCHOR
> | Text ANCHOR
> | Text ANCHOR
>
> tabbing would tab to the first visible anchor, then to the next one after
> that, etc.
sounds like a good idea.
> However, under the tabbing rules (assuming tab-index: auto) the tabbing
> should go from the first element in the document to the next one, so
> pressing tab in this example should tab to an anchor possibly several
> hundred screenfulls up the document, which is completely absurd. This is a
> serious concern for people who can't use pointing devices or who find it
> more efficient not to (such as myself) since they are required, every time
> they wish to select a link, to tab through potentially hundreds of links
> in which they have no interest.
>
> There has to be a way to stop this. I propose tab-index-override. Since
> this clearly only makes sense on the whole document, I propose that it be
> added to the @viewport rule I suggested. Thus either author or user could
> specify @viewport {tab-index-override: override} to specify accessible
> tabbing; I, for example, would have @viewport {tab-index-override:
> override !important}. (The other value is no). HTML implies that 'no'
> should be the initial value, but I am perhaps minded to say that, because
> the tabbing rules are so incredibly stupid that it should be override.
Alternatively, we allow UAs to "turn off" tabindex handling, and handle
tabbing in their own custom way. This was, no extra property is needed.
> key-equivalent
> --------------
<issues about tokenization>
There have been other issues raised about the current set of values allowed by
key-equivalent.
The primary purpose of key-equivalent, is to provide a cascadable,
user-overridable, rule driven, replacement for HTML4 ACCESSKEY.
For these reasons, we may need to reduce the set of values allowed.
> Scrollbar
> -------
> This is a proposed property that complements resizer; it is the same
> except it specifies whether scrollbars will appear, so, for example,
> overflow: scroll; scrollbar: none specifies scrolling behaviour without
> scroll bars appearing. It takes the additional value of menu, which
> specifies the pulldown menu selector.
>
> Thus current overflow and scrolling behaviour is described by:
> input[type=text], input {overflow: scroll;
> scrollbar: none}
The better way to describe this would be with pseudo-elements for the
scrollbars, upon which you could set property values, e.g.:
:scrollbar { display:none }
> The sample style sheet is also wrong:
>
> select:menu,select[size=1]:menu
> {
> display: block;
> }
>
> This is is incorrect (display: block would cause a line break before and
> after the select when it acts as a menu).
No, :menu is a pseudo-element, not a pseudo-class. The SELECT itself still
renders as inline-block as described by previous style rules.
> /* dynamic interface */
> cursor: arrow;
>
> Not a valid cursor type.
Good catch. Should be 'default'.
> In addition, 'default', which is what is meant,
> is not the 'correct' cursor for text input elements.
See overriding rule that follows with "cursor: text;"
> However, the cursor
> declaration is entirely redundant. UA style sheets should not, under any
> circumstances, have any cursor declarations.
Possibly. But what we have here is a *sample style sheet* that is
*informative*, not normative, so I think it is fine.
> input[type=checkbox]:before { content: checkbox }
>
> input[type=radio]:before { content: radio }
>
> Why :before? Why not plain input[type=radio] {content: radio}
So that we can use the content for the label if we want to.
> input[type=button], input[type=reset], input[type=submit]
> {/* content and formatting of text in HTML4 input buttons */
> content: attr(value)}
>
> Nope. attr(value) is fine for button, but for reset it is content: "Reset"
> - regardless of the case of value
Good catch, but the solution is a bit more complex. You actually need to
modify a couple of current rules and add one more:
input[type=button],
input[type=reset][value],
input[type=submit][value]
{
/* content and formatting of text in HTML4 input buttons */
content: attr(value);
}
input[type=reset]
{
/* default content of HTML4 input type=reset button */
content: "Reset";
}
input[type=submit]
{
/* appearance of a default button */
color: DefaultButtonText;
background: DefaultButton;
border: DefaultButtonBorder;
content: "Submit";
}
>
> ...,
> input,
> ...,
> {
> ...
> user-modify: read-only;
> }
> No. Input is the same as input[type=text], which has user-modify:
> read-write.
Yup, just missed a selector in the next rule with input[type=text]
> textarea, button
> {
> /* appearance of BUTTON and TEXTAREA tags in particular */
> white-space:normal;
> }
textarea tends to word-wrap text automatically which pre does not. hmmm... we
may need some of the new CSS3 Text and Font additions to be able to specify
the wrapping independently of the "pre" behavior.
> Example:
> html {
> width: 100px;
> height: 100px;
> overflow: clip;
> }
>
>
> Not a valid value for overflow. This error is repeated several times in
> the document.
Yes, these will have to be corrected. How many other times was this repeated?
Just the two places right?
> optgroup[label]...
> {
> content: attr(label);
> }
>
> No. That would replace the content of the OPTGROUP with the label; not the
> correct behaviour at all. Correct is :before {content: attr(label);
> display: block}
See HTML4. The LABEL of an OPTGROUP *does* replace its contents.
> *[accesskey]:enabled
> {
> key-equivalent:accesskey-attr(accesskey);
> }
>
> *[noresize] { resizer:none }
>
> *[tabindex] { tab-index:attr(tabindex) }
>
> These three universal selectors might mislead people, since they might
> lead people to assume that the universal selector is required here.
It is being recommended to style sheet authors to make the universal selector
explicit rather than implicit. This may be required in a future version of
the selectors module.
> 'user-focus-key'
> ...
> The purpose of this property is to determine what happens to an element
> when the user focusses it specifically by clicking on it with a pointing
> device.
>
> 'user-focus-pointer'
> ...
> The purpose of this property is to determine what happens to an element
> when the user focusses it specifically by "tabbing" into it.
>
>
> These are the wrong way round - correct is:
>
> 'user-focus-key'
> ...
> The purpose of this property is to determine what happens to an element
> when the user focusses it specifically by "tabbing" into it.
>
> 'user-focus-pointer'
> ...
> The purpose of this property is to determine what happens to an element
> when the user focusses it specifically by clicking on it with a pointing
> device.
;*) Yes, another good catch.
> Groups in elements with 'display: none'
> An element that is not displayed ('display' set to 'none') cannot reset a
> group.
> For example, with the following style sheet, H2s with class "secret" do
> not reset 'group2'.
> h2.secret {group-reset: count2; display: none}
> Elements with 'visibility' set to 'hidden', on the other hand, do reset
> groups.
>
> To this I would add: for aural UAs, elements that are not spoken do not
> reset groups either.
>
> This is also an omission from CSS2 generated content.
It sounds reasonable enough to me, but I will defer that to the decision on
this for CSS3 Generated Content.
> UI borders
> -----
> These don't seem to be quite right. Clearly if specifying a UI value it
> must be the only value specified for the property, because otherwise
> border: solid windowborder is ambiguous (the UI style might not be solid).
> A statement to this effect is notably omitted from the WD. (Similarly for
> UI backgrounds).
Statement is there:
http://www.w3.org/TR/css3-userint#color
In addition, when the appropriate values are specified on the 'background' or
'border' shortcut properties, they behave similar to the System Font values,
in that, the value indicates not only the color of the shortcut property but
all other aspects (width, style, etc.) that are determined by the look of
standard user interface elements on the system. When the values are set on
the shortcut 'background' or 'border' property, the individual properties such
as 'background-color' or 'border-style' are still given values taken from the
system, which can be independently varied. Authors are encouraged to use the
shortcut properties 'background' and 'border' rather than the properties
'background-color' and 'border-color' in order to allow the UA the flexibility
to render as close to the standard look and feel of the platform.
> Furthermore, a statement to the following effect is
> needed: 'Although CSS2 states that by using 'border' shorthand one
> constrains oneself to setting all four sides to the same value, this does
> not apply to UI borders insofar as the UI might have different values on
> different sides.'
Similar to 'outline' as specified in CSS2, system borders do not have
different values on different sides. UAs may draw the different sides
differently, but the system border still has only one value to cover all four
sides.
Thanks for all the feedback and suggestions. I've already made a bunch of the
changes, and am working on the rest of the edits.
Tantek
Received on Monday, 28 February 2000 03:55:26 UTC