[css-ui-3] using non fixed size SVG in the cursor property

[frivoal]

About the cursor property, css-ui-3 says:

The UA must support the following image file formats:

• [...]
• SVG, as defined in [SVG11], in secure static mode [SVG2]

In addition, the UA should support the following image file formats:

• [...]
• SVG, as defined in [SVG11], in secure animated mode [SVG2]

Since it doesn't specify any exception, that includes SVG with non fixed sized. However, no browser implement that. See these test results: https://test.csswg.org/harness/details/css-ui-3_dev/cursor-image-005-nfs/

Unless we have 2 browser just about to implement support for non fixed sized SVG cursors, I suggest we punt this feature to level 4, and only require support for fixed size SVG in level 3.

The UA must support the following image file formats:

• [...]
• SVG, as defined in [SVG11], in secure static mode [SVG2], if it has an intrinsic size.

In addition, the UA should support the following image file formats:

• [...]
• SVG, as defined in [SVG11], in secure animated mode [SVG2], if it has an intrinsic size.

In addition, the UA may support the following image file formats:

• [...]
• SVG, as defined in [SVG11], in secure static mode or secure animated mode [SVG2], even if it does not have an intrinsic size.

[frivoal]

Ramblings on IRC on this topic: https://log.csswg.org/irc.w3.org/css/2017-09-13/#e872693

[AmeliaBR]

What currently happens in browsers? Do they use the SVG, but scale it to 0px square? Or do they ignore it like a broken image, and fall back to default system cursors?

I would prefer a platform-specific default size, rather than ignoring it altogether. If we plan to add in defaults later, it might be best to word it as "This specification does not define a default size if the referenced image does not have an intrinsic size; authors should be aware that many user agents currently do not render the image at all in those cases."

Also, that warning should be generic (for images without intrinsic size), rather than specific to SVG. Hypothetically, user agents could support other image formats that don't have intrinsic sizes.

[AmeliaBR]

PS, by "platform-specific default size", I meant "based on the size of the system cursors", in case that wasn't clear. A 300px by 150px cursor is probably not a good default.

[frivoal]

What currently happens in browsers? Do they use the SVG, but scale it to 0px square? Or do they ignore it like a broken image, and fall back to default system cursors?

The later. Well, they fallback, but not directly to system cursors, they fallback to the chain you've defined. If you have cursor: non-fixed.svg, fixed.svg, foo.ico, resize, browsers that support svg in cursors (all but Edge) will fallback to fixed.svg, Edge will fallback to foo.ico, and a theoretical browser that supported none of this would fallback to resize.

I would prefer a platform-specific default size, rather than ignoring it altogether.

That is what the spec currently calls for:

The default object size for cursor images is a UA-defined size that should be based on the size of a typical cursor on the UA’s operating system.

where default object size is a term that redirects to the css-image spec, which results in what you'd want: display non-intrinsically sized images at the largest size that fits within default object size without distorting its aspect ratio if it has one.

A 300px by 150px cursor is probably not a good default.

Indeed:) 16x16 is likely a better starting point (in device independent CSS pixels, so 32x32 on a retina screen, and so on), keeping in mind that this isn't the largest size, but the default size.

[css-meeting-bot]

The Working Group just discussed using non fixed size SVG in the cursor property, and agreed to the following resolutions:

• RESOLVED: SVG without intrinsic dimensions MAY be supported (not MUST), add a note

The full IRC log of that discussion

