Re: [css3-ui] file formats for the cursor property

On Mon, Mar 16, 2015 at 1:30 PM, Florian Rivoal <florian@rivoal.net> wrote:
> On 16 Mar 2015, at 09:39, Tantek Çelik <tantek@cs.stanford.edu> wrote:
>
> Hi Tantek,
>
> Thanks for chiming in, this is a tricky topic indeed.
>
>> This is exactly why we have left cursor file formats unspecified and
>> not required. The situation has not changed since we discussed it
>> years ago.
>> [...]
>> This not a new issue (in general), HTML5 has (had?) the same issue
>> with <video> and <audio>.
>
> There are clearly many parts in the platform where we don't define
> which file formats should or must be supported. However, most of the
> time, this is because we could not do so, not because we prefer not
> to do so. Video is a good example of that, and so is @font-face.

The reason often *why* cannot do so is because we cannot make a
normative reference to a close spec for the format.

> Referring to PNG and SVG is something we can do if we want to,

Agreed.

> and
> so is requiring with a MUST all image static formats the UA already
> supports for the <image> type (as used in 'background-image'),
> or with a SHOULD the animated ones.

That sounds reasonable.


> All browsers other than IE already do this MUST (and safari does
> the SHOULD). Since we already cannot depend on IE to meet the spec's
> CR exit criteria (it misses a number of other features), adding this
> would not slow the spec down.

We do CR exit criteria per feature, not per implementation; I disagree
with this reasoning.

That being said, like I said, sounds like a reasonable change.


>> For any such format we'd like to suggest, even as a should, we need
>> * an open spec we can normatively reference.
>
> As I mentioned it in my initial mail, I agree with you that the lack of
> a spec we can reference for .ico and .cur is an problem.

It is a non-starter.


> At the same time,
>> Multiple implementations implementing a cursor file format is
>> *insufficient* to making such a format a must (or even a should).
>
> All browsers support this pair of formats, and since this pair of
> format is alone in being supported by all browsers, by and large
> that's what content uses.

GIF was similar I believe.


> Being able to be spec compliant without being interoperable is only
> moderately useful,

That's up to implementers to determine - not us.


> so we would be doing a disservice to new
> User Agents (Servo?) by leaving .ico and .cur out.

I disagree, and disagree that it would somehow affect Servo's decision
on this matter.

Whether Servo implements .ico and .cur is likely dependent on whether
they are necessary for the content / use-cases that Servo is trying to
address.

Regardless, we CANNOT add a MUST requirement of an aspect (i.e.
format) a feature that is defined in a spec which we are unable to
normatively reference (lack of open spec), and since there is no open
spec for .ico and .cur, we are unable to normatively reference them.

This is based on W3C rules for normative references - and we may not
even be able to publish an updated draft if we attempt to normatively
reference something that violates W3C's referencing policy.

It doesn't matter if you or the whole group thinks we should
normatively reference a non-open spec - W3C publishing / process will
reject it.

We can provide an informal reference to .ico / .cur, an informal note
about existing implementations, and we can use them in tests to exit
CR. But AFAIK, that's all we can do.

Tantek

Received on Wednesday, 18 March 2015 06:11:03 UTC