- From: Matthew Brealey <thelawnet@yahoo.com>
- Date: Sun, 27 Feb 2000 15:35:51 -0800 (PST)
- To: www-style@w3.org
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?
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. 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.
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.
What effect, if any, does color/background have on the diamond, radio and
checkbox content types?
For example, <span style="content: radio-on; background: red; color:
yellow; border: blue solid"></span>. Does this
(a) result in a standard radio button whose colour, background and borders
are UA-determined
(b) result in a yellow disc inside a radio button with a blue border and a
red background
(c) result in a standard UA-determined radio button with the rectangle in
which the radio button is circumscribed coloured by the specified
background colour; i.e., does the radio button create a circular
placeholder or a rectangular one (which would necessarily have a
transparent outer around the radio button)
I propose that radio buttons, checkboxes and diamonds be treated like
images so that all formatting is as for images; i.e., colour is
ineffective and border goes around the rectangular box. As to the
transparency of this, the bit inside the border (the whole of the element
on checkbox) must not be transparent, but the bit outside the border (only
relevant on radio) should be.
System fonts
-----------
I suggest that the states be allowed; for example, Windows allows you to
distinguish between enabledwindow and disabledwindow.
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, whereas for system colours the new
values replace the old, and equivalent values are not allowed.
Minor solecisms and typos:
Should we add additional pseudo-classes to be able to style an element
based upon it's modifiability? E.g. :read-only, :read-write, :write-only.
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
'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.
In addition, the sentence is wrong (overflow does not describe the
appearance of the scrolling mechanism; rather the presence or otherwise of
it) and the bracketed overflow: hidden is completely unintelligible.
@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.
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; box-sizing:
border-box; padding: 2px; text-align: center">Some text</span>.
We need to take into account the fact that <button></button> results in a
15 pixel wide block, and <button>A long bit of text</button> results in a
longer block, but <button style="width: 15px">A long bit of text</button>
results in a 15 pixel wide block. This behaviour cannot be described by
BUTTON {width: 15px} in the UA style sheet, because the behaviour when
width: 15px is different. Neither can it be described by min-width: 15px,
because that would mean that when width: 10px is specified the width would
be 15 pixels, which isn't the current rendering behaviour.
So to describe current behaviour is impossible under the current proposal.
To describe it, the following (or similar) is needed:
border-box
...
When box-sizing: border-box, min-width is only honoured when width: auto;
for example, the current typical rendering of BUTTON is described by
BUTTON {min-width: 15px; box-sizing: border-box}. If an author specifies
an explicit width, the min-width would be disregarded.
Now while this takes care of the width problem, it doesn't take into
account the problem of the width: auto behaviour - currently when width:
auto the content expands to fit. As a result, I propose the following:
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.
Inline blocks
------------
If a non-replaced inline block has width: auto (and min-width: auto), the
element will be formatted as a single line. If it has an explicit width,
the element will behave like an ordinary block element in that content
will wrap at the edge of the element.
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?]
tab-index
Tab index presents very serious accessibility problems.
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.
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.
key-equivalent
--------------
<q>
A <key-press-combination> is one or more characters with one or more
modifier keys separated by dashes ('-').
</q>
This won't work. The tokenization of CSS is such that this is unworkable.
Take this example from the appendix:
[accesskey]:enabled
{
key-equivalent:accesskey-attr(accesskey);
}
That would be parsed as an IDENT, a '(', a IDENT and a ')'.
What is desired is for it to be parsed as IDENT DELIM FUNCTION IDENT ')',
but because the longest match determines the token, this wouldn't happen.
There is no way around this because the standard declaration production
(necessarily) includes IDENT.
It would be better to use the underscore.
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}
input[type] {overflow: hidden}
textarea {overflow: scroll;
scrollbar: vertical}
select {overflow: scroll;
scrollbar: menu}
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). Correct is select:menu,
select[size=1]:menu {overflow: visible}. Note that this doesn't cause any
problems with document reflow because SELECT always has an explicitly set
height (equal to the value of the size attribute lines).
The only difference between the two (list menu vs. dropdown) is in terms
of height and overflow.
/* dynamic interface */
cursor: arrow;
Not a valid cursor type. In addition, 'default', which is what is meant,
is not the 'correct' cursor for text input elements. However, the cursor
declaration is entirely redundant. UA style sheets should not, under any
circumstances, have any cursor declarations. HTML {cursor: auto}, is the
only declaration that is needed, but this is redundant in a UA style sheet
since auto is the initial value. Let me repeat _cursor declarations have
no place in UA style sheets_, because BUTTON might have a link cursor in
one UA and the platform default in another.
input[type=checkbox]:before { content: checkbox }
input[type=radio]:before { content: radio }
Why :before? Why not plain input[type=radio] {content: radio}
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
...,
input,
...,
{
...
user-modify: read-only;
}
No. Input is the same as input[type=text], which has user-modify:
read-write.
Correct for user-modify is:
input {user-modify: read-write}
input[type] {user-modify: read-only}
input[type=text] {user-modify: read-write}
textarea, button
{
/* appearance of BUTTON and TEXTAREA tags in particular */
white-space:normal;
}
Standard practice is white-space: pre for textarea. I haven't tested any
other browsers, but WinIE does white-space: nowrap for button.
Example:
html {
width: 100px;
height: 100px;
overflow: clip;
}
Not a valid value for overflow. This error is repeated several times in
the document.
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}
select,select[size=1]
{
height: 1em;
No. The height is dependent on line-height - font: PopupMenu is (unless
the UA sets line height on its font settings) equivalent to setting
line-height: normal, which is almost unvariably more than 1em.
Height: 1lines ('lines' is the most user-friendly name for this unit)
would be correct. However, no such unit currently exists; I am proposing
that it should. If it does not, the UA must
do font: PullDownMenu; line-height: anynumber; height: anynumberEM.
The style sheet also omits to consider [readonly], width and padding.
[accesskey]:enabled
{
key-equivalent:accesskey-attr(accesskey);
}
*[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.
'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.
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.
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). 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.'
Furthermore, a statement that the values are taken from the respective
sides is needed; for example, if a OS has different colours on top and
left and bottom and right sides, then border-left: buttonborder should
result in the values for the left side.
Anyway here's an improved sample style sheet, which precisely (to the
pixel (except OPTGROUP, whose styling is of my own devising)) expresses
the Win IE 4 form rendering (incidentally it uses some of the extensions I
have proposed plus :subject to describe the rendering of OPTGROUP):
/* Formatting of elements */
/* Elements formatted as buttons */
BUTTON, INPUT[type=image], INPUT[type=submit], INPUT[type=reset],
INPUT[type=button]
{display: inline-block;
min-width: 1.1em;
text-align: center;
box-sizing: border-box;
padding: 2px;
border: buttonborder;
font: button;
overflow: hidden;
white-space: nowrap;
color: buttontext}
INPUT[type=image] {border: none;
padding: 0}
INPUT[type=submit] {color: defaultbuttontext;
background: defaultbutton;
border: defaultbuttonborder}
INPUT[type=button] {content: attr(value)}
INPUT[type=reset] {content: "Reset"}
INPUT[type=submit] {content: "Submit"}
/* Elements formatted as text entry fields */
INPUT, TEXTAREA {display: inline-block;
color: fieldtext;
border: fieldborder;
box-sizing: border-box;
padding: 0;
overflow: scroll;
background: field;
font: field}
INPUT {content: attr(value);
white-space: nowrap;
min-width: 11.5em;
scrollbar: none}
TEXTAREA {min-width: 13.5em;
min-height: 2lines;
scrollbar: vertical}
/* Elements formatted as radio buttons and checkboxes */
INPUT[type=radio] {display: inline-block;
content: radio}
INPUT[type=checkbox] {display: inline-block;
content: checkbox}
/* Elements not rendered (will render as a text box if display is
overridden) */
INPUT[type=hidden] {display: none}
/* Menu items */
SELECT {overflow: scroll;
display: inline-block;
box-sizing: border-box}
SELECT[size] {color: listtext;
background: list;
height: attr(size)lines;
overflow: scroll;
border: listborder;
font: list}
SELECT, SELECT[size=1] {color: pulldownmenutext;
background: pulldownmenu;
min-width: 25px;
border: pulldownmenuborder;
height: 1lines;
font: pulldownmenu;
scrollbar: menu}
SELECT[size]:menu {overflow: scroll}
SELECT:menu, SELECT[size=1]:menu {overflow: visible}
SELECT[size]:subject OPTGROUP {height: attr(size)lines;
overflow: scroll}
SELECT:subject OPTGROUP, SELECT[size=1]:subject OPTGROUP {overflow:
visible;
height: auto}
OPTGROUP {overflow: scroll;
height: 1lines;
display: block;
scrollbar: menu}
OPTION {display: block;
overflow: hidden;
white-space: nowrap}
OPTGROUP[label]:before {display: block; /* This isn't a problem providing
:before is treated as 'inserted as first child' */
content: attr(label)}
OPTION[label] {content: attr(label)}
/* Other inline blocks */
IMG, OBJECT, APPLET, EMBED {display:inline-block}
/* Interactivity settings */
/* User-input */
INPUT, TEXTAREA, A[href], BUTTON, SELECT {user-input: enabled}
[disabled] {user-input: disabled}
/* User-modify */
INPUT[type] {user-modify: read-only}
INPUT, INPUT[type=text], TEXTAREA {user-modify: read-write}
INPUT[readonly], TEXTAREA[readonly] {user-modify: read-only}
/* User-select */
BUTTON, INPUT[type=image], INPUT[type=button], INPUT[type=reset],
INPUT[type=submit] {user-select: none}
INPUT[type=radio], INPUT[type=checkbox] {user-select: toggle}
SELECT[size] {user-select: elements}
SELECT, SELECT[size=1], OPTGROUP {user-select: element}
/* Toggle */
INPUT[type=checkbox][name], INPUT[type=radio][name] {toggle-group:
attr(name)}
/* Focus */
INPUT[type] {user-focus: normal}
INPUT, INPUT[type=text] {user-focus: select-all}
SELECT[size] {user-focus: select-same}
SELECT, SELECT[size=1] {user-focus: select-menu}
/* Other */
[noresize] {resizer: none}
[tabindex] {tab-index: attr(tabindex)}
[accesskey]:enabled {key-equivalent: accesskey_attr(accesskey)}
=====
----------------------------------------------------------
From Matthew Brealey (http://members.tripod.co.uk/lawnet (for law)or http://members.tripod.co.uk/lawnet/WEBFRAME.HTM (for CSS))
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com
Received on Sunday, 27 February 2000 18:35:52 UTC