- From: Matthew Brealey <thelawnet@yahoo.com>
- Date: Mon, 28 Feb 2000 04:11:19 -0800 (PST)
- To: www-style@w3.org
--- Tantek Çelik <tantek@cs.stanford.edu> wrote:
> > 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?
>
> (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 this case that was far from clear (mainly because there was no 'New
values' statement); if anything the implication was that the values
replaced the old ones, since equivalent values exist with different names.
> > 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".
No.
Here's the CSS2 definition (as explicitly restated by the WD):
<blockquote>
The :active pseudo-class applies while an element is being activated by
the user. For example, between the times the user presses the mouse button
and releases it.
The :focus pseudo-class applies while an element has the focus (accepts
keyboard events or other forms of text input).
</blockquote>
Now if I select a menu, I can move the focus between the menu items (e.g.,
using arrow keys). I could conceivably give dozens of such menu items the
focus before deciding to activate one. It would be completely wrong to say
that they were all being activated; rather they would all have the focus,
and would typically be distinguished as such by the OS (e.g., by different
backgrounds and/or foreground colour).
> > Content
> > -----
> > 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).
Well it might be if it wasn't for the fact that CSS3 UI WD explicitly
states that they are valid, which would necessitate an addition to the
'new values' section.
<blockquote cite="http://www.w3.org/TR/css3-userint#content">
These additional values for 'content' symbolically specify list
annotations and menu annotations that were previously only available
respectively through list-style-type and hardcoded for OPTION elements
that were SELECTED. In addition, symbolic names for the various states of
a radio button and checkbox are introduced. The rendering of disc, circle,
and square is identical to what is described for list-style-type.
</blockquote>
It wouldn't say 'the rendering of disc ...' if these weren't valid on
content - since they were not valid before, it is necessary to either add
them to the new values section or remove that sentence.
> There has been some discussion around adding a :viewport pseudo-element
I find this suggestion bizarre, since as a matter of principle
pseudo-elements may be included on any simple selector, but this would
seem to require either ignoring of 99% of possible syntactically valid
selectors that use :viewport (e.g., P:viewport is meaningless, as are all
cases where the selector is not exactly equal to :viewport) or senseless
modifications of the grammar of CSS.
I would like to see how you would defend :viewport over @viewport.
> > 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
No, what that is saying is that the scrolling mechanism should be visible.
It is not saying what it should look like (it implies that the UA can use
whatever it likes - panner, scrollbar, etc.).
> > It seems odd to create a whole at-rule that will probably only ever
> > support one property. Why not @viewport,
> Good concept, but more appropriate as a pseudo-element - see above
> :viewport.
See above.
> 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.
It seems to me odd to create a whole extra concept for UAs to implement
simply on semantic grounds. It is the concept that counts, not the name it
is given.
> > 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".
That doesn't fully encapsulate current UA behaviour; my point here was
that <button></button> results in:
+--+
| |
+--+
which implies that BUTTON has width set by the UA. However, adding content
to the button increases its width, which proves that it cannot be a UA
width property that is setting the width of the BUTTON. That leaves
min-width. However, the idea that the UA has a min-width under current
specifications would mean that BUTTON {width: a value less than the
UA-specific min-width} would result in the min-width applying because it
is greater than width.
This isn't current UA practice - they will allow you to set width smaller
than the default width.
Now if we wish to go down the 'We must be able to describe the rendering
of HTML elements using CSS' road, it is necessary to be able to describe
this behaviour; just as it is necessary to use box-sizing, so too it is
necessary to describe this behaviour - 'width: auto means as much width as
the content requires' is not enough.
My proposal is that when box-sizing: border-box, min-width should only
apply when width: auto.
You might have a different suggestion, but some means of describing this
is as necessary as box-sizing, and I would suggest that my proposal causes
the fewest problems while still accurately describing current rendering
practice.
> > 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.
Why have display: inline-block then? - it makes a mockery of it to say
that display: inline-block describes the rendering of IMG/OBJECT, etc.,
but then to say 'if you have display: inline then it will behave like an
inline block your contrary declaration not withstanding'.
Certainly, as you say, you should initially 'treat them' as inline blocks,
but it is odd to still treat them as such even when a contrary declaration
has been made.
A way that you could avoid this and achieve the result that both you and I
prefer (although at present it cannot be justified, hence my statement
above concerning how intrinsic elements could be treated as inline) is
with the following:
Relationship between width, height and display: inline
-----------------------------
1. If either width or height != auto, display: inline is set to display:
inline-block.
2. Similarly if width and height are intrinsic (equivalent to explictly
setting width and height), display: inline is also set to display:
inline-block.
That is the only way your suggestion (and my preference) can logically be
justified. It also has the following advantages:
1. It does not require display: inline-block to be set on the intrinsic
elements.
2. It is fully backwards compatible in that intrinsic elements that
currently have display: inline will behave in the same way because the
width and height (implied) declarations override display: inline for you.
3. It is backwards compatible with the Internet Explorer extension to
allow width and height on inline elements.
4. It is easier for XML in that there is no need to set display:
inline-block on intrinsic elements.
> > 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 }
My proposal is easier to implement in that it doesn't require two (or
possible three) (:horizontal-scrollbar and :vertical-scrollbar (and
optionally :scrollbar)) pseudo-elements. It is also quicker to use.
However, the pseudo-element approach has greater flexibility (although I
think to describe scrollbars fully, there also needs to be :scroller
pseudo).
>
> > 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.
I see what you mean, but what you say is still wrong.
select,select[size=1]
{
/* SELECT with no size attribute, or size=1 - popup-menu */
color: PopupMenuText;
background: PopupMenu;
border: PopupMenuBorder;
font: PopupMenu;
display: inline-block;
height: 1em;
overflow: clip;
user-input: enabled;
user-focus: select-menu;
user-select: element;
user-modify: read-only;
}
select:menu,select[size=1]:menu {display: block}
Just as the SELECT will inherit the border, font, etc., so too it will
inherit the overflow: clip and height: 1em declaration.
<blockquote>
2.2.2 The :menu pseudo-element.
Authors can specify the style and location of a generated menu with the
:menu pseudo-element. It is treated as a child of the element (and
therefore inherits all styling by default - similar to :before and
:after), and absolutely positioned at 0,0 with respect to the content top
left corner of the element. It is made "visibility:visible" when the
element itself is :active, and is "visibility:hidden" otherwise. It
contains a copy of all the contents of the element itself.
</blockquote>
This doesn't seem to fully specify some issues.
For a start, I find the idea of the :menu being absolutely positioned
rather fatuous. This seems to cause problems in that the menu is on top of
the default SELECT, and therefore there are problems with transparency,
issues of whether z-index applies, containing block issues, the meaning of
positioning, etc.
I think :menu as a pseudo-class is preferable.
> > However, the cursor
> > declaration is entirely redundant. UA style sheets should not, under
> any
> > circumstances, have any cursor declarations.
>
> Possibly.
Definitely.
> But what we have here is a *sample style sheet* that is
> *informative*, not normative, so I think it is fine.
*Sigh*.
Surely it is better to follow best practice?
It is quite likely that the sample style sheet will be incorporated
directly (probably with adaptations) into a user agent product, and by
using this example, you perpetuate the currently abysmal support for
cursor: auto by implying that current UA practice, namely:
HTML /* BODY should never be used in UA style sheets */ {cursor: text}
A[href] {cursor: pointer}
INPUT[type] {cursor: default}
INPUT, INPUT[type=text], TEXTAREA {cursor: text}
is in some way acceptable (this is the practice in all browsers).
> > 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.
Using :before or :after for the label instead is logically preferable in
that the content of the radio/checkbox is the radio button or checkbox,
not the label.
> > 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?
No, three.
select,select[size=1]
{
...
overflow: clip;
...
}
If the element does not have scrollbars (either through overflow: clip or
default behavior of the user agent),
>
> > 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.
No it doesn't.
In
<OPTGROUP label="PortMaster 3">
<OPTION label="3.7.1" value="pm3_3.7.1">PortMaster 3 with ComOS
3.7.1</OPTION>
<OPTION label="3.7" value="pm3_3.7">PortMaster 3 with ComOS
3.7</OPTION>
<OPTION label="3.5" value="pm3_3.5">PortMaster 3 with ComOS
3.5</OPTION>
</OPTGROUP>
, the content of OPTGROUP is
<OPTION label="3.7.1" value="pm3_3.7.1">PortMaster 3 with ComOS
3.7.1</OPTION>
<OPTION label="3.7" value="pm3_3.7">PortMaster 3 with ComOS
3.7</OPTION>
<OPTION label="3.5" value="pm3_3.5">PortMaster 3 with ComOS
3.5</OPTION>
, which certainly isn't replaced.
> > 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.
In no way can this be construed as saying that UI values must be the sole
value for a property.
=====
----------------------------------------------------------
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 Monday, 28 February 2000 07:11:20 UTC