W3C home > Mailing lists > Public > www-style@w3.org > April 2019

[csswg] Minutes Telecon 2019-04-10 [css-lists-3] [selectors] [css-overflow] [css-values-4] [css-pseudo-4]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 10 Apr 2019 19:00:39 -0400
Message-ID: <CADhPm3shmHz_Hbxu6U-ENCRHcLWiC2USZMn_sES_nvbLSX91QQ@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 Lists

  - RESOLVED: unicode-bidi / direction apply to ::marker (Issue #3809)
  - RESOLVED: apply counter-set after counter-increment (Issue #3810)
  - RESOLVED: implicit list-item counter is not reflected in computed
              style (Issue #3769)


  - RESOLVED: Add :picture-in-picture and :fullscreen to Selectors 4
              (Issue #3796)
  - The spec for :picture-in-picture needs a permanent location that
      Selectors 4 can reference.


  - RESOLVED: Do not propagate any style from display:none HTML or
              Body (Issue #3779)

CSS Values

  - RESOLVED: Use calc(1/0) [to serialize infinity] and calc(0/0) [to
              serialize NaN] (Issue #3768)

Pseudo Elements

  - RESOLVED: Add ::marker to interface CSSPseudoElement (Issue #3769)
  - RESOLVED: The 'content' property should apply to ::marker (Issue


Agenda: https://lists.w3.org/Archives/Public/www-style/2019Apr/0008.html

  Rachel Andrew
  Amelia Bellamy-Royds
  Oriol Brufau
  Emilio Cobos Álvarez
  Dave Cramer
  Benjamin De Cock
  Elika Etemad
  Simon Fraser
  Tony Graham
  Dael Jackson
  Brian Kardell
  Brad Kemper
  Peter Linss
  Anton Prowse
  Manuel Rego Casasnovas
  Melanie Richards
  Greg Whitworth

  Rossen Atanassov
  Tab Atkins
  Florian Rivoal
  Jen Simmons
  Alan Stearns
  Lea Verou

CSS Lists

Should unicode-bidi / direction apply to ::marker?
  Github: https://github.com/w3c/csswg-drafts/issues/3809

  fantasai: We have a limited set of properties that apply to
            ::marker. Unicode-bidi/direction weren't listed but seems
            it would be helpful. This is a request to add those to
            pseudo element spec.
  plinss: Objections?

  RESOLVED: unicode-bidi / direction apply to ::marker

Apply counter-set after counter-increment
  github: https://github.com/w3c/csswg-drafts/issues/3810

  fantasai: This was an issue around interaction. Property values you
            have to set if you're incrementing on every item and want
            to set to a particular value. yOu have to set it minus
            increment. That's ergonomically awkward
  <fremy> (I'm in favor)
  fantasai: Suggestion is set counter set after increment so if you
            set 'foo 5' it will be 5 no matter the counter increment
  fantasai: Generally better cascading behavior. Counter-set wins over
            counter increment rather than adding to it.

  gregwhitworth: When you set counter-set it starts from that place?
  fantasai: Sets an explicit value for the counter
  gregwhitworth: And doesn't increment after that?
  fantasai: If you have nth-child 5 counter-set: chapter 5 it will
            have 5 instead of the increment added to that.
  gregwhitworth: Then increment from 5?
  fantasai: On other elements, yeah.
  fantasai: On a particular element you apply counter-reset then
            counter increment then counter set.

  plinss: Makes sense to me. Looking at issue Gecko implements but
          will change. Any other implementations here?
  fantasai: I think they're only ones. They committed the fix a day ago
  plinss: Objections?

  RESOLVED: Apply counter-set after counter-increment


Add :picture-in-picture pseudo-class
  github: https://github.com/w3c/csswg-drafts/issues/3796

  plinss: Anyone want to talk to this?
  fantasai: I don't know too much about this, but it's being shipped
            by Google imminently. Generally we put all pseudo classes
            in selectors so looks like MOz filed an issue to have it
            in selectors
  fantasai: But I don't know much about what they're about to ship

  smfr: Read but was confused about when it applies. I'd like to to
        say this applies when showing picture-in-picture mode or
        something like that
  fantasai: Is picture-in-picture mode defined?
  smfr: Spec defines but not readable by humans except the 2 that know
        about shadow dom
  <emilio> The shadow dom thing is broken in the spec
  AmeliaBR: Looking quickly it's confusing about if this is pseudo
            class or element. WICG spec describes...seems to describe
  fantasai: It's a pseudo class
  AmeliaBR: An element that's an active element in the doc. There's
            also an extra window object.
  AmeliaBR: I agree with smfr the spec needs some work from css people
            to make sure it's defined clear on consistent. Logically
            makes sense it's a think like fullscreen pseudo class.
  AmeliaBR: Someone needs to work on spec
  fantasai: Not sure we define :fullscreen either
  fantasai: We should add both or neither or have a note about
            additional selectors. I guess in section 11
  <fantasai> https://drafts.csswg.org/selectors-4/#resource-pseudos

  myles: Reason these pseudo elements need to be inside our specs?
  fantasai: Generally...for the most part we have all selectors in
            selectors so if you're looking for one you can find it.
            Detailed description is deferred to the host spec. But we
            define it exists and roughly what it means
  fantasai: Haven't done for :fullscreen or this
  gregwhitworth: I'd like it in selectors spec
  fantasai: Currently specs that define selectors or css properties
            not in WG should ask CSSWG members to review specs before
            shipping, but that's a separate issue
  AmeliaBR: Where ever defined needs to be reviewed to be logically
            consistent. Easier to do if there's a mention in selectors
            that links out.
  plinss: Agree this should be in css specs

  plinss: Do we know where rest of picture-in-picture will spec? Merge
          into HTML? Spec?
  gregwhitworth: I found wicg document but I can ping the person on
                 our team and find out
  AmeliaBR: If following fullscreen pattern it's stand alone in WHATWG
  fantasai: And for us to cross reference we need to know where the
            spec will permanently live. If it doesn't have a plan
            where it should be it needs one. And get buy in from
            people besides Google
  plinss: That's what I was driving at. Are other implementors on
          board with this and whatnot

  plinss: Sounds like we agree if this moves forward pseudo class
          should be in our specs. Not sure what we should do with this
          issue right now
  plinss: Other thoughts?
  smfr: Webkit supports impl but want a better spec. I think there's
        enough to give feedback to authors
  fantasai: Whole spec shouldn't be CSS. We should add a section to
            selectors for :fullscreen and :picture-in-picture. Someone
            should give feedback to the authors. And we should say hey
            we need to link to your spec, are you putting it through a
            standards process somewhere?

  plinss: Resolution to add :picture-in-picture and :fullscreen to
  plinss: Or just leave a note that's where they should live and
  fantasai: Add in and put an issue in there to link to spec once it's
  AmeliaBR: 4 or 5? What's the status of when not quite stable things
            should be...
  fantasai: :fullscreen should definitely be 4. There's no level 5 so
            they should go in there. It's being implemented so I'm not
  plinss: Objections?

  RESOLVED: add :picture-in-picture and :fullscreen to Selectors 4


Overflow propagation when the element propagated from is display: none
  github: https://github.com/w3c/csswg-drafts/issues/3779

  plinss: Who wants this one?
  fantasai: Was emilio able to join?
  emilio: Hey
  emilio: This is mostly a little thing and only place where gecko
          needs to deep dive into the subtree to render
  emilio: I remember Rune at some point complained about it. I was
          wondering if people had willingness to change. I don't
          deeply care but I think it's a bit saner
  * fantasai has no opinion on this
  AmeliaBR: You're asking if the HTML or Body element isn't displayed
            we don't worry about propagate styles up?
  emilio: Yes
  plinss: Just get a blank page?
  <bkardell> seems fine?

  smfr: display:none is common to do?
  emilio: I don't think it is. I could get some data and come back
  smfr: My only concerns is sites where they do that and browsers
        propagate the body background and you get a flash of color
  emilio: Body background is specified to not propagate if there's
  smfr: I guess Chrome has a bug that it doesn't do that which is
        shared by WK
  emilio: Def Chrome, I don't know WK
  smfr: Probably does. I don't feel too strongly. Seems reasonable

  plinss: Curious about usage of display:none body. I can see it
          abused for tracking iframes and whatnot on a page. Curious
          if that's something people want to do. I guess if they're
          putting in iframe they won't put a background on it
  <bkardell> but changing -- there isn't interop now -- or is there?

  plinss: Proposal: Not propagate any style from display:none HTML or
  emilio: Don't propagate the background of the element...basically
          whatever definition the background propagation is using I
          want to align
  plinss: Objections?

  RESOLVED: Do not propagate any style from display:none HTML or Body

CSS Lists (continued)

Is the list-item counter increment for list items reflected in the
    computed style?
  github: https://github.com/w3c/csswg-drafts/issues/3769

  emilio: There's a magic increment applied to list items that's
          defined in terms of display. Element with display styling
          you have the magic counter increment depending on if list is
          incremented [missed]
  emilio: Another possible thing to do is to just do it at used value
  emilio: I don't feel too strongly either way, maybe other engines
          have constraints on when can shuffle elements. As an author
          don't know if it's very useful to gCS with this counter. If
          you spec counter-increment:none and computed style is not
  fremy: I think it's not included in counter style
  <fremy> ^ (in Edge)
  <fremy> ^ (which is good because it probably should not inherit)

  AmeliaBR: Clarification. When author says counter-increment:none it
            doesn't cancel the list item increment. Based on rule
            serialization should be as short as possible if omitting
            list item 1 have same effect as spec shouldn't shortest
            version be to omit it?

  <emilio> Ugh, audio went nuts
  plinss: Looks like emilio is having audio issues. Still there emilio?
  <emilio> on irc yes
  plinss: He's IRC only at this point

  plinss: Any other thoughts on this?
  <emilio> We could also do what AmeliaBR mentions, but that is only
           ommittable depending on the display value, so it's a bit
           weird to serialize differently depending on other property
  <emilio> fremy's point about inheritance is a good point

  plinss: Should we defer until emilio can be on a call? He's
          responding on IRC
  gregwhitworth: Let's defer if he's not able to get on

CSS Values

How to serialize infinite values?
  github: https://github.com/w3c/csswg-drafts/issues/3768

  AmeliaBR: I can go over quickly
  AmeliaBR: Issue is that at serialization stage before computed style
            we say divisions are simplified. Sometimes means you have /
            0 situation or other situations with infinite or NaN
            values. We have that NaN is +infinity but how to serialize.
  AmeliaBR: Proposal is serialize it as a calc expression as something/
            0 where something is appropriate to dimension you're using
            1px, 1deg, 1ms
  AmeliaBR: This would only be exposed in serialized values
  AmeliaBR: Catching up on issue discussion between oriol and
            TabAtkins where NaN should have own unique serialization
            different than infinity
  AmeliaBR: We want something predicable and consistent but not too
            complicated b/c used in a lot of places. Just for
            intermediate serialization

  fantasai: Seems like the issue converging on infinity is calc(1/0)
            and NaN is calc(0/0)
  plinss: negative infinity is calc(-1/0)?
  fantasai: Yep
  AmeliaBR: And all of these would hold on to a unit so it's
  fantasai: Makes sense

  gregwhitworth: Consider NaN as a keyword?
  fantasai: Then we'd need to make it for all CSS and why would you
            want that
  gregwhitworth: For this reason? Because we're specifying in a weird
  fantasai: This is better than a global keyword that's a number that
            doesn't exist. I don't think it helps anyone
  emilio: Probably doesn't work with dimensions
  fantasai: That's an important point
  plinss: Other alternative is keywords for NaN and infinity for only
          in calc. Curious if they have an actual use somewhere else
  AmeliaBR: We do have some properties that have an infinity keyword
            and that is treated different than a calc expression that
            computes to infinity. It's the infinite keyword in
            animations. Not sure where else
  fantasai: We should go with calc-based serialization. It comes up in
            serializing calcs and that way we don't need keywords for
            units. It's built into the method
  plinss: Objections?

  RESOLVED: Use calc(1/0) and calc(0/0)

  emilio: How does NaN behave? Like NaNpx body?
  AmeliaBR: I assume keep current rule where treated as +infinity and
            then clamps per property rules
  emilio: Wouldn't be better to keep as computed time for clamping and
          not care about serialization?
  AmeliaBR: Serialization simplifies multiplication and division so it
            has to be simplified. Going down to a standard division
  AmeliaBR: If you specify calc(3/3) at serialization you get 1. If
            you specify calc(3/0) we're saying at serialization you
            get 1/0
  plinss: Given our existing rules we have to do this

  emilio: calc(1/0) doesn't parse anywhere, right?
  AmeliaBR: I don't know. If we have people rejecting at parse or
            doing own thing at serialization
  emilio: Pretty sure gecko rejects at parse time. When we impl min/
          max may have to change
  <@fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Chtml%20style%3D%22background%3A%20red%3B%20background%3A%20calc(1px%2F0)%20calc(1px%2F0)%20green%3B%22%3E
  fantasai: Does appear to be the case ^
  fantasai: If we enter as keyword still won't parse.
  fantasai: Gecko does not parse
  AmeliaBR: Same for Chromium
  AmeliaBR: But we're extending number of possible divisions
            possibilities. Allowing to divide values with units and
            some units might be 0 so need robust math rules
  emilio: But then how to serialize this is only small part, need to
          spec how behave. You're introducing them into layout
  AmeliaBR: There is an extended new section on range checking
  AmeliaBR: that says any infinite values are clamped to min/max
            allowed. emilio is right most properties don't have
            explicit min/max value allowed
  <AmeliaBR> https://drafts.csswg.org/css-values/#calc-range
  AmeliaBR: That part of spec probably still needs to be discussed. I
            don't know if need to hold off discussion of serialization
  emilio: Generally the spec says clamp and apply transformations as
          early as possible. calc(10px) serializes to 10px.
          Serialization might not be an issue depending on how spec to
  myles: Not sure should spec max for every property. Browsers may
         vary. Some browsers might be able to handle a really big
         width and some can't
  emilio: Agree
  myles: Tons of implementors specific limits like nesting depth that
         aren't written. These max should be with those
  AmeliaBR: Good point. Should lead to not clamp too early. Eventual
            clamp will be impl specific so should only happen when it
            has to. If we just propagate mathematical infinity it
            helps interop and serialization stage
  emilio: Reasonable answer
  plinss: Anything else?

CSS Lists (continued)

Is the list-item counter increment for list items reflected in the
    computed style?
  github: https://github.com/w3c/csswg-drafts/issues/3769

  emilio: I think fremy's point is good. weird the counter would be
  AmeliaBR: You're agreeing the implicit list item shouldn't show in
            computed styles?
  emilio: Yes. That's what I proposed. Mats disagreed.

  plinss: Wondering if we have right people to resolve this
  fantasai: My inclination is leave as a hidden mechanism but I don't
            have strong rationale. I'd choose that unless there's a
            good reason to reflect in computed style. Putting it in
            computed style means it inherits which is a little weird
  fremy: Another reason is right now it's a breaking change but if you
         don't put in computed style it's not a breaking change.
         Unless there's a strong reason for it to be in computed style
         it shouldn't be
  emilio: I don't think in this case compat is a constraint but I
          agree it's nice to keep compat

  AmeliaBR: Sounds like call agrees. Resolve it pending a clear
            objections from Mats or anyone?
  plinss: sgtm
  plinss: Objections?

  RESOLVED: implicit list-item counter is not reflected in computed

Pseudo Elements

Add ::marker to interface CSSPseudoElement
  github: https://github.com/w3c/csswg-drafts/issues/3763

  fantasai: This is straightforward. Have a pseudo element similar to
            before/after. Just add it to the pseudo element interface
  plinss: Objections?

  RESOLVED: Add ::marker to interface CSSPseudoElement

Should Element.pseudo("unknown") be an error or return null?
  github: https://github.com/w3c/csswg-drafts/issues/3603

  fantasai: If TabAtkins isn't here and no one else understands should
  plinss: Defer for TabAtkins

The 'content' property should apply to ::marker
  github: https://github.com/w3c/csswg-drafts/issues/3499

  fantasai: Mozilla has an implementation of this. TabAtkins and I
            cleaned up lists spec so what it needs to do with content
            interaction should be well defined. Proposal is to add the
            content property back into pseudo elements applying to
  AmeliaBR: Content still set auto based on list property?
  fantasai: Yes. Initial value is normal and that takes content from
            list style property
  AmeliaBR: So an author wouldn't have to set content prop for marker
            to be rendered but could override it if want to do
            something special
  fantasai: Yes
  AmeliaBR: Makes sense to me
  fantasai: Any objections?
  plinss: Objections?

  gregwhitworth: Curious about use case. If they're in disc mode
                 they'd replace with a new disc type?
  fantasai: Background and display don't apply to markers. Case is I
            have an <ol> and I might want to change to include the
            chapter number or I might decide I want outside list
            marker styling and turn my headers into list items. You
            could do those kind of things
  gregwhitworth: How different then increment stuff?
  fantasai: You can say I want to use this piece of text. May or may
            not include a counter. More flexibility in terms of what
            you want in terms of things like punct
  AmeliaBR: Lots of use cases <ol> 20-1 but 3 2 1 are bronze/silver/
  fantasai: Multi-part listing is one of the biggest use cases. We
            should put an example in spec.
  plinss: Objections?

  RESOLVED: The 'content' property should apply to ::marker

  plinss: That's the top of the hour.
  plinss: Thanks everyone.
  fantasai: Idea for ::marker was to make it more stylable then it is
            right now. Because we don't have marker layout defined
            we've limited number of properties to those not impacting
            layout. But content was in list spec for a while. Cut it
            down for pseudo 4 and content was easy enough
  gregwhitworth: Thanks for clarification
  <AmeliaBR> Example of that gold/silver/bronze idea done with
             ::before and a custom counter:
  <AmeliaBR> (But I agree that a nested list with 2.b.ii as a number
             is a more common case.)
  <fantasai> We should definitely add it as an example in the spec
Received on Wednesday, 10 April 2019 23:01:34 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:53:13 UTC