Brief   Full   Jump  


High contrast


[CSSWG] Minutes Telecon 2017-05-24 [geometry] [css-writing-modes] [css-values] [css-display] [testing]

1 message.

[CSSWG] Minutes Telecon 2017-05-24 [geometry] [css-writing-modes] [css-values] [css-display] [testing]
fantasai   Fri, 26 May 2017 22:21:26 -0400

www-style > May 2017 > 0057.html

Received on Saturday, 27 May 2017 02:22:28 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to:,

========================================= These are the official CSSWG minutes. Unless you're correcting the minutes, Please respond by starting a new thread with an appropriate subject line. ========================================= Geometry API ------------ - RESOLVED: Republish Geomtry API as Working Draft - RESOLVED: Dirk and Rik to former editors of geometry API CSS Writing Modes ----------------- - RESOLVED: shrink-to-fit formula for auto-sized orthogonal flows uses nearest scrollable ancestor, not necessarily viewport CSS Values and Units -------------------- - RESOLVED: Move the close parens to after "including high-resolution devices" - RESOLVED: Unitless zeros are parsed as numbers if it is ambiguous whether they are a <length> or a <number> - Tentative Resolution: Where calc() is resolved at computed value time, clamp at computed value time; otherwise clamp at used value time - RESOLVED: Numeric expressions are explicitly allowed in denominators of calc() expressions Display ------- - RESOLVED: display:contents applies to ::after and ::before Testing ------- - Normalize spec links to anchors in ToC for now. ===== FULL MINUTES BELOW ====== Agenda: Present: Alan Stearns Alex Critchfield Anton Prowse Bert Bos Brad Kemper David Baron Elika Etemad Greg Whitworth Jen Simmons Liam Quin Melanie Richards Myles Maxfield Peter Linss Rossen Atanassov Robert Flack Simon Fraser Simon Pieters Tantek Çelik Tony Graham Regrets: Benjamin De Cock Chris Lilley Florian Rivoal Lea Verou Rachel Andrew Vladimir Levantovsky <RRSAgent> logging to Administrivia ============= Scribe: fantasai Rossen: Any other agenda items? Rossen: no? Rossen: Ok, anyone willing to bikeshedify css-backgrounds? Rossen: would prefer if fantasai didn't have to do it fantasai: Shouldn't be too much work: don't need to convert to Markdown, bikeshed handles HTML just fine. Just need to fix property/value links and boilerplate ericwilligers volunteers Rossen: Is anything else needed here for css-conditional? <Rossen> this dbaron: Haven't had a chance to look Rossen: Ok, please have a look then. action item was you and zcorpan to resolve disrepencies between CSSOM and css-conditional Rossen: Let us know if this PR is all we need, or we need more. Rossen: I've been tracking writing-modes issues Rossen: Anything else besides the issue that's open? fantasai: I need to respond to ChrisL's transition request questions Rossen: Fonts L3, are we done moving things to L4? Rossen: Is ChrisL or Myles here? Rossen: Thanks to everyone for work on moving these things forward. Geometry API ============ <Rossen> zcorpan: It's been a few years zcorpan: since last publication of this spec zcorpan: But recent activity on implementations, spec fixes, tests zcorpan: seems like reasonable time to republish Rossen: New publication has lots of changes, right? So goes back to WD? zcorpan: Yes, seems reasonable, since a long time since CR and lots of changes Rossen: OK Rossen: Objections to WD of Geometry API? <tantek> ship it fantasai: sgtm RESOLVED: Updated WD of Geometry API Rossen: Spec currently lists two people who are no longer active in CSSWG as editors Rossen: means spec effectively has only one editor, zcorpan Rossen: Do you need help with the spec? zcorpan: not atm Rossen: ok, good, then second request would be to move Dirk and Rik to former editors zcorpan: ok RESOLVED: Dirk and Rik to former editors of geometry API CSS Writing Modes: Orthogonal Flow Constraints as viewport vs scroller ---------------------------------------------------------------------- Scribe: zcorpan <Rossen> fantasai: Realized that I hadn't done an action item to update the spec after some discussions several years ago fantasai: we have 2 impl and a test that i need to check into WPT fantasai: the issue is about when you have orthogonal flows and a scroller fantasai: normally when there's no constraint of the child... the height is determined by a shink-to-fit formula fantasai: Spec says to use ICB as the constraint in that formula fantasai: but better to use the height of the nearest ancestor scrollport Rossen: I recall discussing this Rossen: we already agreed to do this for the reasons you outline Rossen: are there any other opinions or alternative proposals? Rossen: if not we can just resolve Rossen: I will take that as a no RESOLVED: shrink-to-fit formula for auto-sized orthogonal flows uses nearest scrollable ancestor, not necessarily viewport Rossen: Does that change go to Level 3? fantasai: yes Rossen: any other knobs or switches ? fantasai: we have the change, the WG resolution, test case and implementations Rossen: ok great CSS Values ========== High-DPI px Anchor ------------------ Github topic: fantasai: There was a pull request for this issue that we accepted to implement the WG resolution. fantasai: I was reviewing the changes to update V&U spec fantasai: The edits also switched the anchor category of print media with unusual viewing distances, which wasn't part of the issue fantasai: Summary of the issue - fantasai: 2 categories for anchor units fantasai: viewing angle unit = px fantasai: other is physical unit like mm/in fantasai: css is based on 96 DPI and px is viewing angle fantasai: used to be independent but had to lock ratio due to web compat fantasai: On print, we anchor to physical unit fantasai: so when you print, 12pt is actually 12pt fantasai: on screen we anchor to viewing angle pixel approximation, round to actual pixels to make it look nice on the screen fantasai: print and high-dpi used to be classed together... fantasai: but the change to move high-dpi screens also moved all devices with unusual viewing distances fantasai: so for print with unusual viewing distance, which category? fantasai: now it's in the physical category fantasai: do we want to revert the change? Rossen: So, going to echo florian's point... Rossen: since this is a SHOULD, do we need to change? fantasai: if we don't have anything we intentionally want to change, we shouldn't make a change from the previous CR; implies some intention behind the difference <dbaron> seems like if you're taking content written for another device and print it on a billboard, you want your "12pt" font to be bigger than 12pt dbaron: the change seems reasonable to me dbaron: if you take content designed from a different device and print to a billboard you may want the viewing distance thing dbaron: OTOH if you design for the billboard you may want physical units plinss: seems like this should be a choice when you're printing plinss: not happy with either change plinss: it's a print-time choice based on the content, device, etc plinss: shouldn't mandate from the spec Rossen: right, that's why it's a should Rossen: might be enough plinss: I think that's not what should means <tantek> where is the change? <astearns> tantek: bradk: seems like a viewing angle situation bradk: language an opt-in, in e-paper(?) you can go either way fremy: can't you leave it as choice per device? plinss: need all devices to be consistent tantek: i'm confused by the example of billboard vs print fantasai: it's an example of a device with an unusual viewing distance tantek: looking at the diff in github... billboard can be print or screen dbaron: the PR changed printed billboard because of the way it worded it fantasai: [citing spec?] fantasai: not a subset of screen media fantasai: 1 category is high-res, second is low-res and unusual viewing distance fantasai: before you could interpret print with unusual viewing distance as either fantasai: now it can only be that for screen media <fantasai> Proposal is to move the close parentheses after "including high-resolution devices" Rossen: sounds pretty good <Rossen> For screen media (including high-resolution devices), lower-resolution devices, and devices with unusual viewing distances, tantek: sounds sensible <bradk> I agree fantasai: ok, i will make the change plinss: happy with the change plinss: maybe provide an opt-in later <tantek> +1 to proposal RESOLVED: Move the close parens after "including high-resolution devices" Ambiguous Unitless Zeroes ------------------------- Scribe: myles GitHub: fantasai: we have a situation where you can have <interger> or <length> (or <nubmer> & <length>) & it's not clear what happens with unitless zero. fantasai: Situation occurs in, e.g., tab-size & line-height. <fantasai> cases are property syntaxes like <integer> | <length> fantasai: which of type does the unitless 0 parse to? fantasai: currently there is no behavior difference for these properties, but in the future it might matter Rossen: so where would it matter? Rossen: in calc(), parsing would fail if you do it wrong Rossen: in another expression, in grid gaps, or something else, it will always be interpreted as a <length> fantasai: xidorn says that 0 lengths get serialized as "0px" Rossen: the computed style? fantasai: I dunno, not an OM person fantasai: TabAtkins says that the Typed OM might want to make a distinction fantasai: we could make a rule "if you're in an ambiguous situation, it parses as a number" Rossen: yes, and later in the cascade, you could typecast the number to an internal unit type, imlementation-specific, and the implementation could handle it Rossen: the question is: what happens when you serialize it back out? Do you return the number or a real length? Rossen: for us, if we have to tag along an additional information about what I just described, it's going to be difficult Rossen: not impossible though. Rossen: doesn't buy authors much. Rossen: (unless we have a specific example) fantasai: we could not fix it, or we can say it parses as an integer fantasai: those are the two options fantasai: dbaron? fantasai: <restates the question> dbaron: i thought it would be a number fantasai: spec doesn't say that fantasai: can we resolve? Rossen: i have no problem keeping it as a number Rossen: objections? Rossen: to specify it as a number if it isn't already RESOLVED: Unitless zeros are parsed as numbers if it is ambiguous whether they are a <length> or a <number> Clamping calc() --------------- GitHub: fantasai: this question was about when things get clamped, if you have a property which doesn't accept negative lengths, for example, the spec says that the used value is clamped, but the computed value is not clamped, and there is some disagreement about whether that is waht is implemented <fantasai> dbaron's comment from GitHub: For properties where the computed value is a length (i.e., calc()s that are computed at computed value time) like font-size, we clamp to nonnegative values at computed value time. For properties where the calc() expression is part of the computed value space (like padding-left) we have clamping at used value time (both in the GetComputedStyle code and in the code that actually uses the value). I think the spec is still wrong for properties that accept calc() but where calc() is not part of the computed value space since it can be fully computed by computed value time (e.g., font-size). <fantasai> Rossen: to further TabAtkins's latest point, some or most of this is referring to getComputedStyle() which returns used values not computed values Rossen: it seems like WebKit and blink don't have a separate notion of computed values, and this is a transient value for them dbaron: there is some value which gets inherited. If you have "25% - 30px" and you say this is the computed value and it gets inherited to something which clamps differently, it should be clamped differently Rossen: but you don't know that 25% gets resolved to something > 25px fantasai: but you do know this for some properties fantasai: for padding-left you don't know this, because percents depend on layout and are not known at computed value time. fantasai: but font-size, you do know this: you can resolve this at computed value time, and you *need* to because the value of font-size needs to be computed to a length in order to resolve ems. Rossen: font-size is the only property which resolves percentages outside of layout fantasai: dbaron: no Rossen: .... Rossen: ok. fantasai: dbaron, do you have a proposal? dbaron: not off the top of my head dbaron: i could write one fantasai: yes please dbaron: we need a distinction where calc() is resolved at computed value time and where calc() is part of a computed value. these needs separate rules fantasai: ok. fantasai: in the first case, we would do the clamping at computed value time, and the second case, it would be at used value time dbaron: yes Rossen: how is this observable? dbaron: the difference is observable through inheritance. but also, some of the combinations of ways of specifying it, it doesn't make any sense fantasai: let's resolve Rossen: we need a proposal fantasai: i can write proposed text fantasai: w/ dbaron's review Rossen: let's see the prose before we resolve fantasai: sounds good Numeric Expression Denominators in calc() ----------------------------------------- GitHub: fantasai: we originally intended the denominator of calc() to allow a numeric expression fantasai: like calc(13 / (5 + 3)) fantasai: we don't like units in the denominator because unit math is hard fantasai: numeric math is ok though fantasai: This isn't in the spec but we do have implementations. So we should add this to level 3 fantasai: Filing against level 4 doesn't make sense because level 4 will include all the unit math and everything which would be a superset of this fantasai: but we need a resolution if we want to add it to level 3 Rossen: yes please Rossen: <expresses support> Rossen: any objections? RESOLVED: Numeric expressions are explicitly allowed in denominators of calc() expressions Display ======= 'display: contents' vs ::before/::after --------------------------------------- GitHub: fantasai: <restates the topic> fantasai: TabAtkins and i are leaning toward "yes" but we aren't particularly resolute fantasai: any opinions? Rossen: it is unclear, if we say "no," what is observable? fantasai: you can put a border on ::after, and the border will disappear if you say display:contents, because the box will disappear Rossen: was this just an oversight? fantasai: just needed clarification, wanted to check if there were any probs Rossen: this works for us Rossen: objections? RESOLVED: display:contents applies to ::after and ::before Testing: Normalizing Spec Links ------------------------------- <Rossen> Github issue: gregwhitworth: a lot of tests are duplicative in the flex tests. They link to the flex-basis propdef or ... somewhere else gregwhitworth: i want to make them uniform gregwhitworth: someone commented fantasai: we used to have the rule that you would link only to anchors in the table of contents fantasai: i'm okay to revise that rule, but that rule was simple gregwhitworth: that doesn't work because we need deeper links gregwhitworth: except it's okay for now fantasai: sections are usually fine-grained enough in L3 specs, except for flexbox and grid layout algorithms, each bullet point has an anchor, which allows us to be more fine-grained, and it makes more sense there to go deeper gregwhitworth: gsnedders and i were talking about how to understand test coverage. If anyone has any suggestions, please mention them dbaron: there are cases where the propdef is more stable across spec versions fantasai: usually we have one section per property dbaron: not always, and there are often multiple properties in the same section. you might want to link to one individually fantasai: we do that less now. dbaron: css-align has a lot of these fantasai: true Rossen: we are out of time, folks Rossen: we have a solution which will unblock gregwhitworth and gsnedders Rossen: need to continue investing in improving Rossen: please help if you have ideas Rossen: do we need resolution? gregwhitworth: no Rossen: We can just do what fantasai said gregwhitworth: i'll link to sections for now, and if someone argues, we can revisit fantasai: you can also link to both plinss: let's not make a rule, instead, let's just do this for a single spec Rossen: ok plinss: ok Rossen: please start booking flights to paris Rossen: byebye <RRSAgent> trackbot