15:54:56 <RRSAgent> RRSAgent has joined #css
15:54:56 <RRSAgent> logging to http://www.w3.org/2017/05/24-css-irc
15:54:58 <trackbot> RRSAgent, make logs public
15:54:58 <Zakim> Zakim has joined #css
15:55:00 <trackbot> Zakim, this will be Style_CSS FP
15:55:00 <Zakim> ok, trackbot
15:55:01 <trackbot> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
15:55:01 <trackbot> Date: 24 May 2017
15:55:23 <Rossen_> present+
15:57:09 <antenna> antenna has joined #css
15:59:06 <zcorpan> present+
16:00:02 <dauwhe> regrets+ dauwhe
16:00:07 <smfr> smfr has joined #css
16:00:11 <antenna> present+
16:00:21 <antonp> Present+ antonp
16:00:36 <Rossen_> dauwhe, we're not good enough for you anymore :/
16:01:14 <tantek> present+
16:01:15 <smfr> present+
16:02:10 <ericwilligers> ericwilligers has joined #css
16:02:30 <plinss> present+
16:02:31 <alex_antennahouse> alex_antennahouse has joined #css
16:02:41 <alex_antennahouse> present+
16:03:07 <fantasai> present+
16:03:10 <fantasai> SribeNick: fantasai
16:03:18 <tgraham> present+
16:03:27 <jensimmons> present+
16:03:55 <flackr> present+
16:04:06 <Florian> Florian has joined #css
16:04:21 <bcampbell> bcampbell has joined #css
16:05:54 <fantasai> Rossen: Any other agenda items?
16:05:56 <fantasai> Rossen: no?
16:05:57 <dbaron> Present+
16:06:08 <fantasai> Rossen: Ok, anyone willing to bikeshedify css-backgrounds?
16:06:49 <fantasai> Rossen: would prefer if fantasai didn't have to do it
16:07:42 <fantasai> 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
16:07:44 <astearns> present+
16:07:48 <Rossen_> this https://github.com/w3c/csswg-drafts/pull/1209
16:07:54 <fantasai> ?? volunteers
16:08:13 <fantasai> Rossen: Is anything else needed here for css-conditional?
16:08:20 <fantasai> dbaron: Haven't had a chance to look
16:08:39 <astearns> s/??/ericwilligers/
16:08:40 <fantasai> Rossen: Ok, please have a look then. action item was you and zcorpan to resolve disrepencies between CSSOM and css-conditional
16:08:40 <liam> present+
16:08:57 <fantasai> Rossen: Let us know if this PR is all we need, or we need more.
16:09:06 <fantasai> Rossen: I've been tracking writing-modes issues
16:09:15 <melanierichards> present+
16:09:15 <fantasai> Rossen: Anything else besides the issue that's open?
16:09:44 <fantasai> fantasai: I need to respond to ChrisL's transition request questions
16:09:53 <fantasai> Rossen: Fonts L3, are we done moving things to L4?
16:09:55 <Bert> present+
16:10:08 <fantasai> Rossen: Is ChrisL or Myles here?
16:10:41 <fantasai> Rossen: Thanks to everyone for work on moving these things forward.
16:10:55 <fantasai> Topic: Update to Geometry API
16:11:11 <fantasai> zcorpan: It's been a few years
16:11:14 <myles> myles has joined #css
16:11:16 <fantasai> zcorpan: since last publication of this spec
16:11:26 <fantasai> zcorpan: But recent activity on implementations, spec fixes, tests
16:11:34 <fantasai> zcorpan: seems like reasonable time to republish
16:11:46 <Rossen_> https://lists.w3.org/Archives/Public/public-fx/2017AprJun/0011.html
16:11:47 <fantasai> Rossen: New publication has lots of changes, right? So goes back to WD?
16:11:56 <fantasai> zcorpan: Yes, seems reasonable, since a long time since CR and lots of changes
16:11:57 <bradk> bradk has joined #css
16:11:58 <fantasai> Rossen: OK
16:12:09 <fantasai> Rossen: Objections to WD of Geometry API?
16:12:18 <tantek> ship it
16:12:20 <fantasai> fantasai: sgtm
16:12:20 <myles> present+ myles
16:12:30 <bradk> present+
16:12:40 <fantasai> RESOLVED: Updated WD of Geometry API
16:12:41 <fremy> fremy has joined #css
16:13:07 <fantasai> Rossen: Spec currently lists two people who are no longer active in CSSWG as editors
16:13:16 <fantasai> Rossen: means spec effectively has only one editor, zcorpan
16:13:24 <fantasai> Rossen: Do you need help with the spec?
16:13:31 <fantasai> zcorpan: not atm
16:13:47 <fantasai> Rossen: ok, good, then second request would be to move Dirk and Rik to former editors
16:13:51 <fantasai> zcorpan: ok
16:14:02 <fantasai> RESOLVED: Dirk and Rik to former editors of geometry API
16:14:21 <zcorpan> Topic: [css-writing-modes] Orthogonal Flow Constraint: viewport vs scroller
16:14:23 <Rossen_> https://github.com/w3c/csswg-drafts/issues/1391
16:14:33 <zcorpan> fantasai: Realized that I hadn't done ???
16:14:33 <Rossen_> Github issue: https://github.com/w3c/csswg-drafts/issues/1391
16:14:48 <zcorpan> fantasai: we have 2 impl and a test that i need to check in
16:14:58 <zcorpan> fantasai: the issue is about when you have orthogonal flows and a scroller
16:15:36 <zcorpan> fantasai: normally when htere's no constraint of the child... the height is determined by a shink-to-fit formula
16:15:52 <zcorpan> fantasai: better to use the hight of the nearest ancestor
16:16:02 <zcorpan> Rossen_: I recall discussing this
16:16:05 <fantasai> s/nearest ancestor/nearest scrollable ancestor/
16:16:30 <zcorpan> Rossen_: we already agreed to do this for the reasons you outline
16:16:42 <zcorpan> Rossen_: are there any other opinions or alternative proposals?
16:16:49 <zcorpan> Rossen_: if not we can just resolve
16:16:58 <zcorpan> Rossen_: I will take that as a no
16:17:58 <fantasai> RESOLVED: shrink-to-fit formula for auto-sized orthogonal flows uses nearest scrollable ancestor, not necessarily viewport
16:18:01 <zcorpan> Rossen_: Does that change go to Level 1?
16:18:08 <fantasai> s/1/3/
16:18:11 <zcorpan> Rossen_: any other knobs or switches ?
16:18:30 <zcorpan> fantasai: we have the change, the WG resolution, test case and implementations
16:18:43 <zcorpan> Rossen_: ok great
16:18:56 <Rossen_> Github topic: https://github.com/w3c/csswg-drafts/issues/708
16:19:09 <zcorpan> Topic: [css-values] clarify that most (all?) high-dpi devices anchor on pixel, rather than physical, unit
16:19:19 <dbaron> that went to the wrong github issue
16:19:43 <zcorpan> Github topic: https://github.com/w3c/csswg-drafts/issues/708
16:20:08 <zcorpan> fantasai: PR for ???
16:20:18 <zcorpan> fantasai: reviewing the changes to update V&U spec
16:20:24 <zcorpan> fantasai: one implemented the resolution here
16:20:41 <zcorpan> fantasai: also switch the ... anchor category
16:20:47 <zcorpan> fantasai: 2 categories for anchor units
16:20:56 <zcorpan> fantasai: pixel viewing angle unit
16:21:04 <zcorpan> fantasai: other is physical unit
16:21:21 <zcorpan> fantasai: css is based on 96 DPI and px is viewing angle
16:21:33 <zcorpan> fantasai: used to be independent but changed due to web compat
16:21:50 <zcorpan> fantasai: when you print, 12pt is actually 12pt
16:22:08 <zcorpan> fantasai: on screen we do the 96DPI thing and round to actual pixels to make it look nice on the screen
16:22:19 <zcorpan> fantasai: print and high-dpi together...
16:22:34 <zcorpan> fantasai: the change also moved devices with unusual viewing distances
16:22:56 <zcorpan> fantasai: so for print with unusual viewing distance, which category?
16:23:14 <zcorpan> fantasai: now it's in the physical category
16:23:19 <zcorpan> fantasai: do we want to revert the change?
16:23:32 <zcorpan> Rossen_: So, going to echo florian's point...
16:23:40 <zcorpan> Rossen_: since this is a SHOULD, do we need to change?
16:23:48 <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
16:23:58 <zcorpan> fantasai: if we don't have anything we want to change we shouldn't change from the previous PR
16:24:15 <zcorpan> dbaron: the change seems reasonable to me
16:24:43 <zcorpan> dbaron: if you take content designed from a different device and print to a billboard you may want the viewing distance thing
16:24:58 <zcorpan> dbaron: OTOH if you design for the billboard you may want physical units
16:25:21 <dbaron> plinss: seems like this should be a choice when you're printing
16:25:24 <zcorpan> plinss: not happy with either change
16:25:27 <tantek> where is the change?
16:25:42 <zcorpan> plinss: it's a print-time choice based on the content, device, etc
16:25:47 <zcorpan> plinss: shouldn't mandate from the spec
16:25:54 <zcorpan> Rossen_: right, that's why it's a should
16:25:59 <astearns> tantek: https://github.com/w3c/csswg-drafts/pull/713/files
16:26:01 <zcorpan> Rossen_: might be enough
16:26:19 <fantasai> tantek, https://github.com/w3c/csswg-drafts/pull/713/files
16:26:20 <zcorpan> plinss: I think that's not what should means
16:26:43 <zcorpan> bradk: seems like a viewing angle situation
16:27:22 <zcorpan> bradk: language an opt-in, in ebook(?) you can go either way
16:27:45 <zcorpan> fremy: can't you leave it as choice per device?
16:28:08 <zcorpan> plinss: need all devices to be consistent
16:28:19 <bradk> s/ebook/e-paper
16:28:37 <zcorpan> tantek: i'm confused by the example of billboard vs print
16:28:51 <zcorpan> fantasai: it's an example of a device with an unusual viewing distance
16:29:10 <zcorpan> tantek: looking at the diff in github... billboard can be print or screen
16:29:35 <zcorpan> dbaron: the PR changed printed billboard because of the way it worded it
16:29:47 <zcorpan> fantasai: [citing spec?]
16:29:59 <zcorpan> fantasai: not a subset of screen media
16:30:18 <zcorpan> fantasai: 1 category is high-res, second is low-res and unusual viewing distance
16:30:41 <zcorpan> fantasai: before you could interpret print with unusual viewing distance as either
16:30:49 <zcorpan> fantasai: now it can only be that for screen media
16:31:18 <zcorpan> fantasai: becomes ???
16:31:37 <zcorpan> someone: sounds sensible
16:31:38 <fantasai> Proposal is to move the lcose parentheses after "including high-resolution devices"
16:31:43 <fantasai> s/someone/tantek/
16:31:52 <Rossen_> For screen media (including high-resolution devices), lower-resolution devices,   and devices with unusual viewing distances,
16:32:10 <zcorpan> Rossen_: sounds pretty good
16:32:11 <astearns> s/,   /, /
16:32:17 <bradk> I agree
16:32:17 <zcorpan> fantasai: ok, i will make the change
16:32:25 <zcorpan> plinss: happy with the change
16:32:36 <zcorpan> plinss: maybe provide an opt-in later
16:32:59 <fantasai> ScribeNick: fantasai
16:33:06 <zcorpan> Proposed resolution:  move the lcose parentheses after "including high-resolution devices"
16:33:50 <tantek> +1 to proposal
16:33:52 <fantasai> RESOLVED: Move the close parens afte r"including high-resolution devices"
16:33:55 <myles> scribenick: myles
16:34:14 <Rossen_> Topic: [css-values] Parsing "<integer> | <length>" or "<number> | <length>"
16:34:20 <fantasai> Topic: CSS Values and Units: ambiguous zero
16:34:34 <fantasai> github topic: https://github.com/w3c/csswg-drafts/issues/489
16:34:37 <Rossen_> Github issue: https://github.com/w3c/csswg-drafts/issues/489
16:35:10 <myles> fantasai: we have a situation where you can have <interger> or <length> (or <nubmer> & <length> & it's not clear what happens with unitless zero.
16:35:25 <myles> fantasai: tab-size & line-height. which of these values does the 0 parse to?
16:35:31 <jamesn> jamesn has joined #css
16:35:37 <myles> fantasai: currently there is no behavior difference for these properties, but in the fiture it might matter
16:35:46 <myles> Rossen: so where would it matter?
16:35:54 <fantasai> cases are like <integer> | <length>
16:35:55 <myles> Rossen: in calc(), parsing would fail if you do it wrong
16:36:03 <fantasai> properties affected include tab-size and line-height
16:36:14 <myles> Rossen: in another expression, in grid gaps, or something else, it will always be interpreted as a <length>
16:36:26 <myles> fantasai: xidorn says that 0 lengths get serialized as "0px"
16:36:30 <myles> Rossen: the computed style?
16:36:32 <myles> fantasai: i dunno
16:36:48 <myles> fantasai: TabAtkins says that the OM might want to make a distinction
16:36:56 <fantasai> s/OM/Typed OM/
16:37:16 <myles> fantasai: we could make a rule "if you're in an imbiguous situation, it parses as a number"
16:37:37 <fantasai> s/imbig/ambig/
16:37:40 <myles> 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
16:37:50 <jnurthen> jnurthen has joined #css
16:38:07 <myles> Rossen: the question is: what happens when you serialize it back out? Do you return the number or a real reallyrealies length
16:38:46 <myles> Rossen: for us, if we have to tag along an additional information about what i just described, it's going to be difficult
16:38:51 <myles> Rossen: not impossible though.
16:39:01 <myles> Rossen: doesn't buy authors much.
16:39:10 <myles> Rossen: (unless we have a specific example)
16:39:20 <myles> fantasai: we might not fix it, or we can say it parses as an integer
16:39:25 <myles> fantasai: those are the two options
16:39:38 <myles> fantasai: dbaron?
16:39:51 <myles> fantasai: <restates the question>
16:40:07 <myles> dbaron: i thought it would be anumber
16:40:12 <myles> fantasai: spec doesn't say that
16:40:32 <myles> fantasai: can we resolve?
16:40:37 <myles> Rossen: i have no problem keeping it as a number
16:40:40 <myles> Rossen: objections?
16:40:52 <myles> Rossen: to specify it as a number if it isn't already
16:41:16 <myles> RESOLVED: Unitless zeros are parsed as numbers if it is ambiguous whether they are a <length> or a <number>
16:41:20 <fantasai> Topic: CSS Values and Units: clamping calc()
16:41:29 <fantasai> github topic: https://github.com/w3c/csswg-drafts/issues/434
16:42:01 <Rossen_> Rossen_ has joined #css
16:42:01 <myles> 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
16:42:20 <myles> fantasai: dbaron says that calc() is computed at computed value liek font size
16:42:38 <fantasai> dbaron's comment:
16:42:39 <fantasai> For properties where the computed value is a length (i.e., calc()s 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).
16:42:46 <fantasai> 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).
16:42:56 <fantasai> https://github.com/w3c/csswg-drafts/issues/434#issuecomment-243933445
16:43:25 <myles> Rossen: to further TabAtkins's latest point, some or most of this is referring to getComputedStyle() which returns used values not computed values
16:43:35 <jamesn> jamesn has joined #css
16:43:39 <myles> Rossen: it seems like WebKit and blink don't have a separate notion of computed values, and this is a transient value for them
16:44:13 <myles> 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
16:44:21 <myles> Rossen: but you don't know that 25% gets resolved to something > 25px
16:44:26 <myles> fantasai: but you do know this for some properties
16:44:35 <myles> fantasai: for padding-left you don't know this, but font-size, you do know this
16:44:55 <myles> fantasai: you can resolve this at computed value time, and you need to because the value at font-size needs to be computed to a length in order to resolve em
16:45:03 <myles> Rossen: font-size is the only property which resolves percentages outside of layout
16:45:05 <myles> fantasai: dbaron: no
16:45:13 <myles> Rossen: ....
16:45:17 <myles> Rossen: ok.
16:45:28 <myles> fantasai: dbaron, do you have a proposal?
16:45:34 <myles> dbaron: not off the top of my head
16:45:37 <myles> dbaron: i could write one
16:45:42 <myles> fantasai: yes please
16:46:05 <myles> 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
16:46:06 <myles> fantasai: ok.
16:46:22 <myles> 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
16:46:23 <myles> dbaron: yes
16:46:27 <myles> Rossen: how is this observable?
16:46:44 <myles> dbaron: the difference is observable through inheritance. but also, some fo the combinations of ways of specifying it, it doesn't make any sense
16:46:57 <myles> fantasai: let's resolve
16:47:01 <myles> Rossen: we need a proposal
16:47:17 <myles> fantasai: i can write a proposal
16:47:22 <myles> fantasai: w/ dbaron's review
16:47:37 <myles> Rossen: let's see the prose before we resolve
16:47:55 <myles> fantasai: sounds good
16:48:14 <fantasai> Topic: CSS Values and Units: numeric expression denominators
16:48:17 <fantasai> github topic: https://github.com/w3c/csswg-drafts/issues/1241
16:48:41 <myles> fantasai: we originally intended the denominator of calc() to have a numeric expression
16:48:49 <myles> fantasai: like calc(13 / (5 + 3))
16:48:54 <myles> fantasai: we don't like units because unit math is hard
16:49:01 <myles> fantasai: numeric math is ok though
16:49:16 <myles> fantasai: that isn't in the spec but we do have implementations. so we should add this to level 3
16:49:34 <myles> fantasai: level 4 doesn't make sense because level 4 will include all the unit math and everything which would be a superset of this
16:49:45 <myles> fantasai: but we need a resolution if we want to add it to level 3
16:49:48 <myles> Rossen: yes please
16:49:54 <myles> Rossen: <expresses support>
16:49:59 <myles> Rossen: any objections?
16:50:50 <myles> RESOLVED: Numeric expressions are explicitly allowed in denominators of calc() expressions
16:51:36 <myles> gregwhitworth: i'm trying to get the flex tests, uh
16:51:41 <dbaron> horrible noise/echo
16:52:08 <Rossen_> Topic: Testing - Normalize linking to CSS properties
16:52:09 <myles> gregwhitworth: a lot of these tests go to ... sections .... so i need to know .... <static static>
16:52:16 <Rossen_> Github issue: https://github.com/w3c/csswg-drafts/issues/1395
16:52:35 <myles> gregwhitworth: i want to clean up flex tests.
16:53:11 <tantek> jensimmons++
16:53:25 <myles> gregwhitworth: let's discuss this next week. sorry for the noise.
16:53:42 <myles> Rossen: you don't want to discuss this?
16:53:47 <myles> Rossen: please come up to my office
16:53:55 <myles> Rossen: <plays jeopardy theme song>
16:54:12 <myles> TOPIC: https://github.com/w3c/csswg-drafts/issues/1345
16:54:25 <myles> Github topic: https://github.com/w3c/csswg-drafts/issues/1345
16:54:39 <myles> s/write/right/
16:54:51 <myles> fantasai: <restates the topic>
16:55:07 <myles> fantasai: TabAtkins and i are leaning toward "yes" but we aren't particularly resolute
16:55:12 <myles> fantasai: any opinions/
16:55:15 <myles> fantasai: ?
16:55:26 <myles> Rossen: it is unclear, if we say "no," what is observable?
16:55:40 <myles> fantasai: you can put a border on ::after, and the border will disappear if you say display:contents
16:55:45 <myles> fantasai: because the box will disappear
16:55:59 <myles> Rossen: was this just an oversight?
16:56:05 <myles> fantasai: just needed clarification
16:56:24 <myles> Rossen: this works for us
16:56:34 <myles> Rossen: objections?
16:56:58 <myles> RESOLVED: display:contents applies to ::after and ::before
16:57:12 <Rossen_> Topic: Testing - Normalize linking to CSS properties
16:57:37 <Rossen_> Github issue: https://github.com/w3c/csswg-drafts/issues/1395
16:57:53 <myles> gregwhitworth: a lot of tests are duplicative in the flex tests. They link to the flex bases or ... somewhere else
16:57:57 <myles> gregwhitworth: i want to make them uniform
16:58:06 <myles> gregwhitworth: someone commented
16:58:25 <myles> fantasai: we used to have the rule that you would link only to the table of contents
16:58:37 <myles> fantasai: i'm okay to revise that rule, but that rule was simple
16:58:52 <myles> gregwhitworth: that doesn't work because we need deeper links
16:59:00 <myles> gregwhitworth: except it's okay for now
16:59:29 <myles> fantasai: the main cause where it's tricky is that sections are usually what you want, 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
17:00:06 <myles> gregwhitworth: gsnedders and i were talking about how to understand test coverage. If anyone has any suggestions, please mention them
17:00:18 <myles> dbaron: there are cases where the header is more stable across spec versions
17:00:29 <myles> fantasai: usually we have one section per property
17:00:31 <Florian> Florian has joined #css
17:00:47 <myles> dbaron: not always, and there are often multiple properties in the same section. you might want to link to one individually
17:00:51 <myles> fantasai: we do that less now.
17:00:56 <myles> dbaron: css-align has a lot of these
17:01:05 <myles> Rossen: we are out of time, folks
17:01:13 <myles> Rossen: we have a solution which will unblock gregwhitworth and gsnedders
17:01:20 <myles> Rossen: need to continue investing in improving
17:01:27 <myles> Rossen: please help if you have ideas
17:01:31 <plinss> s/where the header/where the property link/
17:01:43 <myles> Rossen: do we need resolution?
17:01:47 <myles> gregwhitworth: no
17:01:56 <myles> Rossen: we will follow fantasai off a clifff
17:02:15 <fantasai> ~_~
17:02:33 <myles> gregwhitworth: i'll link to sections for now, and if someone argues, we can revisit
17:02:40 <myles> plinss: let's not make a rule, instead, let's just do this for a single spec
17:02:45 <myles> Rossen: ok
17:02:49 <myles> plinss: ok
17:02:50 <zcorpan> zcorpan has joined #css
17:03:15 <myles> Rossen: please start booking flights to paris
17:03:21 <myles> Rossen: byebye
17:03:37 <zcorpan> zcorpan has joined #css
17:04:14 <Rossen_> github topic:
17:04:15 <fantasai> tantek, haven't booked anything yet
17:04:24 <Rossen_> Topic: done
17:04:38 <Rossen_> trackbot, end meeting
17:04:38 <trackbot> Zakim, list attendees
17:04:38 <Zakim> As of this point the attendees have been Rossen_, zcorpan, antenna, antonp, tantek, smfr, plinss, alex_antennahouse, fantasai, tgraham, jensimmons, flackr, dbaron, astearns, liam,
17:04:41 <Zakim> ... melanierichards, Bert, myles, bradk
17:04:46 <trackbot> RRSAgent, please draft minutes
17:04:46 <RRSAgent> I have made the request to generate http://www.w3.org/2017/05/24-css-minutes.html trackbot
17:04:47 <trackbot> RRSAgent, bye
17:04:47 <RRSAgent> I see no action items