Re: [css3-ui] Last? Call

Hello Ian, list members,

2003-07-07T18:11:50Z Ian Hickson <ian@hixie.ch> wrote:

>> 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.
This one is pretty useful then.

> 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.)
Is it the policy of the W3C to cover Mozilla's implementations in the
specs?

>> 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.
Rephrasing: What if someone wants to style *just* the padding of the
images according to the padding of the radio buttons?

>> 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.
I agree, that's very useful. Why not use the DOM for this?

> 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.
Ian, could you explain what is "harder to maintain"? For whom or for
what? I'm pretty sure you didn't mean editing CSS by hand here, so
what is it?

I consider the usefulness of the 'icon' value of the 'display'
property equal to zero.

> The 'display:icon' value may be removed at a later stage depending on
> implementation experience.
It spoils and litters the spec.

> The following rule:

>    foo { display: icon; }

> ...is basically equivalent to:

>    foo { display: inline-block; content: icon; }
>    foo::before, foo::after { content: inhibit; }
Too bad. This case is just one among many. And how do you know it is
the most frequent?

>> 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.
Do I have to be an employee of a W3C Member organization to request
properties?

>> 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.
Then you could probably provide a better wording, say, append
"Authors should carefully choose key combinations, etc." and "User
agent behavior is undefined but the WG considers the practice of
assigning key combinations of popular platforms (e.g, Windows Alt+f
stands for search command) to page-specific elements harmful, etc."

And maybe:
"It is the author's responsibility to choose the non-conflicting
key-combinations. We have included a list of key combinations found on
popular platforms: ..."

A better choice for a separator character is the plus sign. I can't
see a good reason for prohibiting lowercase characters in key
combinations. A user is free to use any device including the one with
separate keyboards for lowercase and uppercase characters. That is,
there is a difference between alt+Y and alt+y. The examples in the WD
should use lowercase.

Other system-* equivalents that are worth considering:
1) remove -find-again, introduce -find-next and -find-previous;
2) -save-as;
3) rename -clear to -delete.

Further, it is wrong to include platform-specific keys. How about a
more extensible solution, say, modifier1, modifier2, etc., and the
same for the other keys? Then you could mention that on Windows
typically modifier1 = Ctrl, modifier8 = Win, navigation1 = Enter.

And no left or right key variants of course! That's also wrong as it's
up to user to choose which key to press and should not be controlled
by the author/UA/OS.

Please improve the example with list-item-marker. I think the
key-equivalent property should look like
'key-equivalent: modifier2+list-item-marker' (e.g. alt+a on windows).

>> "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.
I'm sure I can trust you. You claim the draft has been reworked,
reviewed, and reworked again a hundred times. It is worth rereading it
again just to be sure the W3C specification (that can happen to be in
effect for a number of yers) is clean, clear, and unambigious.

>> 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.
I though those who cannot dedicate enough time to a W3C WG are not
employed.

> 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.
Perhaps you receive this feedback in private as I don't see heaps of
comments on this list. Even the wrong link at the w3.org news column
has not bothered people for a couple of days. That can be depressing.

> Your input is appreciated, but it would be more helpful to point out
> specific problems rather than generally requesting that it be rewritten.
Sorry if the previous letter offended you somehow.

What if I politely ask you to include a stylesheet for XHTML 2.0?

Kind regards,
Alex.
-- 
  Alexander "Croll" Savenkov                  http://www.thecroll.com/
  w3@hotbox.ru                                     http://croll.da.ru/

Received on Friday, 11 July 2003 09:45:50 UTC