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

[CSSWG] Minutes TPAC F2F 2020-10-23 Part II: Fragmentation, CSS Overflow, CSS Display & Pseudo Elements, CSS UI, CSS Pseudo Elements [css-break] [css-overflow] [css-display] [css-pseudo] [css-ui]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 4 Nov 2020 09:51:55 -0500
Message-ID: <CADhPm3tFFBZ0_r6E4DSMuwLCfs9kt54EWU18QC6N8k0OTQ52pg@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.


  - Before resolving on issue #4989 (Rules for direction to use when
      slicing inline borders for box-decoration-break:slice are
      unclear) there needs to be additional use cases from
      internationalization. r12a will add examples and then the group
      will re-discuss.
  - RESOLVED: Ink overflow does not cause new fragments to exist, and
              does not fragment (Issue #4099: Specify that ink
              overflow doesn't fragment?)
  - RESOLVED: Work on a mechanism to control where slicing is allowed
              as a length from either side of the monolithic element
              (Issue #3405: Orphans and widows for fragmented
              monolithic replaced elements)
  - RESOLVED: Add "break-inside: allow" to enable slicing of images
              even if they could fit in the next page (Issue #3404:
              Should fragmentation of block-level replaced-elements be
              configurable? ("object-slice"))
  - Adding a 'never' value to break-inside, which would prevent
      slicing if slicing would be necessary and instead cause
      clipping, will be discussed in a separate issue where use cases
      can be compiled.

CSS Overflow

  - RESOLVED: scrollWidth/scrollHeight ignore overflow:clip when
              computing the value (Issue #5572: CSSOM scrollWidth/
              scrollHeight behaviour of “overflow: clip”)

CSS Display & CSS Pseudo Elements

  - RESOLVED: ::marker::marker is invalid (Issue #1793: Is ::marker
              created by display:list-item or does it always exist?)
  - RESOLVED: Computed 'display' on ::marker drops 'list-item' keyword
              (Issue #1793)


  - RESOLVED: Adopt accent-color as a hint to the UA, with
              requirements on contrast (Issue #5187: Allow specifying
              the "accent color" of a form control element)
  - RESOLVED: Mason Freed added as UI 4 editor

CSS Pseudo Elements

  - RESOLVED: Remove ::inactive-selection from Pseudo 4, and add an
              issue on MQ to add an active-window media feature (Issue
              #4579: ::selection vs ::inactive-selection)


Agenda: https://wiki.csswg.org/planning/tpac-2020#agenda-schedule

Scribe: fremy


Rules for direction to use when slicing inline borders unclear
  github: https://github.com/w3c/csswg-drafts/issues/4989

  fantasai: dbaron said the rules for box-decor-break slice are not
            clear on which direction you should use for the splicing
  fantasai: either the inline element itself
  fantasai: or the parent block
  fantasai: and I would suggest to use the inline
  fantasai: For example if you used a rainbow gradient it should
            splice in the direction of the element
  florian: I am confused about what the alternative would do
  florian: but I agree that what you described sounds like the right
  Rossen: ok sounds reasonable
  Rossen: any objection to resolve this?

  * r12a wonders what happens with latin text wrapping inside an
         arabic paragraph
  Rossen: (repeats r12a question on irc)
  r12a: If you write "unicode conference" and "conference" moves
        to the next line
  r12a: and in this case it would not to that in terms of what the
        text actually does
  r12a: but in terms of rendering maybe it does
  florian: For the border, you want the side that is the side on the
           end of the line to be open
  florian: but that doesn't match what we just discussed with the
  r12a: Yes, we should probably look at a few examples
  r12a: I can provide examples if the group wants
  Rossen: that sounds great
  Rossen: (the examples)
  Rossen: fantasai does that change your mind?
  <r12a> https://r12a.github.io/scripts/tutorial/part5#latin-in-rtl
  fantasai: Yes, let's take another look after we considered all the
  Rossen: Ok, if the examples don't break everything (no pun intended)
          we will resolve what we decided
  Rossen: but otherwise we will re-discuss

Specify that ink overflow doesn't fragment?
  github: https://github.com/w3c/csswg-drafts/issues/4099

  fantasai: We don't specify if ink-overflow gets paginated or not
  fantasai: I think we should say it does not
  fantasai: that's my proposal
  <astearns> +1 from me
  Rossen: That sounds like a reasonable resolution indeed
  <jfkthame> +1
  myles: If it doesn't cause scrollbars it shouldn't cause new pages
  fantasai: That was my reasoning
  Rossen: ok, any objection?

  smfr: Also box-shadow?
  fantasai: Yes
  fantasai: If it renders across adjacent columns, that's fine
  fantasai: but it should not fragment in the fragmentation direction
  Rossen: So if the box shadow is long, and it goes beyond the end of
          the page
  Rossen: then we don't create a page for that shadow
  Rossen: but if there is content that generate the page, then we
          don't drop the shadow
  smfr: Yes, both cases were things I considered
  florian: Ink overflow does not cause new fragmentainers to exist
  florian: I don't think we have reached consensus on the first
           question if the fragmentainer exists anyway
  fantasai: These are things you don't want to slice though, such as
            parts of glyphs that are outside the bounding box
  fantasai: So if the things that generate the shadow is in two
            fragmentainers, you get it in both places
  fantasai: but if there is no reason to draw it because the item
            itself doesn't fragment, then you don't draw it
  <astearns> I agree with fantasai on where ink overflow should get

  Rossen: We can split in two resolutions
  Rossen: The first one is mature
  Rossen: whether or not you create a new fragment
  Rossen: depends on content
  Rossen: and ink overflow does not cause the creation of a new
  fantasai: What I want to define is that you don't fragment ink
            overflow. Neither can it cause new fragmentainers, nor can
            it be sliced across them if they exist
  Rossen: That would be the combination of the two resolutions
  <faceless2> +1 to Elika's proposal.

  jensimmons: Something I have seen is that the shadow sometimes
              appear at the top of the next column and it's weird
  iank: We consider that a bug indeed
  Rossen: Let's try to take the super resolution
  Rossen: The ink overflow does not cause new fragments to exist, and
          does not fragment

  RESOLVED: ink overflow does not cause new fragments to exist, and
            does not fragment

Orphans and widows for fragmented monolithic replaced elements
  github: https://github.com/w3c/csswg-drafts/issues/3405

  fantasai: This is a feature request for fragmentation level 4
  fantasai: It would be nice to control widows/orphans on
            monolithic boxes
  fantasai: It would be a length instead
  fantasai: and thus cannot inherit so we need a new property
  fantasai: It would say how much space you need on the page to accept
            and fragment vs push in the box to the next page

  fantasai: Proposal would be widow-something: <length> or something
  faceless2: I don't think the name should be widow/orphan its a
             different concept

  florian: Maybe I misremember but I think we are not supposed to
           split monolithic elements at all
  florian: so the default value should be 100% right?
  florian: (split only happens if you cannot fit)
  fantasai: We want to control that
  fantasai: And that is the next issue
  florian: Why a different toggle?
  florian: If you have 100%
  fantasai: Yes, but break-inside is more reasonable to find for
  florian: Yes, that's true
  Rossen: Are we discussing accepting the proposal?

  myles: Is my understanding correct to say that they don't
  myles: like when 3px of their image appears at the end of a page
  myles: and the rest gets displayed on the next page?
  fantasai: Yes
  myles: Ok

  Rossen: Any other thought?
  florian: I am not sure it's a different than the break-inside thing
  florian: For example on some images there might be only three points
           where you want to break
  <tantek> interesting, the image breaking equivalent of soft-hyphens
  Rossen: Is that a reason to hold off on the proposal?
  florian: I think it's weird to have a toggle for something
  florian: that we can't do yet
  fantasai: We slice if it doesn't fit
  florian: but we might want different if it is forced or not

  JonathanNeal: Seems to be refinements of break-inside to me
  JonathanNeal: so sub-properties of break-inside
  <florian> +1 to jfkthame
  fantasai: We don't control where you can break via break-inside
  fantasai: break-inside, so far, is only whether you can break or not
  fantasai: I think this is a good separation to have

  myles: Also, there are two values, bottom and top
  myles: If the sum is bigger than 100%, what happens?
  fantasai: Can't break anywhere
  florian: But then you are back to the case where you have to
           differentiate whether you are in the normal case or the
           error case
  fantasai: If needed you slice wherever (if the unbreakable item
            is larger than the fragmentation container)
  myles: In the case I described, we would not slice though, right?
  fantasai: You slice

  myles: I am confused
  myles: let me restate
  <myles> you have an image that's 100px tall
  <myles> the fragmentainer is 75px tall
  <myles> and you use both of these properties to say "don't break
          within 80px of the top and don't break within 80px of the
  <myles> <fin>
  <myles> this would overflow, right?
  Rossen: (btw we only try to decide if we want to work on this, don't
          need to have all the details nailed in)
  fantasai: Several things happen
  fantasai: Let's start with 120px fragmentainer
  fantasai: In that case, we move the image to the next fragmentainer
  fantasai: Now, if the fragmentainer is smaller as you said
  fantasai: we are going to ignore the restrictions
  fantasai: so we do slice at 75px
  fantasai: though in theory, the UA is allowed to break anywhere
  fantasai: There is a further proposal to add toggles for this, but
            this would remain an opt-in
  fantasai: by default we make sure all the content is rendered
  myles: Got it

  Rossen: So, do we feel we want to pursue this?
  Rossen: and add to break-4
  Rossen: Any objection?

  RESOLVED: Work on a mechanism to control where slicing is allowed as
            a length from either side of the monolithic element

Controlling fragmentation of block-level replaced-elements
  github: https://github.com/w3c/csswg-drafts/issues/3404

  fantasai: The issue is that, for replaced elements, we can't control
            whether they are breaking or not
  fantasai: We would like to add a control to say "hey, even if you
            could avoid slicing, you don't need to"

  fantasai: The proposal was to add a new property for this
  fantasai: I would rather add a value for break-inside
  fantasai: then if you specify new "allow" value, we trigger this
  fantasai: auto is avoid for replaced and allow for non-replaced
  fantasai: In the future, we can also add "never" which is not like
            "avoid" because it doesn't even slice, it justs get clipped
  fantasai: This should be a different issue though, let's walk back
  fantasai: I would like to propose "break-inside: allow" that would
            enable to slice a replaced element

  florian: We should accept this, otherwise what we accepted in the
           previous issue doesn't make much sense
  florian: so I am in support
  Rossen: Any other thoughts?
  Rossen: Hearing no other remark, let's call for objections

  RESOLVED: Add "break-inside: allow" to enable slicing of images even
            if they could fit in the next page

  fantasai: Can we discuss the "never" value?
  fantasai: I would like to suggest taking this here
  fantasai: We add "never" which prevent slicing if slicing would be
            necessary, and then we just clip
  fantasai: It's fine because it's an opt-in
  Rossen: Do we want to resolve this now?
  Rossen: The name "never" seems a bit too strong
  florian: That's not the meaning of never we want here
  fantasai: We just overflow and clip
  myles: The last issue we said the reverse
  florian: Yes, that is the 'avoid' behavior
  florian: The proposal is to add a new behavior

  faceless2: But you have to print it right?
  faceless2: Engines don't slice an image now
  fantasai: I am pretty sure it's not true
  fantasai: 'avoid' allows to slice across pages as a last resort
  florian: This proposal is to disallow that
  <jfkthame> +1 to florian

  Rossen: The name confused me
  Rossen: but this could be lack of caffeine
  Rossen: Do we really want to take this now?
  Rossen: It's a break 4 thing, let's maybe open a new issue
  Rossen: unless fantasai you feel strongly we should resolve now
  fantasai: No we don't need to, but it would be nice
  Rossen: And the resolution we just took covers that no?
  fantasai: No it's a different behavior. We discussed allowing things
            to break without avoidance, that currently avoid breaking
            (by moving to a next page first). The other option
            discussing now is to forbid breaking.
  Rossen: Ok, let's resolve on keep working on this
  Rossen: but with keyword tbd

  myles: Reading through the thread, one of the issue is that there
         are no example use cases
  myles: and I think it would be useful to have them, because we could
         hit cases
  myles: like what you can fit in the first column would be 1px
  myles: so we should think about this more

  Rossen: The way I'm perceiving this is very similar to ink-overflow,
          it's just decorative like it's an image but it works like a
          shadow or something
  Rossen: I need that decoration to take some space, but when printing
          I don't care about it
  Rossen: At least that's what I understood
  Rossen: but I don't know how frequently this is needed
  florian: If that's the use case, you don't need that behavior
  florian: because you don't want to push if possible to the next page
  myles: Yes, in this case, you don't want the decoration at the top
         of the next column
  myles: so this is not what we described there
  florian: Ok, let's open a new issue to review use cases
  Rossen: Let's move to the next issue

CSS Overflow

CSSOM scrollWidth/scrollHeight behaviour of “overflow: clip”
  github: https://github.com/w3c/csswg-drafts/issues/5572

  Rossen: iank raised this and emilio last added to the agenda
  Rossen: Who want to bring us up to speed?
  emilio: Me.
  emilio: We considered what scrollWidth/Height should return when
          overflow:clip is set
  emilio: there is no scrollbar
  emilio: but there is content out there (invisible)
  emilio: The question is should we return the size as if there was

  emilio: I think acting as visible is easier
  emilio: but iank said there is an optimization if we don't include
          any of the overflow
  <TabAtkins> +1 to behaving the same as visible, at least from first
  iank: If you have overflow:hidden, can be scrolled
  iank: For visible, it still makes sense to return the full value,
        because it will cause scrollbars on ancestors
  <TabAtkins> Hm, okay, Ian's making sense
  iank: When you clip though, it's not useful, because it really does
        not exist
  iank: but if you don't do that, you can return early
  iank: because you don't need to calculate the scrollable overflow
        for the element when the value is fetched
  iank: but it's not super important and only works if clip is in both
  smfr: The other option was what?
  iank: Report as if you had no children
  iank: If the size is definite and you clip overflow, you don't need
        to layout the children
  iank: but it's a small case
  smfr: And offsetWidth/offsetHeight?
  iank: Yes, this is the same as what I had in mind
  smfr: Oh, in that case, yes, I prefer that option slightly

  Rossen: Other opinion?
  iank: If I had to choose I would probably try to keep things
        consistent, but I really don't mind
  iank: We just need to do something
  Rossen: Ok, let's get a summary of the two options and resolve
  iank: Option 1 is to do what we do when overflow:visible is applied (
        you need to layout the children to report that width)
  iank: Option 2: (ignoring overflow-clip-margin) report the size of
        the element ignoring whether or not you have something that
        will be clipped
  iank: but if you have a clip margin, you need to do the full
        computation to see where inside that margin you land
  Rossen: (restates the two proposals)

  fantasai: scrollWidth scrollHeight are asked on an element which is
            not scrollable
  fantasai: Does that mean they are defined on all elements?
  emilio: Yes
  fantasai: Ok, then, if we have a clipping, what happens if you have
            a border?
  iank: They return content-box sizes, so it's a bit complicated
  fantasai: Padding box you mean?
  iank: Yes, padding box size
  iank: If you have no children, this is clientWidth/clientHeight,
        which is the padding box
  iank: If you have a child, it returns whichever is bigger (the
        padding box or that child)
  iank: So if you set overflow:clip with no margin, you can return the
        padding box because the child will not overextend
  iank: but this only works if you don't have a margin
  iank: If you have a margin, there could be an overflow
  iank: so you need to do the full computation

  fantasai: The advantage of doing like visible is that you get
            the value that tells you "how big should it be not to
  fantasai: The advantage of taking the clip into account, is that you
            know how much you will ask the parent scroller
  iank: With proposal 2 you can't get answer 1
  iank: but with proposal 1 you can compute the difference yourself

  Rossen: This seems more clear now
  Rossen: For "what you see is what you get" option 2 is nicer
  Rossen: I don't want to do a straw poll, let's try to resolve
  Rossen: Can we resolve on option 2 which takes into account the
          visual clipping?

  emilio: I lean towards option 1
  emilio: because I don't see strong arguments
  emilio: and for testing purposes, we can copy all the tests
  emilio: and we have shipped like that
  emilio: But this is not a super strong argument
  emilio: but given option 2 removes your ability to get the value of
          option 1
  emilio: I would rather we did 1
  Rossen: If you want to get the bounds for the clip, what do you do?
  iank: In script, you get the style of the clipping, then you do
  iank: between scrollWidth and offsetWidth + the clip margin
  Rossen: Authors might not think about it
  Rossen: and very often it's more useful to consider what is visible
  emilio: I don't disagree it's useful
  emilio: but scrollWidth is not the right API for that
  emilio: It's weird and legacy, so I would rather not change it
  Rossen: ok let's do a poll
  Rossen: because it's pretty split

  <fantasai> Given the arguments in favor of emilio's position, and
             the fact that you can get answers to the second question
             fairly easily with the first option but not the other way
             around, I'd be in favor of emilio's position

  smfr: If we have scrollWidth not behave like overflow:visible
  smfr: then you can't get the data and know if you can flip to
        visible without overflow
  fantasai: Yes, option 2 hides info from authors you can't get
  fantasai: It's not great
  Rossen: Pk, then let's resolve for option 1

  RESOLVED: scrollWidth/scrollHeight ignore overflow:clip when
            computing the value

CSS Display & CSS Pseudo Elements
  scribe: florian

Existence of ::marker::marker
  github: https://github.com/w3c/csswg-drafts/issues/1793

  <fantasai> https://github.com/w3c/csswg-drafts/issues/1793#issuecomment-708072107

  fantasai: This is a follow to previous decisions on ::marker
  fantasai: we didn't want to have infinite markers
  fantasai: so you cannot have ::marker::marker
  fantasai: Right now ::marker doesn't accept the display property,
            so can't anyway.
  fantasai: But, is ::marker::marker invalid?

  fantasai: And, in the future, if we want to allow display on ::marker
  fantasai: then do we force it to compute 'display' so that it loses
            its 'list-item' keyword?

  Rossen: So, taking things one at a time, should we allow
  fantasai: I'd like to make it invalid
  TabAtkins: Browsers don't support it
  <tantek> +1 on no ::marker::marker
  oriol: Implementations are behind flags, so not too relevant
  oriol: In firefox, no nested pseudos
  oriol: In chrome ::before::marker and ::after::marker work, but
         ::marker::marker doesn't
  oriol: but then the styles don't quite work anyway
  oriol: so I'd prefer to keep it invalid
  Rossen: Any objection to ::marker::marker being invalid

  RESOLVED: ::marker::marker is invalid

  fantasai: In the future, when display applies to ::marker, should it
            lose the list itemness
  oriol: Seems reasonable
  Rossen: Me too

  RESOLVED: Computed 'display' on ::marker drops 'list-item' keyword

  scribe: TabAtkins
  scribe's scribe: fantasai

Allow specifying the "accent color" of a form control element
  github: https://github.com/w3c/csswg-drafts/issues/5187

  masonfreed: Summary is I closed the "interoperability thread" -
              question I was trying to ask was whether we wanted
              precise control over where accent colors should go on a
  masonfreed: Think I got the answer I needed - we don't want to do so.
  masonfreed: Majority opinion seems to be that we want this to be
              more of a hint to the UA - "accent-color: purple" means
              "use purple on this control if you can if it makes
  masonfreed: Not "put this purple on the checkbox background", more
              of a hint instead
  masonfreed: So I'd like to get a resolution from the group on this

  TabAtkins: I'm not sure this is exactly the right direction, fine
             with it as long as we adopt something like what fantasai
             said, where we require the UA's chosen colors contrast
             appropriately with the accent-color
  TabAtkins: UA can't put black on black if you specify
  TabAtkins: With that, sounds fine
  Rossen: You can't ignore the accent color?
  fantasai: Can always ignore it...

  jensimmons: I think the way Mason described is really good, more
              realistic to where we are
  jensimmons: More time to solve the problem of robust styling
  jensimmons: Allows us to give authors something useful and gives us
              time to solve the problems more robustly
  florian: Roughly in line with all that. As long as the hint involves
           the requirement that contrast must work.

  florian: Don't think we have a resolution on one vs many colors, but
           we can decide that later
  florian: I think there is an appetite for precise control, but that
           requires a more robust solution. Should do that too, but
           shouldn't conflate with this.

  Rossen: Taking the lack of queue as meaning we've said everything we
          need. Objections?
  Rossen: proposed resolution: adopt accent-color as a hint to the UA,
          with requirements on contrast
  <tantek> I think we're ok with that too

  RESOLVED: Adopt accent-color as a hint to the UA, with requirements
            on contrast

  masonfreed: We probably need to discuss the 1 vs many colors
              question later
  Rossen: yes
  fantasai: I think we should put this into UI 4, should we let the
            editors put that in, and discuss 1 vs many colors
  astearns: Would Mason like to become an editor?
  masonfreed: "want" is strong, but I'm willing to do it
  florian: Happy to have help
  fantasai: There is proposed text already
  Rossen: Objections to adding Mason as UI 4 editor?

  RESOLVED: Mason Freed added as UI 4 editor

Pseudo Elements

::selection vs ::inactive-selection
  github: https://github.com/w3c/csswg-drafts/issues/4579

  fantasai: We'd talked about replacing the selection/
            inactive-selection distinction with a MQ for whether the
            parent window is inactive
  fantasai: So question is if we're actually doing that, should I
            remove ::inactive-selection from Pseudo and open an MQ
  florian: Seems good, but it seemed there was an active question
           about how much nuance there is about active vs inactive
  fantasai: It seemed commented that we could get by with just the
            two, but we can make this an issue for the WG.
  TabAtkins: Since impls don't have ::inactive-selection anyway, we
             can decide that later?

  GameMaker: Looking at the PDF at the bottom, I made a comparison of
             all browsers
  GameMaker: Can't recall exact thoughts at the time, but based on
             these results, I was fine with making a MQ

  Rossen: So what's the proposed resolution?
  fantasai: Removed ::inactive-selection from Pseudo 4, and add an
            issue on MQ to add an active-window media feature
  Rossen: Objections?
  florian: Are we removing it while we're thinking about it, and it's
           gone? Or will we maybe put it back?
  florian: Asking because we have tests for this - should I mark as
           tentative, or delete?
  fantasai: Mark as tentative until we're totally finished on this
            issue. Good chance we can just revise them later

  RESOLVED: Remove ::inactive-selection from Pseudo 4, and add an
            issue on MQ to add an active-window media feature
Received on Wednesday, 4 November 2020 14:53:01 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 4 November 2020 14:53:02 UTC