Re: Optional Style Rules (@option proposal)

Bjoern Hoehrmann wrote:
> Indeed. What I would rather see than syntax proposals is a compilation
> of desired properties of such a mechanism to derive requirements to both
> design solutions and measure solutions.

   OK, so, basically, you want something to help begin the process of 
writing a requirements document for analysing what currently can, and 
can't be done, compared with what should be able to be done, and to 
determine which features would be most beneficial to the development and 
use of CSS in the long run.

> As you point out, modular composition of a site style sheet is such a
> property. Persistence is another, how to maintain the style sheet
> selecion/composition throughout a site, how to override it for specific
> parts of a site, how to maintain state across browser sessions, etc.
<snip/>
> Hence, what properties do we desire and how important are they?

   Yes, all of those ideas definitely are worth looking at, however for 
this post, I will focus on optional rules/alternate style sheets and 
some use cases where they could be useful.  Based on your response, I'll 
focus less on the syntax, and more on the functional requirements.  The 
importance and feasibility of each idea can be decided later.

   I assume it's well known how current UAs user style sheet 
implementations are basically limited to changing colours, backgrounds, 
and font sizes.  IE does allow a single CSS file to be used as a user 
style sheet, and Mozilla can do so, using some of the available 
extensions.  However, providing those few simple options, and being 
essentially limited to using either a single user style sheet or the 
supplied author style sheet(s), with very limited ability to mix 'n' 
match styles from various sources, isn't very useful.

   My concept of options is that different sections of a style sheet can 
be specified and applied either independently of, or (in some cases) 
dependent on other sections of a style sheet.  The aim is to reduce the 
need to write a complete style sheet for every possible combination of 
styles that a user may wish to use.

   Also, if the UA presented the user with a easy to understand set of 
options, it would increase the use of user style sheets on the web. 
(Because, an option, whether it was provided with the UA, created by the 
user, or loaded as part of the author style sheet, should be treated as 
a user style sheet preference when activated.  Thus, it reduces the need 
for the user to have knowledge of CSS, and it *should* (assuming IE 
won't throw in more proprietary properties) allow options to be shared 
freely among UAs, users and authors to work on virtually any document.

   The following points will list some of the requirements and ideas 
that I can think of.  The examples included are extremely trivial, and 
are only there to show the concept, but not necessarily a real world use.

1. Optional styles can be specified by the author, a UA or the user and
    can be applied, at the user's preference.
    a. Some of these options should be able to be applied no matter
       which alternate style sheet has been selected.
    b. Some may only be applicable when one specific alternate
       style sheet is selected.
    c. Others may be applicable to a group of alternate styles, but not
       all.

2. User Agents should be able to remember the preferences set by the
    user for sites and/or browsing sessions.

3. Options should be seamlessly integrated into the user interface,
    regardless of whether they were provided by the author, UA or the
    user.

4. Options should be able to be grouped into categories.  Some categories
    could have requirements on the number of selected options.
    a. Zero or One
       eg. Options: "Red" or "Blue"
       "Either Red, or Blue, but not both; or another, such as Green.
    b. Zero or more;
       eg. "Expanded Abbr.", "Show Hyperlink Uri’s"
       Both can be turned on or off independently of each other.
    c. Exactly one; or
       eg. Options: "Serif Font", "Sans-Serif Font", "Mono-Space Font"
       One and only one font-family can be selected at a time;
    d. One or more.
       (Can't think of an example, but you should understand)

5. Some options may only be applicable when other option(s) are
    selected
    eg. Can only select Arial, Helvetica or Verdana, when
        Sans-Serif is selected.
    a. This suggests, that maybe options could form a hierarchical, or
       maybe even a network structure, and be nested within, or somehow
       linked to other options.
    b. This is similar to point 1.b.  Maybe options shouldn't be totally
       different from alternate style sheets, but rather an extension to
       them.

6. Options should be able to be specified by the author, UA, or user as
    being on or off by default.
    (eg. perhaps an 'active' and/or 'inactive' keyword(s), but that's
     syntax, so at this stage, it doesn't really matter)

7. Some options may apply to any number of media types.

8. Selected options may have slight variations depending on the selected
    alternate style sheet.

9. It may be useful for options to be importable from external style
    sheets.
    eg. If I have a Style sheet containing nothing but a collection of
    options, I should be able to import some, but not necessarily all
    options into one or more of my style sheets (without copying and
    pasting)

10. Options may be as simple as changing font, size and or colour
    properties, or as advanced as rearranging content (eg. moving the
    navbar, etc…).  Thus, an option really is similar to an alternate
    style sheet, except that other options can also be applied with it.

   Now that I've actually, really thought about different uses of 
options and how they may be applied, it now seems that even the original 
syntax I proposed, may be too limited to meet all requirements and ideas 
I've suggested, though it could be a good start.

-- 
Lachlan Hunt

Received on Sunday, 2 May 2004 03:10:36 UTC