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

[CSSWG] Minutes Telecon 2019-05-09 [css-text] [css-size-adjust] [css-pseudo-4] [css-lists] [css-scroll-snap-1] [cssom] [css-overflow]

From: Dael Jackson <daelcss@gmail.com>
Date: Thu, 9 May 2019 07:11:21 -0400
Message-ID: <CADhPm3unYmwy0O38e1n4VEmY+oSYUXeHq3MAEKFtE+eq7W-2ww@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.
=========================================


Toronto F2F
-----------

  - Anyone attending should add their names to the wiki

CSS Size Adjust
---------------

  - The spec needs more attention before it's ready for FPWD.

CSS Text
--------

  - RESOLVED: Inline box boundaries don't affect line breaking
              opportunities (Issue #3886)
  - RESOLVED: Fixed width spaces U+2000 and up are treated like U+0020
              and U+3000 -- hang / disappear at end of line (Issue
              #3879)
  - There was disagreement on how tabs should be handled in pre-wrap
      (Issue #3869) so Florian will add examples to the github issue
      of what tabs are used and what the options are for handling them.
  - RESOLVED: out-of-flows don't affect hyphenation (Issue #3862)

CSS Pseudo
----------

  - RESOLVED: Add .pseudo() to CSSPseudoElement once some stacked
              pseudo combination becomes a valid selector. Adjust
              .element return type to match. (Issue #3836)

CSS Lists
---------

  - RESOLVED: Don't expand the list of properties that apply to
              ::marker (Issue #3826)

Scroll Snap
-----------

  - RESOLVED: Use the writing mode of the container (Issue #3815:
              Clarify which writing-mode is used for
              scroll-snap-align, scroll container or snap position
              element?)

CSSOM
-----

  - RESOLVED: Spec these methods, mark them deprecated, add ADVISEMENT
              to authors to not teach or use (Issue #3814: webkit/
              blink methods on CSSStyleSheet)

CSS Overflow
------------

  - RESOLVED: For flex and grid, margins contribute to overflow (Issue
              #3653)

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

Agenda: https://lists.w3.org/Archives/Public/www-style/2019May/0003.html

Present:
  Rachel Andrew
  David Baron
  Amelia Bellamy-Royds
  Christian Biesinger
  Oriol Brufau
  Emilio Cobos Álvarez
  Benjamin De Cock
  Elika Etemad
  Tony Graham
  Peter Linss
  Anton Prowse
  Melanie Richards
  Florian Rivoal
  Jen Simmons
  Lea Verou
  Sean Voisen
  Fuqiao Xue

Regrets:
  Rossen Atanassov
  Daniel Bates
  Tantek Çelik
  Simon Fraser
  Dael Jackson
  Brad Kemper
  Manuel Rego Casasnovas
  Alan Stearns
  Greg Whitworth

Scribe: fantasai

Toronto F2F
===========

  dbaron: If you're planning to come to Toronto, please add yourself
          to the wiki
  dbaron: and update whether you're coming to Houdini
  dbaron: and also dietary requirements, please email me
  <jensimmons> Link: https://wiki.csswg.org/planning/toronto-2019#participants

CSS Size Adjust
===============

  plinss: FPWD?
  florian: Looking at the spec, seems like there are some issues that
           we should handle before FPWD
  dbaron: I was hoping to add some more before FPWD
  dbaron: Admittedly, it's been a long time and I haven't done that...
  xfq: FPWD is usually that the WG has consensus to work on the spec
  fantasai: A little more than that: agreement to work on it, but also
            that the general direction of the draft is acceptable
  myles: This is text-size-adjust, right?
  myles: We're interested in working with WG to standardize
  myles: can't commit any time in the short term tho
  AmeliaBR: Any IP reasons to get the call for exclusions out?
  [silence]
  florian: Issue 1 in the spec says that the subsection requires
           checking whether the section is correct
  florian: Giving further status to the spec risks confusing people
           rather than helping

  florian: Like to get to FPWD, but maybe not there yet. How do we get
           there?
  dbaron: If Apple folks can help in the medium term, that's helpful
  dbaron: What's in the draft is roughly what we had figured out for
          Gecko as of awhile ago
  dbaron: But Gecko impl may have changed a bit since then
  dbaron: I'd be inclined to wait and make some progress in the future
  dbaron: Maybe at F2F
  myles: I'm happy to talk offline

CSS Text
========

Inline boundaries and wrapping
------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/3886

  florian: out-of-flow elements don't introduce a soft wrap opportunity
  florian: But doesn't say about inline boundaries
  florian: We have a WPT test for this, but not backed by spec
  florian: In the past Chrome had a bug where inline element
           boundaries suppressed wrap opportunities
  florian: Now sometimes have opposite bug that inline boundary
           introduces wrap opportunity
  florian: Any push back that putting a span around things doesn't
           change where line breaks can happen?
  fantasai: No, we should definitely spec this
  fantasai: "Inline boundaries don't affect line breaking
            opportunities"

  RESOLVED: Inline box boundaries don't affect line breaking
            opportunities

Hanging/collapsing fixed-width spaces
-------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/3879

  florian: Spaces ...
  florian: Currently only U+0020 and U+3000 are able to hang
  florian: But other fixed-width spaces don't
  florian: don't know if there was a specific reason not to include
           them, or some kind of oversight
  fantasai: I think we knew that nbsp couldn't hang
  fantasai: so we only had U+0020 hang
  fantasai: Later on added ideographic space in response to feedback
            from Japan
  fantasai: Didn't re-evaluate other fixed-width space

  florian: Compat risk?
  fantasai: Probably low, most people don't know they exist
  fantasai: I'd be willing to change the spec and see how it goes
  fantasai: We'll need to except nbsp
  fantasai: Also ogham space mark?
  florian: There's about whether spaces can hang at the end of the
           line in pre-wrap
  florian: Separate question of whether they disappear when wrapping
           'white-space: normal'
  florian: Not sure how to deal with ogham
  fantasai: Will have to as i18n
  <fantasai> http://www.fileformat.info/info/unicode/category/Zs/list.htm

  RESOLVED: Fixed width spaces U+2000 and up are treated like U+0020
            and U+3000 -- hang / disappear at end of line

Pre-wrap and tabs
-----------------
  github: https://github.com/w3c/csswg-drafts/issues/3869

  florian: Also came up writing tests ...
  florian: We say what happens to spaces at the end of the line. We
           don't say what happens to tabs.
  florian: I suppose the same thing happens, but spec doesn't say
  florian: Spec describes tabs rendered as a shift, not a visible thing
  fantasai: Certainly if spaces after the tab, should be rendered as a
            shift
  fantasai: but at the end of the line, wouldn't be surprised if they
            disappeared
  ...
  fantasai: Definitely treat the same as spaces for break-spaces
  fantasai: not so sure for others
  myles: I agree with Florian, treat it like spaces.
  myles: It's a Unicode character just like any other
  fantasai: Its size changes depending on its position in the line
  florian: Spec allows UA to compress their width to zero at the end
           of the line, could do that with tabs also
  fantasai: That won't be allowed in L4 though

  fantasai: ... wrt myles's point about font shaping, characters
            change shape depending on context
  fantasai: But not depending on their position within the line, which
            is what tabs do
  ...
  fantasai: I'm not really sure what should happen, but I lean towards
            tabs not being allowed to hang
  fantasai: Partly for that, partly because they are quite large = 8
            spaces by default
  florian: But you want your caret to be visible if you put it after
           the tab
  AmeliaBR: Tabs at the end of the line are rare. Also if you want to
            edit, you want to be able to see them.
  myles: Don't want too many special cases
  plinss: Tabs are used for delimiting things. Shouldn't disappear.
  fantasai: Who's saying anything about disappearing? I'm saying they
            shouldn't hang. Doesn't mean they disappear
  fantasai: Treat it just like a visible character, it causes text to
            wrap to the next line.
  fantasai: Hanging allows things to overflow even when there are
            sufficient wrapping opportunities in the line to not
            overflow
  myles: Tabs are more like spaces than visible characters
  florian: Like spaces or nbsp?
  AmeliaBR: Maybe continue this discussion in the issue, write out the
            options and add examples of how that would work for use
            cases e.g. editing text, viewing tab-delimited data, etc.

  ACTION Florian write up options
  <trackbot> Created ACTION-878

Unstyled inlines vs hyphenation
-------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/3862

  florian: We resolved that unstyled inlines don't affect how
           hyphenation work
  florian: But forgot to ask about out-of-flow
  florian: For all other places in this spec where we say inlines
           don't have an effect, say the same thing about out-of-flow
  florian: So consistency seems good
  fantasai: I think it shouldn't
  myles: Linguistically that's wrong

  RESOLVED: out-of-flows don't affect hyphenation

CSS Pseudo
==========

CSSPseudoElement having a pseudo() method
-----------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/3836

  AmeliaBR: Seems to make sense to me, if a pseudo-element can have a
            pseudo-element, then having .pseudo() would make sense
  emilio: Have we decided yet how to make those styleable
  fantasai: Will be stylable with selectors like ::before::marker
  emilio: I would wait to add this method until that is allowed

  fantasai: So proposal is to add .pseudo() to CSSPseudoElement once
            stacked pseudo becomes a valid selector
  plinss: Side issue of whether to rename .element to .parent
  fantasai: Not always a parent
  TabAtkins: The full term is "originating element" but that was too
             long
  TabAtkins: So shortened to .element
  plinss: Need to reach pseudo-element between you and the element
  TabAtkins: Yeah, that's what .element would do
  plinss: OK
  TabAtkins: When we adopt this, just the return type would be adapted

  RESOLVED: Add .pseudo() to CSSPseudoElement once some stacked pseudo
            combination becomes a valid selector. Adjust .element
            return type to match.

CSS Lists
=========

::marker vs other pseudo-elements
---------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/3826

  <fantasai> I agree with
https://github.com/w3c/csswg-drafts/issues/3826#issuecomment-483320040
  emilio: I think there was some confusion of whether 'display'
          applies to markers
  fantasai: Display doesn't currently apply to markers
  fantasai: and I don't think it should until marker layout is fully
            defined
  fantasai: and its interaction with display is also defined
  TabAtkins: Mats is arguing for much more than display
  TabAtkins: He's arguing for marker to take all properties, like
             ::before/::after
  TabAtkins: Is there a reason to stop at display or re-litigate after?

  Scribe: florian

  fantasai: The reason we have a limited list of properties is that
            because we don't know how marker layout works
  fantasai: so allowing these properties without knowing what they do
            is bad
  fantasai: We also don't know the size of the box, so any property
            that makes that visible is a problem
  fantasai: We don't know if line-height plays a role... many other
            properties have the problem
  fantasai: There are implementation specific answers, but so far
            they're not exposed
  fantasai: so if we expose them, me might accidentally lock compat on
            whatever ships first
  fantasai: So we should not
  emilio: Makes sense to me, will apply that to firefox
  fantasai: For now we just allow text related properties
  fantasai: eventually we want to relax that, but only after layout is
            defined
  <florian> https://www.w3.org/TR/css-pseudo-4/#marker-pseudo
  <florian> proposed resolution: don't expand the list of props that
            apply to ::marker

  RESOLVED: Don't expand the list of properties that apply to ::marker

  <fantasai> It would probably be OK to add more properties from
             css-text/text-decor
  <fantasai> those that apply to inlines

Scroll Snap
===========

Clarify which writing-mode is used for scroll-snap-align, scroll
    container or snap position element?
----------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/3815

  fantasai: The question is which writing-mode is used for
            scroll-snap-align:start and the container and the
            containee have different writing-modes
  fantasai: The proposal is to use the writing-mode of the container
  fantasai: because that's what we do for alignment properties
  fantasai: We also have the self-start and self-end keywords if you
            want that
  fantasai: That made more sense to align all things the same side in
            a single container
  fantasai: This proposal is motivated by consistency with that
  jensimmons: Sounds reasonable to me
  plinss: Me too. objections?

  RESOLVED: Use the writing mode of the container

  jensimmons: I wanted to thank the group for the great hard work to
              make specs understandable.
  <bdc> (fully agree with jen)
  jensimmons: I have been at conferences, and after struggling with
              other specs, I really want to voice appreciation for
              doing it well as this group does.

CSSOM
=====
  scribes: fantasai and florian

webkit/blink methods on CSSStyleSheet
-------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/3814

  emilio: I got a compat issue report on this
  emilio: I'm planning to implement and spec
  emilio: It is sad that we need them, but it is also easy, so I'll
          just do it
  emilio: Anyone has a strong concern about adding this?

  plinss: I have been advocating for pushing such things to a side
          spec / compat spec
  TabAtkins: No, I want the compat spec to go away, it should be in
             the main spec
  plinss: That encourage new content to use it
  fantasai: We can mark them as deprecated, presented as a footnote,
            make warnings, etc
  fantasai: but still put them in the main spec
  <chris> I agree that deprecation is sufficient guidance for new
          content
  florian: The compat spec tends to have a lot less rigor than the
           mainstream specs have
  florian: It just documents existence of thing, not how it works
  florian: For things that aren't needed, let's not spec them. But
           things that are necessary for web-compat, then we need to
           spec them.
  florian: It's a disservice to implementers to not spec them.
  florian: If it wasn't necessary to implement, we wouldn't be
           speccing at all

  emilio: Regarding fantasai's point, PR just says "legacy features".
          Open to better suggestions.
  plinss: I'm OK as long as clearly marked as deprecated, as fantasai
          described
  plinss: Other thoughts?

  RESOLVED: Spec these methods, mark them deprecated, add ADVISEMENT
            to authors to not teach or use

  florian: When you do this, you can put them at the bottom of the
           spec, so only ppl who read the whole section notice them
  emilio, https://www.w3.org/StyleSheets/TR/2016/readme.html#advisement

CSS Overflow
============

Margins and scrollable overflow
-------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/3653

  fantasai: ....
  florian: For all things where we don't have a legacy constraint, I'm
           in favor of including margins, and this is one of them
  fantasai: For blocks we cannot just include the margins, because
            compat, but for grid and flex we don't have this problem
  fantasai: so when you put overflow on things, and have margins,
            authors expect them to show up
  [fantasai was explaining why spacing specified by the author should
      be included in scrollable overflow -- it's used for spacing, and
      needs to provide that spacing between item and bottom/right
      edges of scroll container]
  [but have compat issues with block containers, would create too many
      unexpected scrollbars; so adapting for grid flexbox only]

  Proposed resolution: for flex and grid, margins contribute to
      overflow

  RESOLVED: For flex and grid, margins contribute to overflow
Received on Thursday, 9 May 2019 11:12:15 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:15:11 UTC