W3C home > Mailing lists > Public > www-style@w3.org > November 2018

[CSSWG] Minutes Telecon 2018-11-07 [geometry] [css-sizing] [css-shadow-parts] [css-images] [css-grid] [css-break] [selectors]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 7 Nov 2018 21:14:26 -0500
Message-ID: <CADhPm3vH1ZSgK6uVQajk2CbwH9OHa-VLxmde1+ZmadQ7ODi7yQ@mail.gmail.com>
To: www-style@w3.org
=========================================
  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 CR of Geometry API spec

Sizing
------

  - RESOLVED: Add jensimmons as co-editor of Sizing spec
  - jensimmons requested review of her proposal to prevent overflow in
      a container with an explicit aspect ratio (Issue #3268)

Shadow Parts
------------

  - RESOLVED: FPWD for Shadow Parts spec

CSS Images
----------

  - RESOLVED: optimizeQuality behaves the same as smooth (Issue #3283)

CSS Grid
--------

  - RESOLVED: Serialize grid-template-areas as simplified computed
              value for both specified and computed value (Issue #3261)

Fragmentation
-------------

  - RESOLVED: Define that margin collapsing between first or last
              child behaves same as between sibling children (Issue
              #3073)
  - RESOLVED: Republish CR of Break L3.
  - RESOLVED: FPWD of CSS Break L4

Selectors
---------

  - The discussion on :blank (Issue #1967) was reopened to confirm
      that the group no longer saw the compat risk that they
      originally sited when not making the change 3 years before. The
      members on the call generally believed someone needed to commit
      to implementing first or the decision should be reversed however
      there weren't enough members on the call to decide on their path.

Call Times & Agendas
--------------------

  - New tags will be added to github to help indicate which agenda+
      items should happen on an APAC time call and which should only
      happen during a normal timed call.

===== FULL MINUTES BELOW ======

Agenda: https://lists.w3.org/Archives/Public/www-style/2018Nov/0001.html

Present:
  Rossen Atanassov
  Tab Atkins (IRC Only)
  David Baron
  Dave Cramer
  Elika Etemad
  Dael Jackson
  Cameron McCormack
  Manuel Rego Casasnovas
  Florian Rivoal
  Jen Simmons
  Markus Stange
  Alan Stearns
  Eric Willigers

Regrets:
  Rachel Andrew
  Fergal Daly
  Tony Graham
  Chris Harrelson
  Chris Lilley
  Niget Megitt
  Michael Miller
  Fran├žois Remy
  Geoffrey Sneddon
  Lea Verou

Scribe: dael


  Rossen: First I wanted to apologize for the mix up during today's
          conference call. I sent by mistake an agenda with the
          regular call information. Only 4 people read the email and
          showed up. Obviously we intended APAC friendly, sorry about
          the mess up
  Rossen: Are there any additional agenda requests or anything we want
          to change?

Publications & Editors
======================

Selectors 3
-----------

  Rossen: First is recognition and congrats to authors of Selectors 3
          which is now a recommendation.
  Rossen: Thank you for all the hard work and getting spec to rec.
  Rossen: We also have CRs that were published and those deserve
          congrats
  * florian yeah! publications :)

Geometry API
------------

  Rossen: Speaking of CR are any Geometry API authors on the call?
          Chris and Dirk are currently editing
  Rossen: Is there a rule that suggests we can't do CR update without
          editors on?
  florian: I don't think so. If they're in disagreement it's bad form
  Rossen: They're both asking for updated CR
  <TabAtkins> Heh, yeah, don't publish above their objections, but
              fine to approve without them.
  Rossen: Objections to republish CR of Geometry API spec?
  <TabAtkins> No objection.

  RESOLVED: Republish CR of Geometry API spec

Sizing
------

  Rossen: There was interest from jensimmons to start co-editing
          Sizing spec. That's related to intrinsic ratio feature
  Rossen: I'd like to ask WG if there are objections to adding
          jensimmons as co-editor
  <florian> +1
  <astearns> +1

  RESOLVED: Add jensimmons as co-editor of Sizing spec

  * dauwhe_ hooray!
  Rossen: This is awesome.
  <jensimmons> :)

Shadow Parts
------------

  Rossen: Requested as FPWD. We discussed it during TPAC. Since the
          editor addressed all feedback provided
  Rossen: Are there any objections or does anyone want additional time
          to review?

  RESOLVED: FPWD for Shadow Parts spec

  Rossen: Congrats to fergal and others that worked on the draft

CSS Images
==========

image-rendering should support SVG 1.1 values
---------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/3283

  Rossen: Who can represent this?
  ericwilligers: I'm here
  ericwilligers: This was my mistake. I missed that it says optimize
                 was deprecated. Coming out of that we fix
                 optimizeQuality should go to smooth rather than auto.
                 Right now we're throwing away information
  Rossen: Is the value set auto | smooth ?
  <TabAtkins> auto | smooth | pixelated |
              <other-thing-i-forget-not-relevant>
  <TabAtkins> crisp-edges
  <TabAtkins> I'm happy to do "smooth"
  ericwilligers: SVG optimizeQuality will become smooth instead of auto
  ericwilligers: I wanted other thoughts. Current CSS images says
                 optimizeQuality is meaningless
  <TabAtkins> "auto" === "smooth" in practice

  Rossen: Any others on the call that know or care about this?
  dbaron: What is the proposed change?
  Rossen: ericwilligers can you summarize?
  ericwilligers: I'll type it
  <ericwilligers> This property previously accepted the values
                  optimizeSpeed and optimizeQuality. Was These are now
                  deprecated; a user agent must accept them as valid
                  values but must treat them as having the same
                  behavior as pixelated and auto respectively, and
                  authors must not use them. Now These are now
                  deprecated; a user agent must accept them as valid
                  values but must treat them as having the same
                  behavior as pixelated and smooth respectively, and
                  authors mus[CUT]
  <ericwilligers> optimizeQuality will now map to smooth instead of
                  auto.
  <Rossen> property is image-rendering
  ericwilligers: What we're saying is that optimizeSpeed and
                 optimizeQuality are changing
  Rossen: Auto otherwise was sometimes pixelated?
  <TabAtkins> auto is "whatever you want", but in practice it's
              "smooth"
  ericwilligers: Auto was default. Previously images spec said
                 optimizeQuality was equivalent to not setting it at
                 all
  dbaron: Seems reasonable. Unless there's an incompatibility I'm not
          thinking about

  Rossen: Other opinions?
  <TabAtkins> optimizeQualtiy being equal to "auto" is because, at the
              time I wrote those mappings, we just had auto and
              pixelated
  <TabAtkins> I'd map it to "smooth" today

  ericwilligers: No implementor ships smooth. They all ship
                 optimizeQuality. So we should say people can ship
                 smooth
  ericwilligers: Smooth should be cleared for shipping
  Rossen: Well shipping is a UA business decision. But we can say
          value smooth is initial value for
  ericwilligers: Initial value is auto
  Rossen: Auto remains as initial.
  Rossen: optimizeQuality becomes smooth
  Rossen: Proposal: optimizeQuality is replaced by smooth
  ericwilligers: [missed]
  <ericwilligers> optimizeQuality behaves the same as smooth, instead
                  of behaving the same as auto.
  <ericwilligers> (Just like the existing spec text that optimizeSpeed
                  behaves the same as pixelated)

  florian: Parallel we do have a thing to clear for shipping. In some
           cases pre-CR we say a feature is safe to ship. Browsers can
           still decide after that
  <dbaron> yeah, +1 to Florian, I was going to raise the same thing
           once we got the resolutions down
  Rossen: For sure. but this is a technical decision for a particular
          property
  <TabAtkins> "clear for shipping" means that we're approving it for
              shipping despite the spec not being CR. It has nothing
              to do with impls deciding to ship or not
  * rego thinks about https://drafts.csswg.org/css-logical/#issue-3d880eb1
         as an example

  rossen: Objections to optimizeQuality behaves the same as smooth ?

  RESOLVED: optimizeQuality behaves the same as smooth

CSS Grid
========

How to serialize the strings in grid-template-areas?
----------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/3261

  Rossen: TabAtkins is IRC only. fantasai are you on?
  ericwilligers: I can give background
  <TabAtkins> Firefox preserves strings exactly. (as normal for
              strings) Other browsers serialize in simplified form.
  ericwilligers: I wrote a wpt so serialization was similar to blink/
                 edge/safari. FF was acting correctly from spec,
                 though, and the wpt was wrong.
  ericwilligers: Question is what does group believe. I think spec is
                 unclear.
  ericwilligers: We can defer if no one thought it though.

  heycam: If spec doesn't say something else it's natural for strings
          to retain exact values. normalization inside string value
          feels a bit weird to me
  ericwilligers: Other argument is 3 of 4 browsers normalize
  florian: We have a micro language in the strings. It's not
           monolithic. normalization isn't crazy.

  heycam: Did we consider if we want normalization only for computed
          values?
  Rossen: For computed values we're going to do simplified and for
          specified return actual string?
  heycam: Feels more consistent with CSS
  ericwilligers: I had same suggestion
  Rossen: This would require from current impl FF would need to
          change. I guess it's up to you if you're okay to change
  heycam: Not a big deal to change. More about what makes sense
  ericwilligers: If only computed value normalizes all browsers have
                 to change. Everyone except FF changes specified
  heycam: I'm arguing for what makes more sense rather from impl
  Rossen: I don't think anyone is arguing that we want to return
          simplified for specified.
  ericwilligers: That's what 3 browsers do
  Rossen: For both specified and computed?
  ericwilligers: Yes
  Rossen: So minimum implementation cost would be FF to return
          specified
  ericwilligers: That was my original suggestion and original WPT

  Rossen: dbaron or heycam? What do you think?
  dbaron: I think heycam had different opinion. From changing
          implementation I think it's doable either way. For what
          behavior ought to be I think I'm more okay than heycam since
          it seems we're defining a different data type. And I'm okay
          saying this data type normalizes
  heycam: I'm not feeling strongly. Maybe even CSSOM guidelines about
          shortest values we can squint and make this fall under that
          guideline

  Rossen: Objections to serialize grid-template-areas as simplified
          computed value for both specified and computed value?

  RESOLVED: serialize grid-template-areas as simplified computed value
            for both specified and computed value

Selectors 4
===========

Rename :matches() to :is()
--------------------------
  github: https://github.com/w3c/csswg-drafts/issues/3258

  ericwilligers: Is is now free because a different discussion we had
                 at TPAC. Some people thought that better than
                 :matches()
  Rossen: So drop :matches() and replace with :is()
  ericwilligers: Or it's a depreciated alias

  Rossen: Anyone from Safari on the call?
  Rossen: Doesn't sound like. They're ones effected by change in terms
          of implementation. We can call for consensus and if anything
          is raised by webkit folks we can revisit
  florian: We have low attendance. I'm not sure if this is good time
           to rename things.

  Rossen: Are you saying to could have webcompat issues?
  florian: A bit, maybe
  Rossen: Also okay to defer to next week
  florian: I support the change, but doing this w/o impl sounds...I
           don't know
  Rossen: Does anyone on the call feel strongly about resolving now?
          If not we'll postpone
  Rossen: Let's postpone until next week

Fragmentation
=============

What happens to block margins that aren't between block-level boxes?
--------------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/3073

  fantasai: This was the one issue open on fragmentation. dbaron
            suggested we can resolve
  fantasai: What happens to margins...we have defined when breaking
            between siblings, but not if you break before the first
            sibling or after the last.
  fantasai: Typically you don't break there, you break before or after
            parent. You're only allowed to break there if there's a
            gap. If there's just extra space after layout you can break
  fantasai: Proposed is do same as break at siblings. Truncate margins
            if forced, don't if unforced.
  fantasai: Where that shows up is if you are in a multicol and you
            have a bunch of stuff that breaks. You can tell if you
            truncated margin b/c height of multicol will be different
            if margin is there

  Rossen: Behavior sounds reasonable. This is what dbaron is proposing.
  Rossen: Other opinions?
  fantasai: He just wanted a definition. Not sure if he wanted a
            specific one
  <dbaron> yeah, sounds good to me... though not sure that it's what I
           was proposing
  dbaron: I don't think I was proposing something. sgtm

  Rossen: Objections to define that margin collapsing between first or
          last child behaves same as between sibling children ?

  RESOLVED: Define that margin collapsing between first or last child
            behaves same as between sibling children

Publication
-----------

  fantasai: That's in L4, I'll edit into L3 then republish with that
  Rossen: Yes
  florian: L3 is CR
  fantasai: We resolved to publish already. There's just this one
            issue made sense to close it
  Rossen: Objections to republish CR of Break L3 with this change?

  RESOLVED: republish CR of Break L3 with this change

Selectors
=========

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

  Rossen: Discussed between a few folks. I think only heycam is on the
          call of that group
  Rossen: Is this worth discussing now heycam or should we wait?
  heycam: I don't have a strong opinion. I defer to emilio and amelia

Shadow Parts
============

Confirm browser support
-----------------------
  github: https://github.com/w3c/csswg-drafts/issues/2368

  Rossen: This was pushed out of F2F agenda and back into the call
  Rossen: I'm not sure what discussion is needed.
  astearns: May be we didn't take the label off a month ago
  Rossen: It was re-added by fergo after we discussed
  Rossen: He asked for fpwd which we approved. Not sure this is valid
          anymore
  Rossen: I'll remove F2F+ and agenda+

Selectors
=========

Case-sensitive attribute selectors
----------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/2101

  Rossen: Anyone to represent this?
  [silence]

decide on :blank
----------------
  github: https://github.com/w3c/csswg-drafts/issues/1967

  Rossen: Added last by fantasai

  fantasai: Added the flag because annevk wanted to know why we
            decided to change :empty behavior though 3 years ago we
            thought it maybe was not possible
  fantasai: Rather than making edits to spec I decided to re-raise to
            WG

  Rossen: dbaron can you perhaps remember why we did what we did?
  dbaron: Trying to understand this issue
  florian: I think we just thought it was a compat risk we weren't
           willing to take. When we discussed last we thought the
           cases this would impact don't exist much. Had to say if we
           were right

  dbaron: Has someone volunteered to be first impl to change?
  Rossen: I'm not volunteering Edge for this one
  dbaron: I think if group makes changes like this but no one is happy
          to be first impl to ship it won't happen
  Rossen: Agree. Also, if Chrome changed first given their market
          share everything becomes easier.
  Rossen: Curious is Chrome is willing to change first
  Rossen: I know TabAtkins is IRC only but maybe he can answer
  <TabAtkins> ???
  <TabAtkins> Dunno.

  ericwilligers: Defer for a week?
  Rossen: Curious if there's anything we need to do. We have a
          resolution. Are we trying to undo it? Or is anyone going to
          impl it?
  Rossen: Those are the choices on the table
  Rossen: Doesn't look like any impl is stepping up. Not sure if
          there's enough people on call to revert previous resolution
  Rossen: So I agree to ericwilligers to defer to next week.

Call Times & Agendas
====================

  Rossen: There were some multicol, but RachelAndrew couldn't make the
          call.
  Rossen: We've got 13 minutes.

  * fantasai looking for review on
https://lists.w3.org/Archives/Public/www-style/2018Oct/0014.html

  Rossen: One question from me: given low attendance of APAC calls and
          we deferred half agenda I'm questioning if we should
          continue keeping first week as APAC or stick to one regular
          time.
  florian: We've got a few people from China who joined so we should
           give them time to find their way in. It's a valid question
           to ask though
  Rossen: Not intending to cancel next month. Generally surveying this
          audience

  Rossen: We might start adding a different tag for APAC agenda+
  florian: Good idea
  * fantasai proposed Agenda+ APAC last year, for some reason it
             wasn't wanted
  Rossen: We can tally up if we have enough agenda for people who need
          APAC time
  florian: Changing meeting time from week to week doesn't sound good
  Rossen: We'd have a week
  florian: Personally for me APAC time is nicer. but I'll attend the
           middle of the night ones too. Not sure which tag I'd use
  Rossen: You're an exception because you're always on the call. I
          think we have folks that dial in only on APAC so this is for
          them
  heycam: This time of year might be able to find a time acceptable
          for everything. Not as simple for 6 months of the year.
  <dbaron> heycam, that depends on which places in APAC you want to
           accommodate...

  Rossen: Let's end here. astearns and I will walk through calendar
          and figure out if there's an intersection of time that works
          for everyone. And we'll figure out if agenda+ APAC label is
          needed
  fantasai: We have at least one person with a strong preference...2
            members that are APAC only: heycam and birtles
  fantasai: I think agenda+ APAC makes sense so they can flag issues.
            And if we think there's an issue for their radar we can
            flag. And they can swap an agenda+ to an agenda+ APAC
  Rossen: That was my point too. Wanted it easier for someone to say
          I'm APAC only
  florian: Makes sense. I think we should not skip the APAC call even
           if we don't have any topics. We should keep having the
           call. It's significantly more convenient for many people
  fantasai: We should have agenda+ non APAC since some people can't
            make APAC call.
  Rossen: Let's figure out tagging and go from there. Perhaps we can
          add strongly prefer APAC tag that people can add to an
          agenda+. We'll work it offline
  Rossen: Any other topics?

Sizing
======

  <jensimmons> https://github.com/w3c/csswg-drafts/issues/3268
  jensimmons: There's...in thinking about aspect ratios occurred we
              might not need as much complexity in giving authors way
              to define the aspect ratio and let box grow to content
  jensimmons: Wrote an issue [irc link] it would be great for folks to
              look and comment, especially those that understand
              min-height well

Fragmentation
=============

  <fantasai> https://drafts.csswg.org/css-break-4/#break-margins
  fantasai: I drafted fragmentation L4 which is where margin-break was
            going
  fantasai: It's looking for FPWD. If anyone thinks it's good it's one
            property. Or take a week or two to review.
  Rossen: Just this one property?
  fantasai: Yep.
  Rossen: I'm for going forward. I want to hear others.

  Rossen: Anyone want an additional work to go over margin-break
          property added for Break L4?
  florian: Good to me.
  Rossen: Objections to FPWD of CSS Break L4?

  RESOLVED: FPWD of CSS Break L4

  Rossen: yay!

  <fantasai> https://lists.w3.org/Archives/Public/www-style/2018Oct/0014.html
  fantasai: Here's margin-trim status^
  fantasai: Rough draft in box 3, I wanted WG for review. Once that's
            concluded update the WD.
  fantasai: Don't need to resolve today.
  fantasai: Or we can.
  Rossen: Call to action for people to read. Then we can resolve

  Rossen: Anything else?
  Rossen: Thanks for calling and we'll talk next week
Received on Thursday, 8 November 2018 02:15:23 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 8 November 2018 02:15:23 UTC