- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 20 Sep 2017 16:48:40 +0000
- To: public-css-archive@w3.org
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` <details><summary>The full IRC log of that discussion</summary> <dael> Topic: using non fixed size SVG in the cursor property<br> <dael> Github: https://github.com/w3c/csswg-drafts/issues/1813<br> <dael> Rossen_: Thanks florian for progress updates. Remaining issue is non-fixed size SVG as cursor<br> <tantek> hmm - I thought we solved that by referencing a profile<br> <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<br> <dael> florian: It's defined how you would do it, but nobody is.<br> <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<br> <dael> TabAtkins: Does anybody allow other sizeless types?<br> <dael> florian: Not, but they're a may<br> <dael> TabAtkins: I'm fine with it in same category as those.<br> <dael> Chris: I am too, but won't be fixed by same method so that's even more of a may<br> <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.<br> <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.<br> <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.<br> <dael> Chris: In abstract I agree, but on this do you see a specific issue?<br> <dael> tantek: I don't, but I wouldn't know until we try and impl. it's unknow unknowns<br> <dael> Chris: It's the do we add 32 32 problem. This isn't rocket science.<br> <dael> tantek: In this case I"m going to say display densitity is highly variable and changing.<br> <dael> Chris: okay<br> <dael> TabAtkins: I don't understand why dencitiy is relevent. THere's a size the UA uses for the default to render cursor.<br> <dael> Rossen_: Let's step away from process and go back to the issue.<br> <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<br> <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.<br> <dael> tantek: I am.<br> <dael> tantek: I propose we do a note instead of normative text.<br> <dael> florian: We can't do that instead of a may.<br> <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.<br> <dael> Rossen_: Can I hear from dbaron? I understood it was a may with a note saying it wanted to be a must<br> <JonathanNeal__> Hello!<br> <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<br> <dael> dbaron: They're different points. I'm saying when we make changes to enter PR we should say what the old thing way<br> <dael> florian: And I'm happy to do that<br> <JonathanNeal__> Would someone be able to DM me to help me join this call?<br> <dael> dbaron: And that's different then tantek point<br> <dael> Rossen_: and tantek is about process which I don't want to do now.<br> <fantasai> tantek, you can't "drop" the text, you can forbid the implementation of this subset by *adding* text<br> <dael> Rossen_: Obj to changing a the must to a may for svg cursor and add a note expalining the internded must behavior?<br> <dael> tantek: I obj because that's not reflecting what florian wants.<br> <dael> florian: It's a specific case.<br> <dael> tantek: The way you phrased it isn't florian's proposal.<br> <dael> florian: Rossen_ you said svg in general, it's just the non-intrinisic sized ones.<br> <dael> Rossen_: florian can you put the actual text?<br> <dael> Rossen_: thanks for the correction tantek<br> <tantek> alternatively how about restricting the MUST to intrinsic sized SVG?<br> <florian> PROPOSED RESOLUTION: SVG without intrinsic dimensions MAY be supported (not MUST), add a note<br> <tantek> and then just leave non-intrinsic sized unspecified, and documented in the NOTE?<br> <tantek> see alternative<br> <dael> Rossen_: Objections to florian's proposed resolution?<br> <tantek> -0<br> <dael> fantasai: I agree with that.<br> <dael> Rossen_: Anyone favor tantek's?<br> <dael> florian: It's editor wordsmithing.<br> <fantasai> tantek, you'd have to explicitly undefine it to make it undefined, it's defined in css-images<br> <dael> Rossen_: obj to florian proposed resolution?<br> <dael> RESOLVED: SVG without intrinsic dimensions MAY be supported (not MUST), add a note<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1813#issuecomment-330912545 using your GitHub account
Received on Wednesday, 20 September 2017 16:48:33 UTC