Re: Conditional CSS sections based on property support

I problem I see with having a @require-all-properties { } grouping is
that is creates extra work (and potentially duplicated code) to cover
the conditions where some non-essential property might fail. The new
"outline" property (recently implemented in Gecko) looks nice to use,
but in the majority of use cases I can't imagine that I'd want my
entire style group to fail in Opera because of its absence. The above
@require-all-properties { } would cause failure on superfluous
properties (or cause the author to split their CSS styles into less
intuitive blocks, I think).

I think this was covered with (surprise!) the "@group" syntax in the
previous "!required" stuff, but as a quick summary:

The selector syntax could be extended so that "!required" could also
be applied to the end of a selector, as well as the end of a property:
value pair. This marking an entire style as required.
I don't think that !required on a selector should implicitly mark all
properties of that style as required though, just that in the context
of the stylesheet or containing group, that style must be applied
(such that the style will only *not* be applied if a property marked
as !required cannot be satisfied).

The @group { } * groups a number of styles together on the condition
that if one required style fails (where failure is a result of an
unsupported property or properties being marked !required), the entire
contents of that group are not applied.

This gives the option of requiring a specific property within an
individual style ("property: value !required"), or requiring the full
support for an entire style within a group of related (at the author's
discretion) styles.

Err, that's quite wordy. A quick example:

@group 
{
 foo > bar
 {
  background-color: #0F0;
 }

 foo > bar + banana !required
 {
  some-unsupported-property: blah !required;
  color: #F00;
 }
} /* end of group */

The first style would ordinarily be fine, the second style is required
for the application of the entire group. The second style will fail if
some-unsupported-property is not implemented and thus the failure will
cause the entire group to fail.
If "some-unsupported-property" was *not* marked as !required, however,
then "foo > bar +banana !required" would *never* fail, even if s-u-p
was unimplemented.

I feel more comfortable with "opt-in", defining failure conditions,
than defining conditions for non-failure.

Ben

* Small note: (I'm using "@group" throughout as I have no other idea
of what to call it. Something generic like @group seems appropriate
though, since style grouping could be useful some time in the future
for other purposes).

On Apr 4, 2005 10:53 PM, Laurens Holst <lholst@students.cs.uu.nl> wrote:
> 
> I think that it would be useful to be able to say 'everything must be
> !required'. Because if you have a certain portion on your page that you
> only want to style in a certain way, you would want *everything* to be
> work, or nothing, and writing down !required for *each and every
> property* in a selector seems bothersome and bloated.
> 
> Because in practice, will an author not want every property in such a
> 'requirement block' to be supported? If not, I can see a situation
> arising where page authors will often be singling the requirement down
> on a single 'advanced' property (based on browser testing, likely), and
> assume that the other properties they use just as much based on that
> singled out one.
> 
> For example, would I develop a browser which supports opacity: but not
> position: fixed, sites will try to use position: fixed based on the
> support for opacity! I realise this is a slightly extreme example (or is
> it? sounds like IE), but I think it illustrates my point. Maybe the
> availability of text-shadow on browsers such as Safari which is in other
> respects less advanced than Mozilla is a better example.
> 
> In this light, I think e.g. something to express that *all* properties
> inside must be supported (instead of just one of them) might be a better
> idea. An @-rule like @require-property-support {} sounds alright.
> 
> Problem with this is that if you want to use e.g. browser-specific CSS
> to solve certain issues, it needs to be excluded from the group somehow.
> Because such a single rule would make the block not be applied on all
> other browsers as they do not support it, yet it would need to be part
> of the group because it depends on the condition.
> 
> Take the following example, where I only want to use some CSS when it is
> in border-box render model:
> 
> @require-all-properties {
>     div {
>        width: 100px;
>        padding: 10px;
>     }
>     div {
>        -mox-box-model: border-box;
>        box-model: border-box;
>     }
> }
> 
> How would this work? !exclude? That seems kinda counter-intuitive -_-;;.
> But note how you can't express this with !required either, as the bottom
> two properties have an OR relationship.
> 
> The more I think about it, the more difficult it becomes :). Maybe in
> this light, the 'require-all' thing isn't that much better, or at least
> not trivial to do. But the objection against singling out certain
> properties raised in my second paragraph remains.
> 
> ~Grauw
> 
> --
> Ushiko-san! Kimi wa doushite, Ushiko-san!!
> 
> 


-- 
http://www.ben-ward.co.uk

Received on Monday, 4 April 2005 22:49:21 UTC