W3C home > Mailing lists > Public > www-style@w3.org > September 2012

Re: [css3-conditional] thoughts about css3-conditional

From: Marat Tanalin | tanalin.com <mtanalin@yandex.ru>
Date: Sat, 01 Sep 2012 16:45:45 +0400
To: jinlongz <jinlongz@oupeng.com>
Cc: www-style <www-style@w3.org>,Zi Bin Cheah <zibin@opera.com>
Message-Id: <520631346503545@web21h.yandex.ru>
31.08.2012, 12:16, "jinlongz" <jinlongz@oupeng.com>:
>   I just translated css3-conditional[1] and I'd like to share my opinions.
>
>   ISSUE 3:
>
>   "Is any further allowance for forward-compatible parsing needed, for
>   Example, to allow additional features (such as, say, selector tests)
>   to be added to the ‘@supports’ rule? Or are these forward-
>   compatible parsing rules the best solution for such future expansion
>   anyway?"
>
> I think it's fine to only make @supports support CSS values. At least making @supports do CSS selectors doesn't seem necessary. Whenever there's a browser that doesn't support a CSS3 selctor, the declarations are already ignored.

Selectors are not limited to CSS3-level ones. There will be new selectors invented constantly. So it may make sense to be more flexible and use something more specific like `@supports-property`, `@supports-selector` etc. instead of `@supports` that looks universal but is actually limited to properties and their values. Specific syntax could be another. For example, some pseudo-class could be used:

    @supports:selector (some new selector) {}

    @supports:property (some-property: some-value) {}

    @supports:something-another-to-be-introduced-in-future (something another) {}

Currently, spec could say that `@supports` without a pseudoclass is equivalent to `@supports:property`, and new pseudoclasses can be added to the spec in future.

>   ISSUE 5
>
>   Given that this @-rule is intended primarily for user style sheets,
>   what should this specification say about its use in author style
>   sheets? Should it be forbidden? Should use instead be discouraged? Or
>   should this specification remain neutral on the topic, since there
>   are valid uses in author style sheets?
>
> I think this section should apply to author style sheets. As what follows, I think there are use cases here.

It's probably just out of spec responsibility whether it should be used in user stylesheets or in author ones.

Also, it's questionable whether URL must always include protocol and domain. For author stylesheets, it could be more useful to allow URLs relative to root of current domain (for example `/products/` instead of full `http://example.com/products/`). It probably would be overkill to use `@document regexp` to omit protocol and domain when matching URL to exact path string relative to domain root.

>   ISSUE 8:
>
>   "@document" syntax doesn't offer any ability to do negations, which
>   has been requested in Mozilla bug 349813.
>
> I also think @document should support the "not" syntax. Many sites publish common style sheets for the whole site, say, reset.css and such. It would be useful to be able to exclude certain special pages from using these style sheets with something like
>
>   @document :not url('example.com/particular')

Indeed, this could be useful.
Received on Saturday, 1 September 2012 12:46:16 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:59 GMT