Re: [css3-ui] Last? Call

On 7/11/03 6:40 AM, "Alexander Savenkov" <w3@hotbox.ru> wrote:

> 
> 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?

The 'appearance' property was something that myself, Sho Kuwamoto and Peter
Linss came up with many many years ago during a CSS working group meeting,
as a drastic simplification (for both authors and UA developers) to provide
access to presentation of system user interface defaults.  I believe it was
actually introduced in a working draft of CSS-UI *before* Mozilla
implemented -moz-appearance, although I'm not certain if that draft was
*published* before it was implemented.


>>> 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?

The short answer is they don't.  Want to that is.  This a theoretical need
for which we have seen *no* practical need.  Adding values for all the
various different properties would *hugely* expand, complicate the spec in
return for little or no value to authoring community (actually, some
negative value in that it would make CSS more complex for everyone) in
exchange for costing UA developers a lot.


>>> 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?

Short answer: using the DOM is both more complicated and less reliable.

In general is *strongly* desirable to provide simple declarative solutions
to "common" problems that typically have procedural solutions.

And for more complicated interactions, where the condition upon which the
icon display switches is some sort of computation, this property actually
makes it easier (simpler) to use the DOM (rather, the CSS-OM) as well.


>> 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"?

More rules, especially more rules and are dependent in an intertwining way
are "harder to maintain", or, put another way, more fragile.

> For whom or for
> what? I'm pretty sure you didn't mean editing CSS by hand here, so
> what is it?

The fewer the necessary rules to achieve a particular effect, the easier and
more reliable it is for the author to write the rules, come back to them
later and modify the rules, and see by example what others are doing and
learn the rules.

It's also easier for UA implementers to *test* a feature if it requires
fewer rules.

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

Not all properties are expected to be useful to all authors (or user, or
devices, or media for that matter).  In this particular case, needs have
been expressed by the WAI community for this functionality.

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

Feedback noted.  If implementation experience yields that the 'display:icon'
functionality is unnecessary, or provides little to no benefit, it may be
dropped from the spec (as any other feature might).


>> 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?

I don't understand - why is this too bad?  And what does the frequency
matter?


>>> 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?

No.  Many CSS3 properties and values are derived from suggestions that folks
on www-style have made over the years.  See the list of suggested extensions
to CSS:

 http://www.w3.org/TR/NOTE-CSS-potential

That list itself links to proposals made on www-style, and much of CSS3 has
been developed as a result of such feedback mechanisms.

Typically the working group has been fairly conservative about adding new
features to CSS, that is, they've only been added if a number of
representatives are supportive of the additions, and there are no strong
objections.


>>> 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: ..."

This is a good suggestion and I think some wording along these lines would
be appropriate.

> A better choice for a separator character is the plus sign.

Strongly disagreed.  User interface / human interface literature has used
the dash '-' as the separator character in this context consistently
throughout history and therefore we have adopted the same industry
convention rather than invent a new one.  See for example, Apple Human
Interface Guidelines, published 1986, pp.72-73.

> 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.

Are there such devices?  The editor and contributors to the draft have never
seen (or even heard of such a device).  If you could provide an actual
example of such a device then that would be provide more merit to this
discussion.

> That is,
> there is a difference between alt+Y and alt+y.

Typically there isn't, but again, if you provide an example, the group may
reconsider.

> The examples in the WD
> should use lowercase.

Disagreed.  Simply look at any typical computer keyboard.  Notice that the
letters on the keys are typically in uppercase.

> Other system-* equivalents that are worth considering:
> 1) remove -find-again, introduce -find-next and -find-previous;

Good suggestion.

> 2) -save-as;

Do you know of systems that have key equivalents for "Save As..."?

Just checking WinXP and MacOS9 - they don't.

I'd rather add system-* equivalents that are more common in use across
platforms (e.g. *widely* supported across numerous systems) rather than
bloat the list with every equivalent that may have occurred once on a
particular version of an OS because doing so may mislead the content author
into believing they are hooking into functionality that isn't there.

> 3) rename -clear to -delete.

-clear is one of the typical Edit menu items, whereas I don't think -delete
is.  I'd rather not rename this unless there is a good justification for
doing so.

> Further, it is wrong to include platform-specific keys.

Why?

As far as why include them, authors have asked for this functionality for
quite some time.  It remains to be seen if it will be implemented (to be
discovered during the CR period), but we should at least allow for it since
it has been requested by many.

> 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.

This level of abstraction seems even more confusing and thus I don't think
this is a good idea.

> 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.

For such modifier keys, 'key-equivalent' provides a generic variant and both
right and left specific variants, e.g.

 <cmd-key> = cmd | rcmd | lcmd

 because some user interface developers (specifically game developers)
*have* commonly made use of this distinction.

Of course it is recommended that for typical use, the generic variant is
preferable, and I should probably add a note to that effect.  So the spirit
of your feedback is accepted.


> 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).

Perhaps I should mention this in the spec explicitly, but the
list-item-marker equivalent functionality was introduced specifically for
(and at the request of the developers of) handheld/cellphone UAs, where you
literally just press the key that is the same as the list-item marker to
activate the menu item, that is why the example is as it is.

>>> "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.

Ian is right, I overlooked this note and it was supposed to be removed.  It
will be removed for CR.

> You claim the draft has been reworked,
> reviewed, and reworked again a hundred times.

Maybe not a hundred, but certainly more than ten, with many many hours spent
on it (I should know ;).

> 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.

Yes it is, however, when only a small number of people review a document,
they typically miss things, especially a document that has been reviewed so
often and for so long as this one has (which has been developed in some form
or another for about four years).

Fortunately you and the rest of the www-style are helping with this, and the
working group appreciates the time you have taken to review the document and
write up your feedback.


>>> 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.

I think what Ian meant to say is that the working group does not believe
that the document needs to be completely reworked.

It seems like the issues you raise can be resolved with mostly editorial
changes, rather than a complete rewrite.  Why do you think a rewrite is
necessary?


>> 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.

There have been lots of comments on "css3-ui" "css-ui" "CSS UI" "CSS User
Interface" on www-style over the past four years.  And yes, some
(significant) amount of feedback/comments have come from internal feedback
at member companies who are looking to implement or use the new features.


> Even the wrong link at the w3.org news column
> has not bothered people for a couple of days. That can be depressing.

Which link, could you be more specific?  I don't know where it the right
forum to give feedback regarding the w3.org news column, but I don't think
this is it.


>> 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?

I think that may be either/both inappropriate or/and premature since CSS3 UI
is expected to go to CR within a month or so, whereas XHTML 2.0 has not
reached last call yet.

And it is also more appropriate for the default style sheet in the XHTML 2.0
spec to state list style rules using whatever CSS3 UI features are intended
as default presentation/behavior.

E.g. perhaps something like:

 *[href] { appearance: hyperlink }

Since 'href' can be utilized on (nearly) every element in XHTML 2.0.

> Kind regards,
> Alex.

Thanks again for your thoughtful feedback Alex.

Tantek Çelik
editor, CSS3 Basic User Interface module

Received on Friday, 11 July 2003 14:09:18 UTC