W3C home > Mailing lists > Public > www-style@w3.org > April 2005

Re: Stand-in color before images load

From: Ben Ward <benmward@gmail.com>
Date: Wed, 6 Apr 2005 13:24:12 +0100
Message-ID: <ef5d0f2f05040605243a795ab4@mail.gmail.com>
To: Mikko Rantalainen <mikko.rantalainen@peda.net>
Cc: www-style@w3.org

> I addition, explicit collection is much easier to understand.
> Compare following:
> 
> @require-all {
>    foo bar {
>      color: black;
>      background-color: white;
>      position: fixed;
>      font-family: "Custom Font #1252", sans-serif;
>    }
> }
> 

I agree that you do gain some clarity from the block naming there, but
I don't think it's as intuitive to use.
As with any failure froup you end up splitting up code more than
before - one within the @require-all {} block for properties which
depend on each other, then non-essential properties and essential (non
dependent) properties in another block/s.
Alternatively, you could have some kind of "not required" syntax so
that styles can be kept in more condensed groups.

I think it ends up as the opposite of !required. My reservation
remains as before, that consciously thinking about which styles
/don't/ matter (so as to exclude them from a @require-all block) is
more difficult and less intuitive than thinking about which styles /do
matter/ (and adding a marker to the associated properties).

> I think that there's a problem if @group{ ... } doesn't mean
> anything unless it contains string "!required" somewhere.

I'm not sure I see what that problem is? @group is a pretty clear,
generic wrapper. It is the "!required" keyword which adds the
functionality we're all describing.

The potential advantage is providing a syntax that allows you to group
styles together (even if you don't apply any kind of !requirement on
it) which may be an aid to coding CSS3 (it's worth checking to see if
using @group { } acts as a mask around styles in the current breed of
CSS1/2 browsers, for example).

I agree that @group remains the wooliest part of the whole !required
idea though. It comes down to whether it is seem as useful to have an
entirely generic grouping mechanism, which could be used to provide
functionality such as !required, and in future some other, similarly
syntaxed functionality. Or whether it would be more preferable to head
down the road of having more numerous, specifcally named groups, such
as @require-all, @media, @page, @etc, @another-new-idea. I don't know
which of those two routes is better in terms of comprehensibility and,
critically, impact on future implementation.

What follows is a bit of a mind munge about @group and the like, since
it remains the least comfortable part of this whole issue, as far as I
can tell.

* On the face of it, if we had @group and then added more than one
kind of functionality (I shall call it "!something") to those groups,
then all post CSS3 user agents would recognise group and read the
contents, rather than finding @some-new-block and ignoring it
outright.
* Since they don't support "!something", what should they do? Should
they abandon all, assuming that the new "!something" required some
special and critical behaviour? If a @something { } group name was
used, this would be equivilent to ignoring the block.
* Or should it try anyway? Plus, would it be wise to allow !something
and !required and !something-else and !foo to be combined in the same
group?
* Does/should @group add anything to the existing "!important" marker?
Would it be inconsistant/confusing not to?


I wonder if having a generic @group would be a bad idea and pose
future compatibility problems which could be avoided if using
@something-specific. However, I do still think that specifying a
particular property as being !required within that block (opt-in) is
more intuitive than doing the reverse.

Ben
-- 
http://www.ben-ward.co.uk
Received on Wednesday, 6 April 2005 12:24:14 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:36 GMT