[CSSWG] Minutes Telecon 2020-07-15 [mediaqueries-4] [mediaqueries-5] [css-pseudo-4] [css-grid] [css-lists-3] [css-inline-3]

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


  - There will be 4 4-hour F2F timeslots the week of July 27th.
      Details are on the private list.
  - Please begin to tag any F2F agenda items on GitHub. If you have a
      preferred day or timeslot use the milestone to indicate that.

Media Queries 4 & 5

  - A joint session with the media working group was held to discuss
      the video media queries. Though they heard the CSSWG's concerns
      about the solution they still believe that the best way forward
      is the proposed media queries. Discussion will return to github
      in issue #5044.
  - RESOLVED: Mark Update media feature at-risk in MQ4
  - RESOLVED: Update CR of MQ4
  - RESOLVED: Republish WD of MQ5

Pending Pull Requests

  - Editors are reminded to stay on top of PRs as old PRs have merge
      problems. (Issue #5314)

CSS Pseudo Elements

  - Most of the group agreed the the proposal for ::first-letter to
      include space separators (Issue #5154) however there was an
      objection based on a lack of real world examples. Examples will
      be gathered and then discussion will continue.

CSS Grid

  - RESOLVED: grid-template-areas should not accept empty strings
              (Issue #5110: Should grid-template-areas accept empty
  - RESOLVED: Accept edits to spec for explicit grid (Commit with
              (Issue #4914: Does grid-template-areas really expand the
              explicit grid?)

CSS Lists & Pseudo Elements

  - RESOLVED: Add ::marker { text-transform: none; } to UA stylesheet,
              at least for now (Issue #4206: Does text-transform
              inherit to ::marker?)
  - RESOLVED: text-transform applies to ::marker (Issue #4206)

CSS Inline

  - There wasn't enough time left on the call to reach a resolution
      for issue #5120 (initial-letters-wrap: first, whitespace
      collapse needs defining) but everyone who spoke was in favor of
      discarding the space when there's a drop-cap and keeping with
      raised-cap. Unless there's objections raised in github a
      resolution will be called for next week.


Agenda: https://lists.w3.org/Archives/Public/www-style/2020Jul/0009.html

  Rachel Andrew
  Rossen Atanassov
  Tab Atkins
  David Baron
  Christian Biesinger
  Mike Bremford
  Oriol Brufau
  Tantek Çelik
  Hui Jing Chen
  Emilio Cobos Álvarez
  Dave Cramer
  Elika Etemad
  Simon Fraser
  Megan Gardner
  Daniel Holbert
  Dael Jackson
  Sanket Joshi
  Brian Kardell
  Brad Kemper
  Daniel Libby
  Chris Lilley
  Peter Linss
  Alison Maher
  Stanton Marcum
  Devin Rousso
  Jen Simmons
  Miriam Suzanne
  Greg Whitworth

  Greta Krafsig
  François REMY

Scribe: dael

  Rossen: It is 9:02
  Rossen: I think we have quorum. Hello!
  Rossen: Any last minute agenda items or changes?
  florian: I suggest a de-briefing of media WG meeting?
  Rossen: Agree. We'll timebox and mingle with the MQ4 topic
  Rossen: Anything else?


  Rossen: One housekeeping item
  Rossen: Proposed dates for next virtual F2F as well as help we want
          to request for topics you want to see or participate in a
          time zone which is convenient for you
  Rossen: We have proposed 2 timeslot A and 2 timeslot B meetings week
          of July 27th
  Rossen: We ask if you open any GH for agenda+ F2F please do add
          topics. If you have a time slot please set the milestone to
          be timeslot a or timeslot b for a date.
  Rossen: As an example I've set milestone to be July 31st Slot A.
  Rossen: It is one preference only so if there is overlap we'll
          discuss with participants
  Rossen: I'll clear this issue but that's the request.
  Rossen: Any questions?

Media Queries 4 & 5

Recap of MQ5 joint meeting with mediawg

  Rossen: Since we are talking MQ it would be good to take a couple
          minutes to recap the Media WG joint meeting. florian can you
          do that?
  florian: To avoid confusion joint meeting was about a MQ5 item
  florian: My sense from our last discussion is we agreed on use case
           and accepted a few video queries but looking closer group
           was less convinced this was right way to solve
  florian: From csswg there was limited attendance. I presented our
           concerns but Media WG thinks this is still right approach.
           We're back to GH to add or do further convincing
  Rossen: Thank you. I would urge those interested in continuing to
          discuss on GH.
  florian: Because we have concerns and no conclusion I added issues
           inline in spec in case anyone wanted to read.
  Rossen: Makes sense. I got impression Media WG thought it was ready
          to go.

Request for an updated CR for MQ4

  Open issues (none as of now):
  Disposition of comments:
  Changes Section: https://drafts.csswg.org/mediaqueries-4/#changes-2017-9
  Calls for wide/horizontal review:
    - > 1 month ago:
     -> In preparation of the previous CR:

  florian: We have no open issues.
  florian: We have DoC and change section. Posted for horizontal
           review 49 or 50 days ago
  florian: Tests for everything new since last CR. Not a complete test
           suite, but tests for delta
  florian: List of changes is short, deprecated speech, added notes,
           fixed a grammar bug, moved a definition to Values 4, added
           some terms, dropped another value
  florian: I suggest we mark Update media feature as at-risk as there
           is no impl

  chris: I was going to ask about how far from PR
  florian: For everything except Update I think we have impl. Since
           test suite isn't complete not sure.
  chris: Untested features?
  florian: Yes, I think so. Every diff from last CR is tested but bulk
           was not. Far from complete.
  florian: I plan to write more but I don't think should block CR
  chris: No, not trying to block. Just wondering next step
  Rossen: Question on tests, you mean in general for MQ4 or Update
  florian: In general. Some tests that are not exhaustive. All changes
           from last CR have tests

  Rossen: One at a time. Any impl with intent to impl Update media
          feature and thinks we shouldn't mark at-risk?
  Rossen: Obj to mark Update media feature at-risk?

  RESOLVED: Mark Update media feature at-risk in MQ4

  Rossen: Objections to update CR of MQ4?

  RESOLVED: Update CR of MQ4

Media Queries 5 Publication

  florian: Thanks. Follow-up.
  florian: MQ5 was a delta spec. I have folded L4 in. Do we want a WD
           of that?
  <astearns> yes
  <fantasai> yes
  Rossen: I believe we resolved to republish 2 calls ago?
  florian: I think a little more. There is a recent publication but it
           doesn't include L4

  chris: Would that make L5 the current work?
  florian: Possibly?
  fantasai: We never figured out policy for unleveled URLs. We often
            switch at CR. I think that needs to be a general
            conversation. We should publish updated WD of L5
  Rossen: Absolutely. I believe previous resolution stands
  fantasai: New resolution
  florian: My memory is we published after last resolution.
  florian: I don't know if folding in L4 falls into editorial changes.
           If we're okay let's resolve
  fantasai: We're spending more time discussing if we need a
            resolution than if we just made one
  Rossen: Obj on republish WD of MQ 5?

  RESOLVED: Republish WD of MQ 5

Pending pull requests
  github: https://github.com/w3c/csswg-drafts/issues/5314

  chris: Reminder, lots of PRs that are old. As long as they languish
         the older they get
  chris: You can reject if you don't like, but please keep on top of it
  chris: Quick reminder

  plinss: We have 5 additional branches in main repo with 5 PRs. 4
          have PRs open with 1-3 years old. Please review and handle.
          Then please don't branch from main.
  florian: Can we kill the one without a PR?
  plinss: It's from TabAtkins
  TabAtkins: Okay, will take care of it

CSS Pseudo Elements

::first-letter should include space separators
  github: https://github.com/w3c/csswg-drafts/issues/5154

  fantasai: Issue about how not including spaces but only punctuation.
  fantasai: Number of punctuation related patterns with punctuation
            space letter.
  <fantasai> https://github.com/w3c/csswg-drafts/issues/5154#issuecomment-655940861
  fantasai: Proposal is update as description ^ to include intervening
            whitespace in ::first-letter
  Rossen: Feedback or objections?

  faceless2: If not followed by letter does that go with it?
  fantasai: Currently ::first-letter is a letter or digit. If you have
            a paragraph with only punctuation there is no

  tantek: I accept the situation exists in prose. What I'm not seeing
          in issue is documentation or example like print example of
          ::first-letter with punctuation and space and letter all as
          first letter
  tantek: Open to keeping issue open but needs more data to accept
          because otherwise might make worse
  tantek: Inclusion of punctuation in ::first-letter at all we had
          numerous examples in multiple languages. Since I'm not
          seeing that I would reject
  fantasai: Do you have those examples?
  tantek: Yeah, need to check my bookshelf
  fantasai: Typical case is if " in French you have to include space.
            Usually not full sized.
  tantek: My point is a French first letter with a " and a letter.
          Need to see that example to move forward.
  <astearns> there are two references in the initial comment
  myIes: I think I disagree with tantek. If we're doing ::first-letter
         that punch through punctuation this has to happen if we
         support French
  florian: Question is valid, does French do that

  fantasai: This was raised because issue filed against browsers and
            browsers wanted spec update
  <fantasai> https://bugs.chromium.org/p/chromium/issues/detail?id=638267
  Rossen: And there are bugs linked in issue
  tantek: At time we found print examples in magazines so it was not
          hard to find. If that's not true in French I'd push back.
          Someone more familiar with French I'd ask have they ever
          seen it in French and share an example rather then rely on
  Rossen: French only?
  tantek: I think Norwegian is also provided in issue
  tantek: Either is sufficient evidence.
  tantek: When talking details I'd rather based on examples and not
          completion-ism reasoning.

  dauwhe: We use spacing like this all the time " and than ' would be
          separated by a space. If that's all ::first-letter we'd want
          it all selected. We use spaces between punctuation all the
  tantek: That's different than proposal.
  fantasai: That's included. All punctuation before the first letter
            is included as well as any intervening space. So this
            would solve dauwhe use case
  tantek: Have you seen it in print?
  fantasai: We have it in English
  dauwhe: I can't remember if I've seen that at start of chapter with
          initial-letter. Somewhere that I'd need a ::first-letter
          selector to capture that combo of glyphs

  tantek: Anything adding complexity to platform has a cost. It's
          reasonable to request some examples produces, esp with other
  astearns: True there is a cost, but this is a case without interop.
            We can spec what is requested and have engines that don't
            do it match those that do and we gain interop
  Rossen: And this is Mozilla right that would need to add to be
  tantek: I couldn't determine from issue which engines did what
  astearns: We know some do and some don't. Seems reasonable to spec
            this knowing there are strings that have this behavior and
            people like to apply ::first-letter to things. I don't
            know it's necessary to come up with print example to spec
            this and have engines match
  Rossen: I think 2nd paragraph in opening issue comment. Safari
          includes spaces, Chrome doesn't. There's a 10 year old bug
          from Mozilla describing this.
  Rossen: Safari is ahead and Mozilla and Blink need to catch up
  Rossen: There is precedent for interop
  plinss: If there isn't interop there is fail in testing or unclarity
          in spec. Need to fix either way
  tantek: I'd worry about compat if there's a 10 year old bug
  fantasai: Safari shipped with this. Not sure why worried about compat
  tantek: Safari might have compat problem
  fantasai: Doubt it
  florian: Especially since people are filing bugs against Chrome and

  fantasai: We've spent a long time on this. I'd rather we not spend
            more time. tantek will you block and want us to go look
            for more because the lack of interop and old bugs is not
  tantek: Prefer to request examples and leave open
  florian: I would agree with tantek if there had been interop and we
           were proposing to change, but there isn't interop and we're
           trying to align, so I don't agree
  Rossen: Sounds like tantek you object on resolving based on lack of
  Rossen: Let's record that objection. It will go into the issue.
  Rossen: I'm hoping dauwhe or Richard can get an example and we can
          resolve next week.
  Rossen: Either way we'll come back to discuss this around interop.
  <tantek> That's fine, didn't intend so much time on this issue
  Rossen: tantek do you agree with this?
  tantek: Yes, reasonable. Thank you

CSS Grid

Should grid-template-areas accept empty strings?
  github: https://github.com/w3c/csswg-drafts/issues/5110

  TabAtkins: Oriol raised issue that technically spec does not
             disallow empty strings in grid-template-areas
  TabAtkins: No reason to do it either way but no one wants to put
             empty string in. Both Chrome and Edge consider it to be
  TabAtkins: As long as no objections we're going to say we require
             one cell to be expressed or it's invalid
  Rossen: Other opinions?

  plinss: Requires at least one cell with a name?
  TabAtkins: A cell. It can be empty.
  plinss: If you define an area with empty string for name what does
          it mean?
  TabAtkins: It's got a track but no alignment
  plinss: Same as dot?
  florian: No, empty string would be parse error
  TabAtkins: We don't give strings per cell name. String is name of
             all cells in row
  plinss: Right.

  oriol: Difference between empty string and string with dot is it
         forces it to have specific number of column and rows. If
         allow empty strings grid would force 5 rows and no column
  oriol: Strings with dots you could have 1 column. That's difference
  TabAtkins: Given no use case for rows with 0 columns and it doesn't
             go the other way around I'm inclined to call it invalid
             which is matching Chrome and Edge
  florian: Doesn't seem to be a use case to allow. It's a weird error
           and we can align, the market share of browsers who do this
           already prove it's possible
  Rossen: I can see it spit out by preprocessors or tools. Having spec
          is good

  Rossen: I don't hear objections or pushback.
  Rossen: Other questions or reasons why we shouldn't?
  dholbert: Sounds fine to me/Mozilla

  RESOLVED: grid-template-areas should not accept empty strings

Does grid-template-areas really expand the explicit grid?
  github: https://github.com/w3c/csswg-drafts/issues/4914

  <fantasai> https://github.com/w3c/csswg-drafts/issues/4914#issuecomment-609914410
  TabAtkins: Issue here is grid-template-rows/columns/areas don't have
             to agree number of rows or columns expressing. You can
             have a template with 5 rows and only put 1.
  TabAtkins: Question is what defines explicit grid. Explicit rows and
  TabAtkins: Browsers agree on behavior but it's not well specified.
             They are part of explicit grid, can detect by span to -1
             line. Will fill space of grid-template-area. Sized as if
             implicit tracks from grid-auto-rows properties.
  TabAtkins: Reasonable, want to canonicalize in spec.
  TabAtkins: We checked in edits and added tests. If there's
             objections we can revert. Otherwise current spec has
             intentions. Explicit grid is the larger option and if
             it's more than rows and columns it's sized by grid-auto
  Rossen: Thoughts or objections?

  RESOLVED: Accept edits to spec for explicit grid

CSS Lists & Pseudo Elements

Does text-transform inherit to ::marker?
  github: https://github.com/w3c/csswg-drafts/issues/4206

  fantasai: One browser blocks inheritance of list marker
  fantasai: Blocking text-transform makes sense. ::marker means UA
            should set text-transform:none and author can set to
            inherit. But default it should not inherit.
  <florian> +1
  fantasai: I want to go through text-transform before other properties
  <TabAtkins> +1 to text-transform

  oriol: Not sure I agree. text-transform applies to text like color.
         If you set color it's inherit, why should text-transform be
         different? For ::before and ::after it inherits. If you set
         something case sensitive you would close it. Why should
         marker be different?
  florian: In general we don't know if text is case sensitive but we
           do know markers are
  TabAtkins: Agree with fantasai and florian where we have 2 pairs of
             markers that are explicitly case sensitive. Having
             text-transform for in is likely unintentional. Having it
             automatically it may make it confusing to read. Should be
             allowed to set
  fantasai: Can also be semantic where nested lists have some upper
            and some lower and then they're referenced in other parts
            of text. If you transform the case it breaks the link. The
            default would be safer if we don't have this inherit by

  dbaron: I think there's some question if the thing is markers or
          counter references
  dbaron: I think the thing we're talking about is references to
          counters which are lower-roman, upper-roman. If we were to
          have a feature for counter references then the thing we want
          to not be transformed is the counter reference.
  dbaron: If rule in css is the counter references are not text
          transformed there's no way for author to say they really do
  fantasai: Interesting point. Advocate a separate issue for that. In
            meantime set text-transform to none so we get markers as
            defined today
  <florian> +1

  dauwhe: Author PoV I found it surprising that I do something to list
          item and changes list numbering
  oriol: Should we allow it to list of properties allowed in markers
         so authors can set to inherit?
  fantasai: Yes, that's part of proposal

  Rossen: Nearing a resolution. Other questions or PoV?
  Rossen: If not I'll ask if there are objections.
  oriol: Should we discuss other properties in issue? Text-indent
         seems more obvious
  fantasai: Let's not all properties together. Let's do one and move
            to next.
  TabAtkins: Unless you think they're linked.
  Rossen: Do you believe they should be linked?
  oriol: Independent

  Rossen: Objections?
  fantasai: text-indent is #4568
  florian: You mean text-indent?
  Rossen: Where should the resolution go?
  fantasai: Here.

  dbaron: I think at some point there was summary of existing impl
  dbaron: Trying to understand that state
  fantasai: Top of issue
  dbaron: Claim Gecko blocks inheritence of text-transform. Do we
          support text-transform:inherit?
  oriol: In Gecko markers if you use content:normal it uses
         nsBulletFrame which doesn't support text-transform. Content
         to something different than normal it's a different box and
         it inherits like Chromium. If you set it to something else it
         will also do that
  dbaron: I think implication is trying to resolve on something done
          by some impl. I don't think that's the case
  fantasai: I think there's some spec in what's impl. Effect on
            existing pages...features where we don't have the behavior
            are new and not much used. Discussion in the issue but I
            concluded we should block text-transform on markers
  dbaron: Rather than say it doesn't apply to counter references
  fantasai: Until that's defined I think it's important to not
            establish a precedence in the majority of cases with
  dbaron: Okay
  <TabAtkins> I could see a list style that's like "First: ",
              "Second: ", etc., which is fine to text-transform and
              probably *expected* to respond to that. Maybe this does
              need to go into the @counter-style definition, like
              dbaron's earlier comments suggested...
  <dbaron> (I think I probably prefer tying this to counters than to
           markers, but I don't object.)
  <fantasai> yeah, I could live with that... but I'm not sure how
             we're going to make that work yet, and until we do I
             think this is a good move

  Rossen: Going back, any new objections from this conversation?

  RESOLVED: Add ::marker { text-transform: none; } to UA stylesheet,
            at least for now

  Rossen: Next set of properties in the issue?
  <fantasai> https://github.com/w3c/csswg-drafts/issues/4568
  fantasai: Separate issue open which is #4568 which discusses all
  <fantasai> https://github.com/w3c/csswg-drafts/issues/4568#issuecomment-562734422
  fantasai: I suggest we continue there.
  fantasai: My take is we need to define what is inherited through
            ::marker vs properties that are for paragraph or line box.
            Properties for block containers shouldn't be for ::marker.
            Once we define the interesting question is if word-spacing
            or letter-spacing is also reset.
  fantasai: Not sure we should take it now.

  florian: Given resolution we took I think we need to say
           text-transform applies to ::marker
  fantasai: Sure
  florian: We said we'd put the property in the UA stylesheet without
           saying to property applies
  fantasai: Does it apply to marker or text. Need clarity
  florian: That is applies somehow needs to be resolved
  fantasai: Sure
  Rossen: What's the proposal?
  florian: text-transform applies to ::marker
  Rossen: Thoughts or objections?

  RESOLVED: text-transform applies to ::marker

  Rossen: fantasai you asked if we should open #4568 about which
          properties reset?
  fantasai: I think today we should move on

CSS Inline

initial-letters-wrap: first, whitespace collapse needs defining
  github: https://github.com/w3c/csswg-drafts/issues/5120

  fantasai: Appears that current suggestion is raised-caps should have
            whitespace between them and first line but drop-caps
            should not
  fantasai: Question is do we make edits to make that happen
  Rossen: Edits to make that happen in text? Or where?
  fantasai: Changes to initial-letters spec. If you have a raised
            initial then whatever whitepsace collapsing which would
            take effect should happen. Word, raised-initial letter
            should have all spaces
  <tantek> yeah with dropcaps that space after the initial letter
           would look like an errant text-indent
  fantasai: drop-caps if you have that behavior it would be weird so
            we should collapse the white-space.

  <dbaron> This seems related to 'initial-letter-wrap: first'.
  <dbaron> There's an example at

  fantasai: dauwhe do you want to explain more?
  dauwhe: It's a weird case. When the initial-letter is a word.
          Example in English it's an A or an I that starts a sentence.
          We need to retain the space so reader is not confused. Some
          examples in spec I think. Sunk drop-cap gives you space
          automatically. Raised-cap you don't so need to retain the
  dauwhe: What fantasai proposes seems reasonable

  tantek: Proposal the space when it's drop-cap?
  fantasai: Discard space when drop-cap. Keep with raised-cap
  tantek: Yeah. That's what I'm seeing in print
  tantek: Print examples conform to that
  <tantek> FWIW the print example I found was on p.80 of How To Spec
           Type by Alex White

  dbaron: Reasonable but makes me wonder if initial-letter-wrap should
          default to first instead of none
  fantasai: Does that because people didn't want to implement first
  <fantasai> (so we couldn't make it the default)

  Rossen: We're overtime and people are dropping
  Rossen: Ready to resolve or table?
  Rossen: We're losing people. Let's not resolve now and take this
          first next week.

  Rossen: Please add agenda+F2F issues and mark with dates for time
  Rossen: Thank you for sticking through the end. We'll chat next week.

Received on Wednesday, 15 July 2020 23:13:04 UTC