W3C home > Mailing lists > Public > www-style@w3.org > July 2013

Re: [selectors4] Using the complete profile in non-interactive media?

From: Lea Verou <lea@w3.org>
Date: Mon, 1 Jul 2013 23:19:16 +0300
Cc: www-style list <www-style@w3.org>
Message-Id: <BB9FA5AE-5465-4790-9594-B8DAA0542953@w3.org>
To: Tab Atkins Jr. <jackalmage@gmail.com>
Thanks Tab, apparently I had sent regrets for that telcon and missed that part in the minutes.

So, if I'm getting this right, it was decided that the complete profile shouldn't be available in print with the rationale that it's ...confusing? What about the use cases it would solve?
There are many things available in print today that aren't available in other media types, e.g. CMYK colors.
I think the complete profile should be available in as many contexts as possible, even if that confuses some people, but maybe I'm in the minority.

On Jul 1, 2013, at 23:11, Tab Atkins Jr. <jackalmage@gmail.com> wrote:

> On Mon, Jul 1, 2013 at 11:45 AM, Lea Verou <lea@w3.org> wrote:
>> Currently, Selectors 4 [1] says:
>> 
>>> CSS implementations conformant to Selectors Level 4 must use the ‘fast’
>>> profile for CSS selection.
>> 
>> I'm not sure what this leaves besides the Selectors API, but shouldn't UAs
>> use the complete profile for non-interactive media as well, such as print?
>> The performance issues are not present there, right?
> 
> This was discussed here:
> <http://lists.w3.org/Archives/Public/www-style/2013Apr/0246.html>
> (look near the bottom, particularly Simon Sapin's lines)
> 
>> Also, why is this a "must" and not a "may"? With this wording, if a UA finds
>> a way to support the complete profile for CSS Selection, it will be a spec
>> violation! Or am I missing something?
> 
> If browsers figure out how to support something sufficiently that it
> can be done in normal CSS, we'll move it into the fast profile.  What
> we don't want is browsers being encouraged to implement a
> shitty-but-fast version of one of the complicated features.
> 
> ~TJ
Received on Monday, 1 July 2013 20:19:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:31 UTC