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

   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


   - RESOLVED: display:contents applies to ::after and ::before


   - Normalize spec links to anchors in ToC for now.


Agenda: https://lists.w3.org/Archives/Public/www-style/2017May/0040.html

   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

   Benjamin De Cock
   Chris Lilley
   Florian Rivoal
   Lea Verou
   Rachel Andrew
   Vladimir Levantovsky

<RRSAgent> logging to http://www.w3.org/2017/05/24-css-irc

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 https://github.com/w3c/csswg-drafts/pull/1209
   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> https://lists.w3.org/Archives/Public/public-fx/2017AprJun/0011.html
   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> https://github.com/w3c/csswg-drafts/issues/1391
   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: https://github.com/w3c/csswg-drafts/issues/708

   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: https://github.com/w3c/csswg-drafts/pull/713/files

   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
   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: https://github.com/w3c/csswg-drafts/issues/489

   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: https://github.com/w3c/csswg-drafts/issues/434

   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> https://github.com/w3c/csswg-drafts/issues/434#issuecomment-243933445

   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: https://github.com/w3c/csswg-drafts/issues/1241

   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: contents' vs ::before/::after

   GitHub: https://github.com/w3c/csswg-drafts/issues/1345
   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: https://github.com/w3c/csswg-drafts/issues/1395
   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> http://www.w3.org/2017/05/24-css-minutes.html trackbot

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