Re: [css3-ui] Last? Call

On Mon, 7 Jul 2003, Alexander Savenkov wrote:
>
> 3.2.2. ::choices and other
> ----------------
> What's a "pseudo"? The specification should not contain
> abbreviations like this. Change to pseudo-class/pseudo-elements.

Good catch. After reading this draft several hundred times,
editorial errors like this start to become unnoticeable.


> 4.1. The 'appearance' property
> ------------------------------
> Who's idea was this? What's the purpose of this? Why not just use
> 'display' property with the new values?

'display' controls the layout of the element, while 'appearance' controls
only its appearance.

You could, for example, have a row of buttons in a table-like arrangement:

   button { display: table-cell; appearance: button; }

...or you might want to keep them inline:

   textarea { display: inline-block; appearance: field; }

The two aspects are independent.

As to who thought of it, I do not remember when this was first mentioned,
but Mozilla has implemented a version of this for around a year now. (As
'-moz-appearance'; it is used to render the user interface in the
"classic" skin so that it matches the OS.)


> 4.2. System fonts
> -----------------
> Why just fonts? What if someone wants to style the padding of the
> images according to the padding of system radio button? What if the
> other one believes the margin of his paragraph should be equal to the
> system checkbox-group?

That's what 'appearance' is for; the extra fonts are useful primarily for
matching the font in other parts of a document with the fonts used by
controls.


> 5.1. Additional value(s) for 'display' property
> -----------------------------------------------
> I guess this ought to look like this:
> p { display: icon; icon: url(blah); }
> Tell me, how is this different from
> p { content: url(blah); }?

Functionally, the difference is limited, but in practice it is useful to
be able to control the icons used in one stylesheet and have the element
switch in and out of the icon representation on the fly.

Note that the 'content' property will have an 'icon' value as well, so
that it is possible to say:

   p { content: icon; }

The typical usage will be something like:

   #save { icon: url(save); }
   #open { icon: url(open); }
   #print { icon: url(print); }

   button { content: icon '\A' contents; }

While it would also be possible to say:

   #save { content: url(save) '\A' contents; }
   #open { content: url(open) '\A' contents; }
   #print { content: url(print) '\A' contents; }

...it is a lot harder to maintain.


The 'display:icon' value may be removed at a later stage depending on
implementation experience. The following rule:

   foo { display: icon; }

...is basically equivalent to:

   foo { display: inline-block; content: icon; }
   foo::before, foo::after { content: inhibit; }


> 6.5. 'outline-offset' property
> ------------------------------
> This reminds me of the "marker-offset". Is this really important? The
> specification should leave this to the user agents.

The behaviour controlled by 'marker-offset' is now controlled by 'margin',
but it is still controllable.

Some people have requested control over the offset of the outline.


> 8.2.1. Keyboard equivalents: the 'key-equivalent' property
> ----------------------------------------------------------
> "There may be platform and user agent limitations to key-equivalents
> which conflict with those inherent in the user agent and operating
> system."
> Great news. What about the UA behavior in this case?

The term "user agent limitations" implies that in those scenarios the
behaviour is UA-defined.


> "Should we include "standard" keys from other consumer computing
> devices?"

I believe this is an editorial note that was supposed to be removed but
was forgotten.


> Could you expand on this? You call this a last call. Where's the
> solution? This section should be completely reworked.
>
> Etc., etc., etc. This document is not in its Last Call. I'd say it still
> looks like a list of requirements. It has to be carefully reviewed and
> rewritten.

Rewriting a draft is an incredibly time-consuming task for all involved.
The document has already been carefully reviewed and rewritten several
times, it has reached the point where those involved could no longer see
problems, possibly due to their over-familiarity with the document. That
is why we published the document: to get further feedback.

Your input is appreciated, but it would be more helpful to point out
specific problems rather than generally requesting that it be rewritten.

-- 
Ian Hickson                                      )\._.,--....,'``.    fL
"meow"                                          /,   _.. \   _\  ;`._ ,.
http://index.hixie.ch/                         `._.-(,_..'--(,_..'`-.;.'

Received on Monday, 7 July 2003 10:11:21 UTC