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

[CSSWG] Minutes Telecon 2018-12-05 [css-break] [fxtf] [css-box] [css-text] [css-syntax] [selectors-4] [css-text-decor-4] [css-alignment]

From: Dael Jackson <daelcss@gmail.com>
Date: Thu, 6 Dec 2018 19:32:05 -0500
Message-ID: <CADhPm3v0WjiafS54qDLDw9wRDpcuQkzWEJyUf_wz+SXmojsW1g@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.
=========================================


CSS Break
---------

  - RESOLVED: FPWD for CSS Break L4

FXTF Specs move to CSSWG
------------------------

  - RESOLVED: Publish Filter Effects under CSSWG
  - RESOLVED: Publish Web Animations under CSSWG
  - RESOLVED: Publish Composition and Blending under CSSWG
  - RESOLVED: Publish Fill and Stroke under CSSWG
  - RESOLVED: Publish Masking under CSSWG
  - RESOLVED: Publish Motion Path under CSSWG
  - RESOLVED: Publish Geometry Interfaces under CSSWG

CSS Box 3
---------

  - RESOLVED: Republish CSS Box 3 as a WD

CSS Text
--------

  - RESOLVED: Close issue #698: (Cursive shaping breaks needs better
              scoping) no shaping across positive margins, borders,
              padding
  - RESOLVED: Accept changes in
https://github.com/w3c/csswg-drafts/commit/caf1e4747f2bd906bb9f671af8c463b28b97deda
  - RESOLVED: Publish a new WD of CSS Text L3
  - The group will target 19 December to request a CR transition.
      Anyone wishing to review or add comments should do so in advance.

CSS Syntax
----------

  - RESOLVED: Add the additional codepoint filtering

