[CSSWG] Minutes Telecon 2018-10-17 [css-paged-media-3] [css-ui] [css-grid] [css-align] [selectors-4] [css-multicol] [css-shadow-parts] [css-inline]

  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.

CSS Paged Media L3

  - RESOLVED: Publish updated WD of Paged Media L3


  - RESOLVED: Change cursor in vertical writing mode to a must (Issue

CSS Grid

  - RESOLVED: Accept this edit:
              [A computed track list is a list alternating between
              line name sets and track sections, with the first and
              last items being line name sets.] (Issue #3154)

CSS Align & Grid

  - RESOLVED: Content alignment and self alignment share a baseline
              (Issue #3200)

Selectors 4

  - There is a request for review of Issue #3071: :valid-within /
      :invalid-within pseudo-classes


  - During the discussion of Issue #3064 (Shouldn't column-fill: auto
      take min-height into account?) there was interest in creating a
      general approach to handling heights so this topic will be added
      to the F2F agenda where it can be discussed with a whiteboard.

CSS Shadow Parts

  - The right people weren't on the call to cover Issue #2386 (confirm
      browser support) so it will be added to the F2F agenda

CSS Inline

  - RESOLVED: Add drop and raise as keywords to initial-letters
              property (Issue #2955)
  - RESOLVED: Order does not matter for the keyword in initial-letter
              property (Issue #2955)


Agenda: https://lists.w3.org/Archives/Public/www-style/2018Oct/0009.html

  Rachel Andrew
  Rossen Atanassov
  David Baron
  Tantek Çelik
  Emilio Cobos Álvarez
  Dave Cramer
  Alex Critchfield
  Benjamin De Cock
  Elika Etemad
  Javier Fernandez
  Tony Graham
  Dael Jackson
  Cameron McCormack
  Manuel Rego Casasnovas
  Melanie Richards
  Florian Rivoal
  Jen Simmons
  Alan Stearns
  Greg Whitworth
  Fuqiao Xue

  Chris Harrelson
  Peter Linss

Scribe: dael

CSS Paged Media L3

  astearns: Are there any changes to the agenda people would like?
  xfq: I have one. Update CSS paged media L3
  astearns: Republish?
  xfq: Yes a working draft
  <xfq> https://lists.w3.org/Archives/Public/www-style/2018Sep/0020.html

  astearns: What has changed?
  xfq: The current version on /tr is from 2013. It doesn't contain
       some normative changes like the bleed property
  xfq: I would like to request a new WD mostly because w3c css
       validator needs a stable reference
  xfq: Is there any objection?
  florian: I haven't reviewed delta but I remember reading the ED
           before and not finding a glaring problem. I'm in general in

  dbaron: I'd like to hear from editors if they support
  fantasai: I think there should be update WD, don't think there's
            controversy, but I haven't made a changes
  xfq: I've seen commit and all substantive changes are in changes
       list now
  fantasai: Okay, then seems reasonable
  astearns: Thanks for reviewing change list

  astearns: Any objections to update WD of Paged Media L3?

  RESOLVED: Update WD of Paged Media L3

  astearns: Other agenda?


  astearns: Housekeeping: continue adding things to TPAC agenda. We've
            got a good set but I'm happy to take more.
  dbaron: I added a column for time conflicts. Might be useful if
          people who will have to miss part of the meeting fill that
  astearns: Thank you. That would be very useful.
  astearns: Also if you want to call in for particular topics it would
            be good to know times and topics
  <rego> https://wiki.csswg.org/planning/tpac-2018


Add value `horizontal-text` to property `cursor`
  github: https://github.com/w3c/csswg-drafts/issues/3196#issuecomment-427739133

  florian: Conversation has evolved. The property has 2 values about
           text: text and vertical-text. 'text' is when it's a
           vertical the I beam that usually shows like it's
           horizontal, but the browser may show vertical at vertical
           and may do angles. That we have one must on vertical-text
           but a may on text it's a problem.
  florian: Suggestion is change the may to a must. If it's over
           vertical text you must match. Diagonal I think stays as a
  florian: If we get that for text we can deprecate vertical-text

  dbaron: State of implementations switching to vertical?
  florian: I don't remember. At least one impl does it, but I don't
           remember if more than one
  astearns: I'd be more happy to resolve if we have an impl report
  astearns: If this is something we'd have to wait on bugs or if this
            is uncontroversial
  florian: It is not something everyone impl.
  florian: I think I have the list, but I'd have to find it.
  myles: Webkit does rotate
  <heycam> Gecko also does
  <heycam> just tested it
  dbaron: I can tell you Gecko has code that does it, though I haven't
          made sure it works
  florian: Test harness is too slow to pull results
  dbaron: It's possible we only work for auto
  fantasai: Works for text
  myles: Chrome, FF and Webkit all rotate
  florian: So shouldn't have too many problems with must
  <dbaron> I'd note the test should test behavior both with 'cursor:
           auto' and with 'cursor: text'
  <dbaron> and the Gecko code only looks at writing mode

  florian: I will note current phrasing does not care if the text is
           vertical due to a specific reason. Not sure we've tested
           all those variants
  astearns: Suggestion is change the wording that it's must when
            writing mode gives you vertical?
  florian: At least writing modes. If we can do any reason it's nice.
           Angled cursor except 0 or 90 deg should be a should
  florian: For 90deg transforms what do people think?
  <fantasai> Gecko doesn't look at transforms
  <fantasai> Neither does Chrome
  gregwhitworth: With transforms we don't change ours. I would
                 struggle to feel that is a high priority for webdevs.
                 For vertical it makes sense. I think that's where I
                 would start and then try and find a common pattern

  florian: So must on writing mode, should on transforms
  fantasai: Yeah
  myles: If no impl I'm not sure it should be a should
  florian: Keep as a may?
  gregwhitworth: May sounds right. Majority of webdevs aren't using
                 text you'd want copy/paste at odd angles. I'd put
                 may. If someone wants that step sure.
  florian: So that's unchanged, make it a must for vertical writing

  astearns: Proposal: Change cursor in vertical writing mode to a must
  astearns: Objections?

  RESOLVED: Change cursor in vertical writing mode to a must

CSS Grid

Define computed value of grid-template-rows/columns
  github: https://github.com/w3c/csswg-drafts/issues/3154#issuecomment-428002686

  fantasai: As part of fix computed values I noticed this. Wanted to
            cross check with the group this seemed reasonable
  fantasai: Current ED says [reads]
  <astearns> https://github.com/w3c/csswg-drafts/commit/63a1d65afa5997a56b210c1cbddccdb2603ecec9
  fantasai: What this means is no distinction in computed value of
            50px and minmax(50px,50px). Functionally same so shouldn't
            be a distinction

  astearns: Any idea about what's implemented?
  fantasai: Didn't check
  fantasai: It's hard to check because getComputedStyle is the used
            value for these prop so can't retrieve computed value
  fantasai: Main check would be animating between. Not sure animation
            is well supported
  fantasai: This would clarify.
  rego: I think animations aren't working on any mpl yet so hard to

  astearns: I like the clarification and seems reasonable to me.
            Haven't thought through implications for animations
  fantasai: What this does is makes it as likely as possible to
            animate between 2 values so that functionally same values
            compute to each other. Everything matches so values that
            mean the same are represented same.
  fantasai: Additional magic we might want for animating, but that's
            issue #3201. Computed value that's best we can do to make
            animation as easy as can be
  astearns: Other comments?
  astearns: Concerns?

  emilio: Can test be written? All this is tricky and to get interop
          tests would be best
  fantasai: Tests would be for animation and this is not being
            animated as far as I know. But we can write tests
  astearns: When someone impl animations for these properties tests
            will need to be written
  <emilio> yeah, fair enough

  astearns: Concerns or objections on taking this edit:

  RESOLVED: Accept this edit:

  <fantasai> https://github.com/w3c/csswg-drafts/issues/3201
  fantasai: Issue #3201 is looking for impl feedback and is related

CSS Align & Grid

Can baseline content-aligned items and baseline self-aligned items
    align together?
  github: https://github.com/w3c/csswg-drafts/issues/3200

  fantasai: We noticed spec was inconsistent on if there is 1 or 2
            first and last baselines. Depends on if elements use
            content or self baseline alignment
  fantasai: We think intent was 1 baseline and that simplifies amount
            of info impl keeps. Want to make sure there aren't
            problems we didn't think of
  fantasai: dholbert and javier think it's right way to go
  <fantasai> Proposal: Align the note and clarify css-align to match
             10.6 in Grid: there is only one baseline that is shared
             across items in an alignment context, and both types of
             baseline alignment use it.
  astearns: Thanks for dholbert and javier for putting their approval
            in issue
  astearns: Other opinions?
  fantasai: Content alignment and self alignment share a baseline
  astearns: Objections to Content alignment and self alignment share a

  RESOLVED: Content alignment and self alignment share a baseline

Selectors 4

:valid-within / :invalid-within pseudo-classes
  github: https://github.com/w3c/csswg-drafts/issues/3072

  fantasai: Proposal to add :valid-within and :invalid-within pseudo
            classes. Seemed reasonable. Want to know if WG thought we
            should add
  astearns: Anyone with a ready opinion?
  fantasai: Not urgent
  astearns: Let's take this as a call for review and add comments in

  heycam: I can add comment to issue. Alternative is you have a pseudo
          class on the form and not just any arbitrary ancestor
  fantasai: I think that's what we do, but I'll check. If it's not we
            can make it work on form
  fantasai: I think that would solve the use case. If it works on
            forms and fieldsets maybe.
  * heycam didn't think about fieldsets; nor did he look at the test
           in the issue
  fantasai: Looks like they're using at a smaller level for a segment
            of a form. Don't know if that solves the use case.
  fantasai: We can continue that conversation in issue
  astearns: Thanks for bringing it to attention. Please comment on the
            issue and we can see if we should take or modify this


Shouldn't column-fill: auto take min-height into account?
  github: https://github.com/w3c/csswg-drafts/issues/3064

  fantasai: If you have column-fill:auto it doesn't take effect if you
            have auto height multicol container. Goal of auto is fill
            first column then move rather then balance. Fixed height
            or page we can fill.
  fantasai: Commenter said if height works, why not fill up to
  fantasai: Reasonable to me. rachelandrew agrees
  florian: Max is reasonable, but why min?
  florian: Why would you stop at a min.
  fantasai: Because at the min you balance.

  dbaron: If you have more than that? You've filled all columns at min
          and you have more, do you go back and do it again?
  rachelandrew: Yes, I think so.
  dbaron: Seems like a very special case. I don't feel it's work
          adding the complexity of redoing it a second way because
          someone suggested it's nice
  myles: Second that
  florian: I'm a big fan of multicol being smarter, but I'm not
           convinced on this

  fantasai: What's happening now is if you have a min-height and you
            say auto it will balance and not fill the column. You have
            all this extra space because you have a min-height. Was
            max-height you don't necessarily have extra space.
  florian: What do you mean you balance?
  astearns: Useful for case where there is not enough content when
            columns balanced to meet min-height. In that case all
            columns don't fill min-height. Change is some columns
            would fill min-height. Too much content, though, is a
            second pass
  rachelandrew: Request makes sense. If it's worth impl is different
                issue. Expectation makes sense.
  florian: I need to re-read. astearns explanation sounded different
  astearns: I might be wrong, that's my take

  dbaron: I get the model, but having trouble imaging the design where
          someone wants this
  fantasai: Can go back to commenter and ask for more info
  rachelandrew: Using min-height we haven't seen much because only
                float was available. Now that we have grid people
                thinking about layout different. Using min-height is
                common and powerful. If there's more content I want to
                use min-height because I don't want it to be smaller
                then viewport.
  rachelandrew: At first glance this looks like a powerful use case
                that would be helpful. But I've been looking for 2.5

  dbaron: Broader then min-height? whenever the height comes from
          something else?
  florian: Original comment was more shouldn't make auto take computed
  fantasai: Question is shouldn't column-fill:auto...okay, yea.
  dbaron: Another example is if you have a multicol whose height is
          stretched should column-fill: auto work? I think not right
  rachelandrew: As an author I want it to work the same everywhere
  rachelandrew: If the height is created by a grid track or a
                min-height...all the many ways to create height. They
                should all look the same
  dbaron: More sympathetic for a general approach then just min-height
  florian: Same here
  rachelandrew: Makes sense
  astearns: rachelandrew do you think there's enough for you to work
            on this?
  rachelandrew: I'll think about it. Maybe discuss at F2F?
  astearns: A whiteboard would be good for this
  rachelandrew: I'll have a think on this
  astearns: Let's add F2F Agenda tag to this

CSS Shadow Parts

confirm browser support
  github: https://github.com/w3c/csswg-drafts/issues/2368#issuecomment-429342082

  astearns: Is TabAtkins on?
  fergal: I'm here, but I was hoping TabAtkins would be.
  astearns: Will you be at F2F?
  fergal: No. I was hoping to have agreement before
  astearns: Summarize agreement?
  fergal: There is a draft spec. Agreement I believe we have is there
          will be no idl for this in initial version. Agreement on
          minimal version that's acceptable. We have naming right for
          everything. There will be a part= and exportparts= and
          syntax is colon separate inner and outer name
  fergal: We postponed multiple parts with an *. Everything with theme
          is postponed.
  fergal: But I don't know if anyone else on the call understands that

  dbaron: Is that written somewhere?
  fergal: It's in the issue. That list is there.
  dbaron: I see 50 or so comments. Is there one to look at?
  fergal: Toward the bottom
  <astearns> 20 days ago
  fergal: From 15 days ago
  <fantasai> fergal,is it this comment?

  Rossen: What's the urgency to agree before TPAC? Especially since
          you said you wanted names agreed to proceed?
  fergal: No particular urgency, just that this has gone for a long
          time. I won't be at TPAC
  Rossen: Is this something TabAtkins can handle in F2F?
  fergal: I think so. I don't know for sure that Ryosuke Niwa is going
          to tpac
  myles: He is
  fergal: If there's no one on the call who was in the discussion it
          has to wait.
  astearns: Summary is still useful
  astearns: We'll let you know fergal what time at TPAC in case you
            can call in
  fergal: Great

CSS Inline

raise/drop keywords for initial-letters
  github: https://github.com/w3c/csswg-drafts/issues/2955

  fantasai: Someone asked for keywords representing drop-caps vs
            raised-caps rather then use numbers
  fantasai: Thought it would be easy to say drop computed to integral
            floor and raise computes to 1. It's a question of if WG
            things work adding
  <fantasai> https://github.com/w3c/csswg-drafts/issues/2955#issuecomment-430277200
  <fantasai> Amelia's follow-up comment on reordering:
  fantasai: Summary of proposal^

  astearns: Reasonable to me.
  astearns: I like keywords rather than opaque numbers
  dauwhe: Reasonable to me too
  astearns: Objections to adding drop and raise as keywords to
            initial-letters property?
  <tantek> +1 to keywords

  RESOLVED: Add drop and raise as keywords to initial-letters property

  fantasai: Follow up is if we can swap order of keyword letter and
  <fantasai> https://github.com/w3c/csswg-drafts/issues/2955#issuecomment-430323643
  astearns: Seems CSS-like
  <tantek> it depends. background does that. border does not.
  <fantasai> “Would it be possible to tweak that syntax so that drop 3
             and raise 2 are valid values? (While still being
             unambiguous for parsing when there are two integers.)”
  fantasai: Comment^

  astearns: tantek responded in IRC [reads]
  astearns: I assume because border it would not be unambiguous
  fantasai: Right. I think the principle is if it's unambiguous you
            can reorder
  <dbaron> We've had properties where swapping ended up being
           confusing like x/y in background-position
  astearns: Any future thoughts on adding to the syntax? Where
            re-ordering might not be unambiguous?
  <tantek> I lean towards usability (forgiveness) up front, thus
           allowing re-ordering.
  <tantek> makes it easier to author off the top of your head
  fantasai: I don't think there's other relevant numbers. Can't think
            of anything. We've had people asking for lots of features
            and none is more numbers
  dauwhe: I can't think of anything either. Lots of wants, but they're
          additional properties.

  astearns: dbaron mentions properties where swapping was confusing
  astearns: Not sure it's a problem here, at least in my mind it's not
            confusing to put keyword where you want
  astearns: Objections to allowing the keywords to be put in either
            position along with the number?
  dbaron: I think some depends on how much we might extend. Initially
          with background-position-x/y we thought it was fine to let
          people put in either order. Then we extended and it was
  fantasai: I think the part that's confusing there is when you have
            one keyword and one non-keyword and there's strict order,
            but not in other cases
  fantasai: This one we're doing opposite. No strict order when
            there's a keyword and it's unambiguous

  <AmeliaBR> Jumping in as the person who suggested it: There's no
             harm with starting out with the more strict syntax & then
             seeing if there's any author confusion/frustration.

  astearns: Leaning a bit more toward dbaron. I'm a little concerned
            we might want to extend values syntax here.
  astearns: If there isn't anything anyone can think of that would
            extend syntax, and I know dauwhe has put a lot of thought
            into this, I'm okay with allowing the swap
  astearns: AmeliaBR said she's okay with a particular order now and
            figure out swap later.
  astearns: dbaron what do you think?
  dbaron: I'm okay with it if we don't see future possibilities to
          expand. But if this becomes 3 value at some point letting
          these two swap might be problematic
  astearns: One way to look is we're committing to extra properties if
            we want to extend. And that's not a bad thing. More
            properties with a name makes it clear what you're doing
            rather then adding a value in a list
  fantasai: I can't think of a reason to add another number to this
  dauwhe: Yeah
  tantek: Tend to agree if a property requires ordering of numbers
          it's confusing. Classic example is how many people get
          latitude and longitude wrong. That's a classically studied
  tantek: We barely get away with TRoBLe
  [argument if that even works]
  tantek: Larger point is list of numbers has been shown to be a
          usability problem
  astearns: Hearing slight concerns but no objects. I'm inclined to
            propose: Order does not matter for the keyword

  RESOLVED: Order does not matter for the keyword in initial-letter


  astearns: Anything in 4 minutes?
  Rossen: Question- status of the proposal for static variables?
  Rossen: I remember dino brought this a few F2F ago and we've been
          getting requests for this. Curious where we stand, is it in
          a spec, can we bring to TPAC perhaps?
  Rossen: Is this happening?
  astearns: I see a draft in a repo
  <astearns> https://drafts.csswg.org/css-env-1/
  Rossen: Awesome. I'll put this on F2F agenda
  myles: We're shipping it
  Rossen: Cool. I'll try to play with it. Thanks.

  astearns: Safe travels everyone. For those not going to TPAC please
            let me know if you want to call in to any of the meeting.
  astearns: Thanks for calling in!

  <rego> Chromium is shipping env() too:
  <myles> Rossen: https://webkit.org/blog/7929/designing-websites-for-iphone-x/
  <myles> Rossen: these are the ones we support:

Received on Wednesday, 17 October 2018 23:49:56 UTC