<dael> Topic: using non fixed size SVG in the cursor property
<dael> Github: https://github.com//issues/1813
<dael> Rossen_: Thanks florian for progress updates. Remaining issue is non-fixed size SVG as cursor
<tantek> hmm - I thought we solved that by referencing a profile
<dael> florian: We mandate support for SVG and forgot to say anything about those without an intrinisic size. For general SVG there is support, but no one supports it without intrinisic size. I'm not seeing progress despite having bugs, so therefore I think we should change the spec, maybe to a may
<dael> florian: It's defined how you would do it, but nobody is.
<dael> Chris: There is clear spec text to say what to do. It's not a case we can clarify, but no one seems to want to impl
<dael> TabAtkins: Does anybody allow other sizeless types?
<dael> florian: Not, but they're a may
<dael> TabAtkins: I'm fine with it in same category as those.
<dael> Chris: I am too, but won't be fixed by same method so that's even more of a may
<dael> dbaron: One comment is that when we change things in order to weaken requirements to have impl, I'd like to have notes to say what we intended so that people 5 years from now know why it's a may.
<dael> florian: The behavior is not tied to SVG, it's anything without a size. So that would stay in and I would add prose to say if svg doesn't have intrinisic size you may support it. I'm happy to add spec text saying we wanted it.
<dael> tantek: I think I agree with dbaron's point to add a note to give the intent of the group, but I kinda disagree with leaving it in as a may for something never impl. If we had one impl I'd be comfortable, but given no one impl that means it hasn't been incubated.
<dael> Chris: In abstract I agree, but on this do you see a specific issue?
<dael> tantek: I don't, but I wouldn't know until we try and impl. it's unknow unknowns
<dael> Chris: It's the do we add 32 32 problem. This isn't rocket science.
<dael> tantek: In this case I"m going to say display densitity is highly variable and changing.
<dael> Chris: okay
<dael> TabAtkins: I don't understand why dencitiy is relevent. THere's a size the UA uses for the default to render cursor.
<dael> Rossen_: Let's step away from process and go back to the issue.
<fantasai> tantek, if we don't allow this with a MAY we have to forbid it, which means any implementation that tries will be non-conformant
<dael> Rossen_: I didn't hear anyone disagree that the current lack of support suggests we might have to weaken current spec text with a may. Is this something people are objecting to? Or is this how to do better as spec editors.
<dael> tantek: I am.
<dael> tantek: I propose we do a note instead of normative text.
<dael> florian: We can't do that instead of a may.
<dael> florian: If we do a note instead of a may, we fallback to you must support svg or you must not support. That's not a good idea.
<dael> Rossen_: Can I hear from dbaron? I understood it was a may with a note saying it wanted to be a must
<JonathanNeal__> Hello!
<tantek> the point was to explicitly *drop* from normative text what has not been implemented, AND add the NOTE: with explicit text indicating consensus intent of the WG
<dael> dbaron: They're different points. I'm saying when we make changes to enter PR we should say what the old thing way
<dael> florian: And I'm happy to do that
<JonathanNeal__> Would someone be able to DM me to help me join this call?
<dael> dbaron: And that's different then tantek point
<dael> Rossen_: and tantek is about process which I don't want to do now.
<fantasai> tantek, you can't "drop" the text, you can forbid the implementation of this subset by *adding* text
<dael> Rossen_: Obj to changing a the must to a may for svg cursor and add a note expalining the internded must behavior?
<dael> tantek: I obj because that's not reflecting what florian wants.
<dael> florian: It's a specific case.
<dael> tantek: The way you phrased it isn't florian's proposal.
<dael> florian: Rossen_ you said svg in general, it's just the non-intrinisic sized ones.
<dael> Rossen_: florian can you put the actual text?
<dael> Rossen_: thanks for the correction tantek
<tantek> alternatively how about restricting the MUST to intrinsic sized SVG?
<florian> PROPOSED RESOLUTION: SVG without intrinsic dimensions MAY be supported (not MUST), add a note
<tantek> and then just leave non-intrinsic sized unspecified, and documented in the NOTE?
<tantek> see alternative
<dael> Rossen_: Objections to florian's proposed resolution?
<tantek> -0
<dael> fantasai: I agree with that.
<dael> Rossen_: Anyone favor tantek's?
<dael> florian: It's editor wordsmithing.
<fantasai> tantek, you'd have to explicitly undefine it to make it undefined, it's defined in css-images
<dael> Rossen_: obj to florian proposed resolution?
<dael> RESOLVED: SVG without intrinsic dimensions MAY be supported (not MUST), add a note

[AmeliaBR]

OK, working on actual spec text.

The current text in CSS UI 3:

The UA must support the following image file formats:

• PNG, as defined in [PNG]
• SVG, as defined in [SVG11], in secure static mode [SVG2]
• any other non-animated image file format that they support for <image> in other properties, such as the the background-image property

In addition, the UA should support the following image file formats:

• SVG, as defined in [SVG11], in secure animated mode [SVG2]
• any other animated image file format that they support for <image> in other properties, such as the the background-image property

The UA may also support additional file formats.

...

The default object size for cursor images is a UA-defined size that should be based on the size of a typical cursor on the UA’s operating system.

As I'm reading the IRC notes (sorry I missed the call), the changes should be:

• Add a qualification to both "The UA must support the following image file formats" and "the UA should support the following image file formats", saying "for images with intrinsic dimensions". (Added at the top of the list, not in the SVG bullet point, so that it includes both SVG and the "any other format" item).

• After "The UA may also support additional file formats" add something like "In particular, the UA may support images without intrinsic dimensions, by using a UA-defined default object size for cursor images, which should be based on the size of a typical cursor on the UA’s operating system."

• (Then remove the extra paragraph that has been moved up into the "may" section.)

• Maybe (?) add an informative note explaining that the CSS WG would really like to add normative support for cursors without intrinsic dimensions, if only UAs would be so kind as to implement it.

I personally would have argued for adding no-intrinsic size to the "should" list, instead of "may" but... anyway. Not a big difference in practice.

[AmeliaBR]

PS @frivoal s/indented/intended/ here

csswg-drafts/css-ui/Overview.bs

Line 979 in 5dcad30

Note: The CSS Working group initially indented support for all SVG,

Also, I'm not sure if Bikeshed will auto-link "intrinsic size" to CSS Images, but it would be nice to have that link. (To the section on "intrinsic dimensions".)

[frivoal]

Pull request for updating the relevant test here: web-platform-tests/wpt#7430