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

[CSSWG] Minutes Telecon 2018-11-21 [css-transforms] [css-break] [css-exclusions] [selectors] [css-inline]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 21 Nov 2018 19:57:12 -0500
Message-ID: <CADhPm3sbTqw5KmyxmPR9W-ZB4fEVcHCvAOVyGJecoN1Q_pNZpA@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.


  - RESOLVED: Publish WD for Transforms

CSS Exclusions

  - There hasn't been any recent work toward resolving the concerns
      that have been already raised about this spec. (Issue #3308)
  - Interest from web developers is still high so those interested in
      working on it will compile use cases and revisit the open
      concerns in light of the use cases.

CSS Break

  - RESOLVED: Add 'always' and 'all' to break-before and break-after
              where always is on the nearest fragmentainer and all
              breaks across all fragmentainers. (Issue #3318)

CSS Selectors

  - RESOLVED: Use media query style invalidation inside pseudo classes
              that accept selector lists (Issue #3264)
  - RESOLVED: Kick the can down the road and think about this (Issue
              #3082: Reconsider removing selector list invalidation)
              for Selectors 5
  - RESOLVED: Add :defined to selectors L4 (Issue #2258)
  - RESOLVED: Publish a new WD of Selectors 4

CSS Inline

  - The draft proposal for line-box-contain (Issue #3199,
      created a lot of interest, but time ran out on the call so those
      who wish to discuss further will organize a separate call to
      dive deeper into details.


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

  Rachel Andrew
  Rossen Atanassov
  David Baron
  Tantek Çelik
  Emilio Cobos Álvarez
  Dave Cramer
  Alex Critchfield
  Elika Etemad
  Javier Fernandez
  Simon Fraser
  Dael Jackson
  Brad Kemper
  Chris Lilley
  Peter Linss
  Myles Maxfield
  Thierry Michel
  Melanie Richards
  Florian Rivoal
  Alan Stearns
  Lea Verou
  Greg Whitworth
  Eric Willigers

  Tony Graham
  Nigel Megitt
  Michael Miller
  Jen Simmons
  Manuel Rego Casasnovas

Scribe: dael

  Rossen: It's 9:02. Let's get going
  Rossen: I wanted to see if there are any additions or changes to the

  florian: We have issue #3024 on the agenda. Used to be agenda+ for
           F2F, was changed to regular. Not sure if it's ready since
           the discussion at TPAC.
  Rossen: How can we make progress?
  florian: Is zcorpan on?
  florian: If not we should not discuss
  astearns: I believe he's on vacation until next year
  Rossen: I'll push to end of agenda. Can you take an action item to
          ping him and see if we can get progress?
  florian: I think it's mostly you should harass me to respond to his


Publish WD for Transforms
  Rossen: We have a CR resolution, but we don't have a current WD.
  RESOLVED: Publish WD for Transforms

CSS Exclusions

Status of the exclusions spec
  github: https://github.com/w3c/csswg-drafts/issues/3308

  rachelandrew: This keeps coming up. Every now and again I get a grid
                question that's actually exclusions
  rachelandrew: This issue is quite compelling
  [audio issues]
  rachelandrew: This is something that keeps coming up. The issues I
                opened this with, floating things in a grid, I see
                people keep asking for.
  rachelandrew: I wanted to package this up and see where we are.

  Rossen: For exclusions the current version, you've captured the impl
          status. We've had some since IE10, carried through to Edge.
          Current spec as is defines how an exclusion area works, what
          is effected, how propitiate through decedents. How geometry
          side works.
  Rossen: Lots of push back in past because most people thought this
          also defines exclusions as working on abspos only. Not true.
          Not dependent on any specific layout scheme
  Rossen: As such spec has been held at no progress for those issues.
          I'd be happy to engage with anyone interested in progress
          and see if can get more traction.
  <dbaron> some of my previous concerns about exclusions are at
           and the thread above

  florian: There was push back on that, but also on a variant where
           they could work on some modes that didn't do collision
           avoidance. That you could exclude without collision
           avoidance was a problem. I was given an action to try and
           define collision avoidance by default, but it's very hard
           and not sure that's the way forward. Other option is to
           make property have no effect on things such as abspos that
           don't include collision avoidance built-in or just let it
           be possible
  florian: Maybe still pursue if you turn it on with something that
           doesn't have collision avoidance you get it. Need someone
           to define that. It's possible, but massive.
  Rossen: That's my memory as well.

  Rossen: I think dbaron posted related threads
  Rossen: They had to do with some concerns about cyclic dependencies
  Rossen: I don't recall any such issues when I impl exclusions, but
          can't speak for other engines.
  Rossen: Most of concerns were related to paged media and not as much
          visual. This is when most issues would occur

  <rachelandrew> I think this is going to keep coming up, I'd be happy
                 to help work on it, but I think we need something to
                 solve these use cases
  <rachelandrew> now we have grid we'll see more of them

  Rossen: This is where we are. Summary captures everything we've
          discussed. Be happy to try and make progress and have
          exclusions move forward because they are awesome.
  Rossen: For those interested let me know and we can try and make
          something actionable
  Rossen: rachelandrew are you interested?
  rachelandrew: Yes, definitely
  Rossen: What if we table the discussion until we bring back use
          cases and see how they fit in current model.
  rachelandrew: sgtm

  <fantasai> +1 to dbaron's concerns listed above
  <florian> rachelandrew If you're interested, I can send you my notes
            / draft about trying to define collision avoidance by
            default from way back. They're not complete, but might
            still be of interest.
  <rachelandrew> florian: that would be great thanks

CSS Break

Should 'break-before' / 'break-after' have an 'always' value?
  github: https://github.com/w3c/csswg-drafts/issues/3318

  fantasai: As emilio and I looked into these aliases we noticed IE
            impl 'always' which is not in spec. In earlier revisions
            there was 'always' but not clear. We considered break
            through all fragmentation context or in closest one.
  fantasai: IE treats as alias to page and only works in paged mode
  fantasai: Options: We can define that break-before:always doesn't
            exist but it looks like usage is high
  fantasai: We define it to exist has 3 options:
  fantasai: Alias of Page, Trigger break at inner most fragmentation
            context, or Trigger to break through all available
            fragmentation contexts
  fantasai: Those are our options.
  fantasai: My preference is if we have this we should break at inner
            most fragmentation context. That way author working on
            content can ask for a break at the next thing. That seems
            most useful when trying to simulate pages.
  <bradk> Innermost seems the most sane to me.
  fantasai: Most compatible is define as page break. I'm not sure we
            need that level of compat because main difference is if
            inside a multi-col. In IE you will not trigger any break
            in a multi-col unless you're printing. So if you're using
            break in multi-col you'll get really inconsistent results
            depending on mode.

  florian: I think last time we talked we agreed main use case was
           inner most, but also a use case for outermost. We removed
           because needed to name both consistently. I think we had any
           /all, but not sure.
  fantasai: Now we have 'always' which needs to be defined in some way
  florian: Always and all and always and any that always pairs best. I
           think we should get both, but if we have both which name is
  <bradk> always|all

  fantasai: I think inner most is most useful, but interested in
            hearing from rachelandrew and dauwhe
  dauwhe: In ebook people fake pagination with multi-col all the time.
          Inner sounds like would make sense for us
  florian: If you're not nesting it doesn't make difference whether
           you punch through. If you are nesting I think you'll need
           both. Like, you're at a chapter break and want to break all
           context. Or smaller break.
  fantasai: bradk suggests 'always' and 'all'
  florian: I think that's okay
  <rachelandrew> always and all sounds good to me
  florian: If we're stuck with 'always' it's reasonable

  fantasai: Rossen would you be willing to change in Edge?
  Rossen: Potentially. Use cases I've heard are compelling and make
          sense. From impl PoV it's not super hard. more juggling to
          re-order breaks in the right priority and break as much as
          needed based on current stack of breaks.
  Rossen: Break through all or just current is similar to things we're
  Rossen: Having heavy hammers of those two, it'll be fine. I don't
          think from impl PoV this is a huge concern as long as it
          fits the bill and addresses enough use cases.
  fantasai: I think having 'always' makes it easy for authors. They
            don't have to think about context, they just want a break.
            If you want a page break, you can say that specifically.
  Rossen: Wouldn't disagree.
  Rossen: In principle my model for breaking and fragmentation has
          been ideally one you can declare your own levels and then
          have your own defined break for that level. It could be a
          page, a column, and article, and you should expect that's
          how it happens
  Rossen: Since we're static defining the levels something to punch
          through is needed.
  Rossen: You'll always have cases where they say punch through
          everything except this one. Hoping to not have to discuss
  florian: Might need that with region or region-like things. But it's
           just a maybe. If we do it's not hard, but hopefully
           unneeded complexity

  <myles> Rossen: if you have columns inside pages, how do you force a
          page break without forcing a column break?

  Rossen: I see last proposal was break-before/after: always | any |
  fantasai: 'always' and 'all', 'always' is nearest
  Rossen: 'All' is a superset of 'always'
  fantasai: 'always' means you always get the minor-est amount of break
  Rossen: 'All' implies 'always' everywhere
  fantasai: umhum
  Rossen: What do others think?

  Rossen: Objections to adding 'always' and 'all' to break-before/
          after where always is on the nearest fragmentainer and all
          breaks across all fragmentainers

  RESOLVED: Add 'always' and 'all' to break-before and break-after
            where always is on the nearest fragmentainer and all
            breaks across all fragmentainers.


Let :matches() have better error-recovery behavior than normal
  github: https://github.com/w3c/csswg-drafts/issues/3264

  Rossen: Is TabAtkins on?
  fantasai: I can take it
  fantasai: When we have a list of selectors :foo, :bar
  fantasai: Browser doesn't recognize :foo so the entire style rule is
            thrown out
  fantasai: That's selectors style invalidation.
  fantasai: Other style of invalidation is media queries-like where
            you throw out a section. So if you have :foo, screen we
            recognize screen
  fantasai: Can't do MQ like because it would break the web for
            selectors. TabAtkins pointed out we have ability to do it
            within the new selectors in L4
  fantasai: Issue proposes we adopt MQ-like invalidation inside the
            pseudo classes that take selectors.
  fantasai: :foo || :bar, [known selector] we'd only do the part we
  fantasai: Makes a lot of sense to me together with @supports rule we
            added. Gives authors much better tools. If they want more
            granular they can use something else
  Rossen: Sounds reasonable.

  Rossen: Opinions?
  myles: Thoughts from people that teach this? Seems like could be
  Rossen: leaverou or rachelandrew ?
  * tantek agreed with myles, it could be confusing. would definitely
           want webdev teacher feedback on this.

  <dbaron> Were you suggesting doing different things for :matches()
           vs. :is() ?
  fantasai: dbaron this was from before we renamed. Title should be
            :is. Applies to :is, :not, :has, :nth-child, and maybe
  dbaron: One worry is some have been around for a while and might
          have compat issues
  fantasai: :not with commas isn't widely supported.
  fantasai: :not with a single argument that's invalid makes the whole
            thing invalid
  florian: I think :not with a comma is supported in Safari and
  fantasai: :not is trickier because it's a negation

  leaverou: Trying to decide error recovery or syntax?
  fantasai: Error recovery
  leaverou: Sounds amazing thing to do. It might be a little
            confusing, but it's worth it. In talks I only use webkit
            version and have to mention verbally it's just webkit. As
            an author I would love it

  emilio: Doesn't solve unknown pseudo elements issue, right?
  fantasai: No, that's separate.
  emilio: I think that's biggest issue authors want to solve
  fantasai: There's a rule for the webkit
  emilio: Want to style a video control for webkit and edge it's not
          standard. That's the biggest source of duplication
  fantasai: This would solve, put it in all one :is
  emilio: Syntax allows pseudo elements inside?
  fantasai: This is work for pseudo classes. Elements is next on agenda
  <florian> I support this

  <bradk> I’m still concerned about :not. Can we find out how much
          authors have :-webkit and commas inside not?
  Rossen: bradk point about :not and his concern, can we address that
  Rossen: Concern is the :not and defining how much authors have
          commas inside a :not?
  florian: It's safari only
  bradk: Safari on iphone is used a lot. :not has been without commas
         for a while, but it's used in mobile web a lot. That's my
         suggestion, I'd like actual data
  florian: This is hard data to get. Need to find usage that would
           break the page if it started working in a different way.
           That's a judgment call
  Rossen: Another way to ask is if any Apple folks have an issue with
          this. If they feel comfortable with compat risk we can
  bradk: That solution would be okay
  smfr: I don't think we have enough information to know. When we
        implemented :not we got compat issues because people using it
        in wrong ways
  smfr: No feeling for how common comma use is to know if it's risky
  Rossen: Would you be okay with current proposal in the absence of
          this information?
  smfr: I think so

  Rossen: Anything else before we try and resolve?
  <bradk> No strong objection
  Rossen: fantasai can you give the resolution text?
  fantasai: Use media query style invalidation inside pseudo classes
            that accept selector lists
  Rossen: Objections to ^?
  emilio: Would like behavior for :not clarified
  fantasai: Makes sense.

  RESOLVED: Use media query style invalidation inside pseudo classes
            that accept selector lists

  Rossen: fantasai and TabAtkins will have clarification in spec

Reconsider removing selector list invalidation
  github: https://github.com/w3c/csswg-drafts/issues/3082

  fantasai: Closely related issue
  fantasai: We were talking about how invalidation is a problem, can't
            change for compat reasons.
  fantasai: Suggestion was have a special rule for unknown pseudo
            elements to treat as valid, but only for not prefixed
            ones. Wanted to ask WG if we should look into this
  fantasai: If you don't recognize anything in the selector you
            invalidate the whole thing. Can't change whole rule, but
            maybe possible to change that rule only for pseudo elements
  fantasai: Wanted to ask if anybody has thoughts on if this is
            something we should look into

  Rossen: Opinions?
  florian: I think people rely on it not to work as a form of browser
  dbaron: Also one where I would ask who would impl first
  Rossen: I'm hearing pushback

  emilio: Assume proposal you need to work only for unprefixed, right?
  fantasai: Yes
  florian: Then it's a question of accidentally relying on it not to
           work. Possibly less but have no data.
  Rossen: I can't figure out if this is something we want to work on
          or if just table
  Rossen: Still hearing more pushback then interest
  florian: If we could make it work it would be great.

  fantasai: Want to know if we should a: accept, b: reject, or c: not
            now, maybe selectors 5
  Rossen: Easiest to agree on is C
  <bradk> C
  Rossen: Anyone pushing for accept or reject?
  Rossen: Objections to kick the can down the road and think about
          this for Selectors 5?

  RESOLVED: kick the can down the road and think about this for
            Selectors 5

  florian: Not satisfactory but until someone volunteers to collect
           data there's not much we can do.
  Rossen: It's reflecting reality, though.

  github: https://github.com/w3c/csswg-drafts/issues/2258

  fantasai: HTML defines :defined pseudo class in its spec, in general
            we define in selectors and HTML refines. So should
            :defined be defined in selectors?
  fantasai: Matches all elements that had no problem during

  Rossen: Any reason why it shouldn't be defined in selectors?
  fantasai: Very HTML specific currently. That's the only reason I can
            think of
  Rossen: Not crazy about the name, it's a little too generic

  florian: Would it fail to match on custom elements not defined
           properly and any element whose semantics are unknown to
  fantasai: Don't know
  florian: Reading example that seems to be the case. If using on a
           not known element it won't match.
  florian: Does make it non-HTML specific even if use cases are HTML
  florian: Seems like we should do this, but also study more
  fantasai: It's implemented afaict
  Rossen: Implemented in blink?
  fantasai: Not registering as invalid in test case.
  <fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0Ahtml%3Adefined%2C%20foo%3Adefined%20%7B%20border%3A%20solid%20green%3B%20%7D%0A%3C%2Fstyle%3E%0A%3Cfoo%3EThis%20is%20a%20test%3C%2Ffoo%3E
  emilio: Implemented in blink, gecko, and webkit
  Rossen: If this has implemented in various UA and since it's a
          selector makes sense as part of selectors unless we're
          against it in the way it's defined. We should accept it and
  florian: Sounds good

  Rossen: Other comments or objections to adding :defined to selectors

  RESOLVED: Add :defined to selectors L4

Publication of Selectors

  Rossen: Republish WD?
  fantasai: Yeah.
  fantasai: Thing we just resolved on I'll mark as open issue

  RESOLVED: Publish a new WD of Selectors 4

CSS Inline

Draft line-box-contain proposal
  github: https://github.com/w3c/csswg-drafts/issues/3199

  fantasai: We talked about having a property that does roughly this.
            Some control over height of line calc. Been discussed
            since before my time. dbaron had interesting proposals for
            how to do it
  fantasai: Know we need 3 behaviors: now, quirks mode, and consistent
            lines people want
  fantasai: Drafted rough proposal with behaviors talked about.
  <fantasai> https://drafts.csswg.org/css-inline-3/#line-sizing-property

  fantasai: Wanted to ask WG if we want to work on this? Add
            something? I think need to add to inline spec, this is a
            rough draft.
  fantasai: I think we need to add a property that does something
            smooth with a syntax
  fantasai: Vague, but I wanted a start
  myles: Been thinking about this for a while and I don't know right
         approach. Need backwards compat, but mode switches are
         confusing and multiple ways to solve line-height is extra
         maintenance and makes web more complicated. Not sure right
         way to do this
  florian: Hard time seeing anything but a mode switch here. Not sure
           we need that many values, I'd rather 2. One does legacy or
           quirk depending on mode and the better behavior. Others
           listing leave out until proven
  fantasai: The 'better behavior' says "Line boxes are sized, and
            content positioned within them, as defined in [CSS2],
            except that positive half-leading is not applied to any
            box other than the root inline box."
  fantasai: It might be possible to slip that in without breaking too
            much. Any leading would break, but only eliminating
            positive leading might be possible. It's possible that
            won't break anything
  myles: Not saying mode switch bad. More frustration about where we
         got to. Also, want to say this is one of the most requested
         features from people that care about text. Great to solve.
         We're between a rock and a hard place
  dauwhe: I will use it as soon as it exists
  Rossen: Where do we work on it?

  dbaron: A few comments
  dbaron: I think there is an alternative to mode switch is new syntax
          to line-height. Mode switch-like, but not as bad in some ways
  dbaron: May need >1 new value. bunch of use cases for things like
          images in a line and in default you want images to change
          line height, but there are cases where images within a line
          and do not want a change because images are roughly the size
          of the text
  fantasai: In terms of new keywords for line-height for ergonomics a
            mode switch is better. Line-height you're talking about
            quantity of space, not the mechanism by which you want to
            measure. It's a separate thought in how you want to do it.
  fantasai: You want the good line height calc on the whole page and
            forget it. Same way as box sizing is done. I used to think
            it was a mistake, but the way we did box sizing was
            originally almost always wrong. Webdev would rather set it
            once on a style sheet.
  <dbaron> I actually disagree about box-sizing, since I think it
           depends whether you care about the inside-size or the
  fantasai: This is similar. You almost never want to switch. You want
            to set at the top and you don't want to think anymore. If
            you put it in line-height you have to think every time you
            change the line height
  <tantek> yes it was certainly my intent when I proposed box-sizing
           that it was a "just fix it so things work like I expect
           across all the things box related"

  myles: Would a mode switch change the way line-height is inherited
         or how it applies to only block elements and not inlines?
  fantasai: Various behaviors proposed. One that would fix most
            problems would be to change it so line-height is ignored
            on all inline elements. They just have a line-height of 1
  fantasai: Had to modify so if you set line-height <1 we add negative
            leading so your effect is honored
  fantasai: Not that it doesn't apply, just only applies if negative
            leading. Applies to root and then applied to every line.
            As long as you're in that space, if the sizing box fits,
            it doesn't increase height of line or move it
  myles: Any precedent for that type of behavior?
  myles: I mean changing the behavior of a property based on another
         property. Not sure how I would impl

  Rossen: Sorry to interrupt. We're 4 minutes overtime. I want
          conversation to continue, but I want to let everyone else
          go. We won't resolve, but conversation should continue
  myles: I have to go too.
  fantasai: Schedule a separate call about this.
  Rossen: Good idea
  Rossen: Focused group would be good. I'll send an email to private
          list to see if we can get folks.
  fantasai: I can send
  Rossen: Have a great Thanksgiving for those of you celebrating. Talk
          to you next week.
Received on Thursday, 22 November 2018 00:58:09 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:12 UTC