Selectors 4
-----------

  - RESOLVED: Defer this issue (Issue #2284: Why \"Pseudo-elements
              cannot be represented by the matches-any
              pseudo-class\"?) to L5

Text Decor 4
------------

  - RESOLVED: Text decoration is considered ink overflow and not
              layout (Issue #3272)

CSS Alignment
-------------

  - RESOLVED: Publish CSS Box Align L3 WD

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

Agenda: https://lists.w3.org/Archives/Public/www-style/2018Dec/0005.html

Present:
  Rossen Atanassov
  Tab Atkins
  David Baron (IRC Only)
  Dave Cramer
  Elika Etemad
  Dael Jackson
  Peter Linss
  Alan Stearns
  Eric Willigers
  Jeff Xu

Regrets:
  Rachel Andrew
  Angelo Cano
  Emilio Cobos Álvarez
  Tony Graham
  Chris Harrelson
  Chris Lilley
  Myles Maxfield
  Nigel Megitt
  Michael Miller
  François Remy
  Florian Rivoal
  Jen Simmons
  Lea Verou
  Sean Voisen
  Greg Whitworth

Scribe: dael

  Rossen: It's 3 minutes past. We'll try to make progress on as many
          issues as we can.
  Rossen: As usual, any additional agenda items or changes to make?

CSS Break
=========

Request for a FPWD for CSS Break
--------------------------------
  <fantasai> https://drafts.csswg.org/css-break-4/#changes-level-4

  Rossen: Fragmentation L4. Only 2 changes from L3- margin break
          property and the always and all values added
  Rossen: With that I'll call for opinions or objections
  Rossen: Objections to FPWD for CSS Break L4?

  RESOLVED: FPWD for CSS Break L4

FXTF Specs move to CSSWG
========================

  Rossen: We have already recorded resolutions to take over and get
          this under CSSWG. I wanted to know if anyone had reasons to
          object to this.
  Rossen: If no, we'll resolve on each
  <TabAtkins> +1 to republishing all
  <astearns> also +1 to republishing everything

  Rossen: Filter Effects
  Rossen: Obj?

  RESOLVED: Publish Filter Effects under CSSWG

  Rossen: Web animations L1

  RESOLVED: Publish Web Animations under CSSWG

  Rossen: Composition and Blending. Objections?

  RESOLVED: Publish Composition and Blending under CSSWG

  Rossen: Fill and stroke. Objections?

  RESOLVED: Publish Fill and Stroke under CSSWG

  Rossen: Masking. Objections?

  RESOLVED: Publish Masking under CSSWG

  Rossen: Motion Path. Objections?

  RESOLVED: Publish Motion Path under CSSWG

  Rossen: Geometry Interfaces. Objections?

  RESOLVED: Publish Geometry Interfaces under CSSWG

CSS Box 3
=========

  <fantasai> https://drafts.csswg.org/css-box-3/#margin-trim
  fantasai: astearns points out we should publish ^ as a WD to get
            margin trim published
  Rossen: WD?

  RESOLVED: Republish CSS Box 3 as a WD

CSS Text
========

Cursive shaping breaks needs better scoping
-------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/698#issuecomment-437944436

  Rossen: Reopened a couple weeks ago.
  fantasai: This was an issue where Richard asked us to clarify or
            change where we have breaks across element boundaries or
            not. I think he was asking for it to not break when
            there's a border. There's a span mid-word. Current spec
            requires if you have border, margin, or padding we don't
            shape across that boundary
  fantasai: Richard asked to have that changed. Asked Jonathan for his
            opinion and it was that Firefox does that is a problem.
            We're keeping current set of rules is that latest on the
            issue
  fantasai: Wanted to ask if there's anything to add. If not I'll
            close editorial for clarifications, but no change
  Rossen: I support the no change. Change would be nontrivial and I'm
          not sure how it would impact web compat.
  Rossen: Objections?

  RESOLVED: Close issue #698: no shaping across positive margins,
            borders, padding

Clarify what ligatures are optional
-----------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/2644#issuecomment-432774658

  <fantasai> https://github.com/w3c/csswg-drafts/issues/2644#issuecomment-422075536
  fantasai: This one I committed some changes to CSS Text to define
            what myles_ suggested is correct. myles_ posted ^
  <fantasai> * rlig is required, no other ligatures are required
  <fantasai> * text engines have heuristics for broken stuff, spec
             shouldn't override
  fantasai: Committed that.
  fantasai: There was discussion about needing update to font
  <fantasai> https://github.com/w3c/csswg-drafts/commit/caf1e4747f2bd906bb9f671af8c463b28b97deda
  fantasai: Commit for CSS 3 Text ^

  <fantasai> https://github.com/w3c/csswg-drafts/issues/2644#issuecomment-437085666
  fantasai: Comments about changing fonts to clarify interactions.
            Wanted WG to discuss. Changes are largely that the section
            that defines how font features interact. There's a section
            that says [reads]
  fantasai: Should say optional ligatures as is in spec. Then clarify
            that if you set letter spacing later it disables all
            ligatures, not just common
  fantasai: Also a suggestion there should be step 6 that says if the
            engine does stuff under the hood it might take precedence.
  fantasai: I don't know about that, it's beyond my knowledge.
  fantasai: Clarification to which ligatures are disabled should go in.

  Rossen: What's in the PR of the 6?
  fantasai: Changes made to text are committed. Basically clarifies
            optional ligature. I didn't think that text should spec
            what that means.
  fantasai: Making sure text doesn't conflict with font and says go
            look for exact details. I think that's correct.
  * fantasai reads
https://github.com/w3c/csswg-drafts/commit/caf1e4747f2bd906bb9f671af8c463b28b97deda
  fantasai: I'm guessing no issues with this one. Need to figure out
            font spec and if there should be a step 6
  <fantasai> https://github.com/w3c/csswg-drafts/issues/2644#issuecomment-437085666
  fantasai: If you look at ^ there's a list of precedence of parts of
            CSS that inject font feature settings.
  fantasai: Proposal to make changes to that list

  fantasai: Wanted to bring that up to see if we should make those
            changes to font. If so it should be fonts 3 as well as 4
  Rossen: 3? Isn't that too late?
  fantasai: Clarification to what's happening.

  Rossen: For CSS Text L3 would any additional changes be required?
  Rossen: I know we need to take to font 3 and/or 4. What about Text 3?
  fantasai: Nothing more. The commit went in.
  Rossen: To close CSS Text discussion, are there any objections to
          proposed changes in the commit
https://github.com/w3c/csswg-drafts/commit/caf1e4747f2bd906bb9f671af8c463b28b97deda
?
  <dauwhe> +1

  RESOLVED: Accept changes in
https://github.com/w3c/csswg-drafts/commit/caf1e4747f2bd906bb9f671af8c463b28b97deda

Publish an updated WD of css-text-3
-----------------------------------

  Rossen: Anything else before we republish?
  <fantasai> https://github.com/w3c/csswg-drafts/issues/337#issuecomment-444316214
  fantasai: There's another issue florian and I tried to figure out.
            Ran into a problem with emoji. Line break transformation
            is dependent on east Asian width. Emoji are very
            inconsistent in east Asian width so line break is
            different depending on emoji.
  fantasai: florian figured out unicode we can use. Pushed that in. If
            people are interested they may want to look more deeply.
  fantasai: Might want to review, but if people need more time we can
            give it.
  Rossen: florian isn't on, but I'm assuming you support his point.
  fantasai: Yeah
  Rossen: I would rather have koji and others look
  fantasai: Yeah
  Rossen: We can republish again
  Rossen: Objections to republish?

  RESOLVED: Publish a new WD of CSS Text L3

  fantasai: That brings us to all issues closed and waiting for review
            from commenters
  fantasai: I wanted to set a target for transition to CR.
  Rossen: Awesome
  fantasai: When I post that we published, what date should we set as
            deadline for review?
  Rossen: Given holidays are upon us I expect less people will review.
          What would be normal time frame. I think a couple weeks. Do
          we have actual target dates that we set before asking for
          transition?
  Rossen: I don't recall us setting a precedent for 2 weeks.
  fantasai: Usually post an announcement saying we plan on going to CR
            soon, please send comments.  Usually a case of what day do
            we want to say
  Rossen: Last call of this year is likely 19th. Is that a good target?
  fantasai: Enough for me, don't know anyone else
  Rossen: Let's try. If there's pushback we extend
  Rossen: 19th is deadline for additional comments or issues before we
          transition
  fantasai: I'll post an announcement

CSS Syntax
==========

The tokenizer input should probably be a stream of scalar values,
    not codepoints
-----------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/3307

  TabAtkins: This is a small change, no change for Firefox and minor
             for others. Turns out when I wrote syntax I didn't know
             scalar vs codepoints distinction
  TabAtkins: When I wrote I said codepoints. Every algorithm produces
             only scalar except for when you assign a DOMstring. All
             other methods like decoding or escaping produce only
             scalar values.
  TabAtkins: Seems like I don't want non-scalar values; would be more
             consistent to block the codepoints in all places.
  TabAtkins: I propose we add a new step to codepoint filtering that
             says they are replaced and all entry points work on pure
             scalar
  TabAtkins: Firefox does this already, Chrome does allow surrogate
             codepoints in because we're using DOMstrings
  TabAtkins: Simplifies model.
  TabAtkins: Yea or Nay, trivial change on my part
  Rossen: I'm assuming Firefox people will be okay. They're mostly
          out, but I'd be surprised if they oppose. Chrome is in
          favor. I don't think we have Apple
  Rossen: Objections to the proposed change?
  <plinss> +1

  RESOLVED: Add the additional codepoint filtering

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

Why \"Pseudo-elements cannot be represented by the matches-any
    pseudo-class\"?
--------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/2284

  fantasai: I wanted to ask if this is something we should try and
            define or close as no change
  TabAtkins: Valid.
  TabAtkins: I know that safari allows pseudo elements, but it doesn't
             make sense and I don't know why
  <TabAtkins> .foo:matches(::before):hover
  TabAtkins: This selector ^ bothers me.
  TabAtkins: Unclear if it means before when foo is hovered or when
             foo.before is hovered.

  fantasai: If we're going to define we have to define if a selector
            ends in a pseudo element and has same meaning as if you
            placed element outside of matches.
  <TabAtkins> .foo:matches(::before).bar is invalid, then
  <TabAtkins> .foo:matches(::before, .baz).bar is invalid, too
  fantasai: That's invalid, right.
  TabAtkins: Reasonable sort of thing to define on
  TabAtkins: It's weird and I don't like it, but if it's what we want
             I'm okay

  ericwilligers: What's the need for this?
  <TabAtkins> .foo:matches(::before, ::after)
  TabAtkins: Safari does it for selectors like ^
  TabAtkins: You want to assign a style to multiple pseudo elements.
             Can't do that with matches right now. That's annoying, I
             agree
  TabAtkins: Reasonable thing. Even bikeshed stylesheet would like to
             do a selector like this.
  <fantasai> s/matches/is/ btw ;)

  <TabAtkins> .foo:matches(::before, .bar)
  <TabAtkins> ^ invalid
  TabAtkins: Another option is we're more limited and you can put
             pseudo elements in if they're the only thing in the
             selector. All options have to be pseudo elements
  <TabAtkins> .foo:matches(::before:hover) is valid
  TabAtkins: That would be okay way to deal
  <plinss> .foo:matches(::before):matches(:hover) ?
  <TabAtkins> Would be valid by my rule I think
  fantasai: Thing that's tricky is different pseudo elements can be
            followed by different things. No need to make first
            example invalid because each branch is valid. If any
            branch is invalid whole is invalid.
  <dbaron> Pseudo elements seem like they might differ in what is
           allowed after them
  fantasai: More restrictive I'm not sure that gains us a whole lot.
            You'll still need contextual checking, even if they're all
            pseudo-elements.

  <dbaron> It seems like you might want to ensure that all branches of
           the :matches end in the same restriction state
  <TabAtkins> dbaron, I agree with that as a good restriction if we go
              this way

  TabAtkins: ericwilligers we don't support pseudo elements in matches
             right now, correct?
  ericwilligers: Correct
  TabAtkins: Firefox or Edge, how does this sound. Should I close no
             change and Safari violates spec? Or do we want?
  Rossen: Curious to hear from Safari folks.
  * smfr we’re all in a meeting and can’t follow, sorry

  Rossen: dbaron is on IRC [reads]
  <dbaron> (where we need to be conservative about what is the same,
           e.g. before and after OK but not selection)
  <TabAtkins> :matches(::before, ::spelling-error) would be invalid
  TabAtkins: before and after are fine, but before and spelling
             wouldn't work because allow different things
  ericwilligers: Safari uses different selector name. So it doesn't
                 matter too much.
  TabAtkins: Not a backwards compat concern. It's what we want to do
             for the future
  TabAtkins: I'm perfectly fine saying close no change.
  <dbaron> Still have mixed feelings about whether to allow pseudos in
           v1
  TabAtkins: dbaron is unsure. We can relax restriction later
  <dbaron> (typing on phone, BTW)
  Rossen: smfr said Safari folks can't follow because they're in a
          meeting

  Rossen: Objections to resolving no change?
  fantasai: I think deferred
  fantasai: Close no change means we don't want to accept. We might
            accept in future
  fantasai: I'd prefer...if we're going to consider in the future we
            leave it open for selectors 5. If it's a bad idea we close
            no change.
  Rossen: Don't disagree
  Rossen: Objections to defer to L5?

  RESOLVED: Defer this issue to L5

publication
-----------

  fantasai: We just published. Nothing has changed since then
  Rossen:  Okay, that's fine

Text Decor 4
============

Are text decorations visual overflow or layout overflow?
--------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/3272

  Rossen: Raised by myles, fantasai added
  fantasai: myles and I agree it should be ink overflow. Want to
            confirm with WG. I think add to L3 and L4
  Rossen: Implication is if you're editing and at the end of a
          scrollable paragraph and what I type in becomes underlined
          because syntax I won't be able to see that by scrollbar.
  fantasai: If you choose and offset that places underline outside of
            linebox.
  fantasai: Underline typically in linebox and that's within
            scrollable. You'd have to place the underline below the
            line height before it disappears
  Rossen: Trying to understand if we're okay with that
  fantasai: I think it's fine. If you're placing the underline that
            low you're asking for trouble

  <dbaron> It might also be fun to define what element they're
           overflow from.
  <dbaron> But happy with ink overflow, I think
  Rossen: [Reads dbaron ]
  fantasai: Given painted at same layer as text, should overflow from
            element painting the text
  Rossen: Certainly content layer of the scroller...let's see
  <fantasai> https://www.w3.org/TR/CSS2/zindex.html#each-box
  Rossen: Should be container of element with text.
  Rossen: Objections to resolving on definition that text decoration
          is considered ink overflow and not layout?

  RESOLVED: text decoration is considered ink overflow and not layout

CSS Fonts 4
===========

font-display says it's valid in @font-feature-values but it isn't
    an at-rule
-----------------------------------------------------------------

  Rossen: Do we have people for this?
  Rossen: Or defer until myles and chris are around?
  TabAtkins: Let's defer

CSS Inline
==========

Should first/last baseline values of `vertical-align` belong to
    `alignment-baseline` or separate longhand?
---------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/861

  Rossen: fantasai can you summarize?
  fantasai: There is a question of if these values should be
            incorporated into alignment baseline or a sub property of
            vertical align. Vertical-align is a shorthand of baseline
            shift and alignment baseline
  fantasai: Adding a switch to say if we care about first or last
            baseline. Is it a separate property so it cascades? I'm
            not sure how to think through this problem

  Rossen: Anyone on the call or IRC with an opinion?
  Rossen: If not we can defer
  Rossen: Defer to next week
  Rossen: 2 issues left, seems like 1st we can discuss

vertically align to nth-child
-----------------------------
  github: https://github.com/w3c/csswg-drafts/issues/1339

  fantasai: Top ask from math on web pages folks to say this element
            will provide baseline rather then first or last
  fantasai: Similar to first/last switch. It's a property so element
            says "I'm providing baseline". Needs a more concrete
            proposal then what's in issue
  Rossen: Okay. If we can't make progress here, not going to be able
          to do next one either

  Rossen: We can wrap up early unless there's something else we can
          discuss
  fantasai: Trying to think if there's anything to publish. We can do
            CSS Align- it is only minor change to it.

CSS Alignment
=============

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

  Rossen: What's the change? Looking at changes section
  <fantasai> https://github.com/w3c/csswg-drafts/commit/52f193c852b19616019df8f30d67cf2d67146a8a#diff-fe8d087fed2ccda3bdf57954b3ac8d75
  fantasai: Minor clarifications. Mainly ^
  Rossen: Okay.
  Rossen: Objections to publishing CSS Box Align L3 WD?

  RESOLVED: Publish CSS Box Align L3 WD

  Rossen: Anything else?

FXTF logistics
==============

  astearns: Given we have resolutions for FXTF spec publication and
            taking them to CSS, should we close FXTF mailing list?
  Rossen: Anything remaining between new SVG and CSSWG that needs to
          be FXTF?
  astearns: Only part of charter I'm aware of is working on the bits
            of SVG that map to our properties
  Rossen: Don't necessarily need FXTF for that, do we?
  astearns: Nope
  Rossen: Anyone on the call with a reason to keep FXTF ML going? If
          no we can reach out to SVG.
  [silence]
  Rossen: Sounds like no one wants to hold onto it
  plinss: Shut down FXTF server too?
  Rossen: Yes
  plinss: Whoever migrates ping me when you're done
  <smfr> can we keep redirects alive?
  <fantasai> yes, plinss said so
  <plinss> yes
  Rossen: Okay, sounds good

  Rossen: Anything else?
  Rossen: I'll give us 2 minutes back. Thanks for calling, next week
          will be a regular call. Thank you
Received on Friday, 7 December 2018 00:32:57 UTC

This archive was generated by hypermail 2.3.1 : Friday, 7 December 2018 00:32:57 UTC