- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 15 Apr 2020 16:20:29 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-values] Quirky lengths and math expressions`, and agreed to the following: * `RESOLVED: Properties that accept quirky lengths accept number token which is converted at parse to pixels` * `RESOLVED: This resolution does not apply to any quirks inside of calc` * `RESOLVED: encourage SVG to follow this approach` <details><summary>The full IRC log of that discussion</summary> <dael> Topic: [css-values] Quirky lengths and math expressions<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/4874<br> <dael> emilio: This is when should SVG and quirks accept numbers and when shouldn't<br> <dael> emilio: I think quirks mode shouldn't accept calc but SVG is more debatable.<br> <dael> emilio: Haven't checked issue today so don't know if there's new comments there<br> <dael> astearns: One comment from rune where he links to change list for review on Blink<br> <dael> dbaron: I what emilio is asking is the quirks mode rules that you can omit pixels not apply iside of calc<br> <dael> TabAtkins: That's what I feel should be happening<br> <dael> TabAtkins: Effect of quirks mode is these prop are defined to take number as final value and it's interp as pixel. Has no effect on calc b/c doesn't allow 1 + 3px. If your calc ends up as a number it works out.<br> <dael> TabAtkins: That's what some of the SVG properties do explicitly. If we define quirks as same thing it's a nice consistant system<br> <dael> emilio: Seems to be Peter said he didn't want it to work. A number inside quirks not to work. I'm ambivelent.<br> <dael> florian: Logic is quirks was meant to be limited. This is logical extension, yes, but quirks was meant to be as limited as possible.<br> <dael> AmeliaBR: One complication is as we moved to typedOM and exposing the true computed value not just resolved value things could get a lot messier if we need to keep track of numbers instead of lengths<br> <dael> emilio: I don't think any engine will struggle. Final number interp as a length<br> <dael> emilio: I don't know but I suspect fancy calc rules would require keep track but no one impl. You need math there. Calc that resolves to number you can get final at parse.<br> <dael> TabAtkins: NOt true with the later stuff<br> <dael> TabAtkins: Re-reading comments. Looks like you suggest quirks accepts number token as the value. So write a literal number but not any expression. No calc, attr, etc<br> <dael> TabAtkins: That's fine with me. Would like consistent with SVG but since they didn't originally accept calc I suspect could change<br> <dael> AmeliaBR: SVG presentation attributes where they accept values allowed in regular CSS> Could define presentation attributes are quirky<br> <dael> TabAtkins: Or jsut number token in grammar. Yeah<br> <dael> emilio: sgtm. Happy they're consistent<br> <dael> astearns: Prop: In quirks mode properties don't accept calc<br> <dael> TabAtkins: IN quirks mode properties that need to be quirky will spec to take a number token and interp as pixels<br> <dael> AmeliaBR: Spec when fixup happens? How it effect serialization/computing?<br> <dael> TabAtkins: Don't know today<br> <dael> emilio: I think all serialize pixels.<br> <dael> AmeliaBR: I believet hat's true<br> <dael> emilio: Almost sure webkit and FF do that<br> <dael> astearns: I don't expect the resoltution effects serialization<br> <dael> TabAtkins: I could. Have to say when converts to length<br> <dael> plinss: Should be parse time. Quirks should be as limited as possible and was designed to be phased out. Minimal impact and just at parse time.<br> <dael> TabAtkins: Fine with me<br> <fantasai> +1 to plinss<br> <dael> astearns: Prop: In quirks mode properties that are quirky will be able to take a number token which is interpreted as pixels<br> <dael> emilio: And so should SVG<br> <TabAtkins> Confirmed that Blink converts number to px at parse time.<br> <dael> TabAtkins: Different serialization rules, but otherwise yes<br> <dbaron> and the point is that "can take a number token" doesn't apply any quirks *inside* of calc()<br> <dael> AmeliaBR: Not sure how much we need. attribute value will get attribute. CSS serialization can sync<br> <dael> emilio: We return pixels in specified side<br> <dael> astearns: All one thing to resolve on? Or are there 3 bits to resolve separately?<br> <TabAtkins> proposed resolution: Properties that accept "quirky lengths" are defined as having `<number-token>` in their grammar, which is converted at parse-time to a px length. SVG follows along for its presentation attributes.<br> <dael> emilio: I think...browsers do not agree on quirky SVG so at least 2 resolutions<br> <dael> astearns: Prop: Properties that accept quirky lengths accept number token which is converted at parse to pixels<br> <dael> RESOLVED: Properties that accept quirky lengths accept number token which is converted at parse to pixels<br> <dael> astearns: Second: This resolution does not apply to any quirks inside of calc<br> <fantasai> +1<br> <fantasai> make it clear<br> <dael> emilio: I think that's implied.<br> <dael> astearns: I'd like to specifically resolve to make it clear<br> <dael> TabAtkins: sure<br> <dael> RESOLVED: This resolution does not apply to any quirks inside of calc<br> <dael> astearns: Browser incompat and presentation attributes following along. Can we resolve?<br> <dael> emilio: I've never heard of any compat issues<br> <dael> AmeliaBR: Don't expect issue on compat, but I have to open a separate issue on SVG so we can resolve CSS endorces this and we can add details on SVG<br> <dael> astearns: Prop: encourage SVG to follow this approach<br> <dael> RESOLVED: encourage SVG to follow this approach<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4874#issuecomment-614138114 using your GitHub account
Received on Wednesday, 15 April 2020 16:20:31 UTC