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

[CSSWG] Minutes Fukuoka F2F 2019-09-17 Part VII: CSS Text & Sizing, CSS Fonts, MathML, ScrollTimeline, CSS Text, Transforms, CSS Tables [css-text] [css-sizing] [css-fonts] [css-text] [css-transforms] [css-tables]

From: Dael Jackson <daelcss@gmail.com>
Date: Tue, 3 Dec 2019 18:16:35 -0500
Message-ID: <CADhPm3vtRuKONrNuPs=RaSWH39xEs08TsOxaSD1TGq-C35rG9Q@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 Text & CSS Sizing

  - RESOLVED: Accept the proposal in

CSS Fonts (Continued)

  - RESOLVED: Add them with the `ui-` prefix and make them not match
              if they're not available (Issue #4107: system-ui fonts)


  - The MathML spec is almost complete and includes its CSS
      integration: https://mathml-refresh.github.io/mathml-core/
  - Anyone with issues should open them against the spec now.


  - RESOLVED: Move scroll-timeline (
https://github.com/WICG/scroll-animations/issues/51 )
              into csswg-drafts

CSS Text

  - Florian presented the current state of the word space insertion
      proposals; there were some concerns about CSS doing the automatic
      insertion feature (due to complexity of linguistic analysis,
  - There wasn't a decision on issue #4297 (Hanging spaces cannot be
      scrollable overflow) because there's a desire to avoid magic
      when explaining how the browser allows access to these spaces.


  - RESOLVED: Publish CR of css-transforms

CSS Tables

  - RESOLVED: Any math expression of a complex type is treated as
              auto. Simple typed things continue to work as today.
              (Issue #94: calc for table layout)


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

Scribe: emilio
Scribe's Scribe: heycam

CSS Text & CSS Sizing

When to/not to include preserved trailing spaces
  github: https://github.com/w3c/csswg-drafts/issues/3440#issuecomment-530702998

  fantasai: [summarizes situation]
  fantasai: proposal is to accept the proposal in
  fantasai: I think we should resolve on that
  florian: I think koji is ok with it now
  Rossen: Objections?

  RESOLVED: Accept the proposal in

CSS Fonts

system-ui fonts
  GitHub: https://github.com/w3c/csswg-drafts/issues/4107

  <fantasai> This is my position:
  myles: Should we expose these like any other font like "Times new
         roman" or as a keyword like a generic font family, which
         other browsers would also implement and whose behavior would
         change across OSes... ?
  myles: I'd prefer the later
  fantasai: (explains her position above)
  fantasai: tldr it makes sense to have system-ui keywords, but they
            should be exposed also behind an actual font name
  myles: It's impossible for us to determine whether people want them
         because the fonts are nice or because they're systemy
  Rossen: How are you going to determine it?
  Rossen: Expose it with a proprietary name and you're done

  koji: I think regardless of exposing them via the name I think
        there's use case for the keywords
  florian: I think they should be exposed by name, and if after that
           there's still users asking for that then we're done
  florian: but just font families is not the only thing for emulating
           the system
  myles: But it's a required part of matching the system, regardless
         of the rest of the design
  florian: It doesn't seem helpful to use system-ui vs. named, if you
           can just ua-sniff and set the font name
  dino: It may help authors in other systems too

  koji: We learned from system-ui that authors don't want the exact
        same font as the system
  koji: On windows server a bunch of big pages didn't want the system
        font which was tahoma, they wanted segoe instead
  Rossen: That's why when we released segoe we did it as a font with
          a real font name, not as a special keyword
  florian: That's interesting, so this is appropriate in the sense
           that people wants ui fonts, but not necessarily the system's
           ui font
  myles: So ui-serif rather than system-ui-serif?
  florian: If that's the use case that sounds fine

  nmccully: Having a shorthand seems useful to guarantee that the font
            is current, is there, and not have to worry about the list
            of system fonts

  myles: So it seems we're coalescing to add `ui-rounded`, `ui-serif`,
         `ui-monospace`, ...
  florian: I'd also also encourage apple to expose them by name
  nmccully: That seems useful
  myles: ok, we'll do both

  florian: Less sure about *-rounded
  fantasai: What do we do for `ui-rounded` if there's no rounded font?
  fantasai: Maybe you have only arial and times?
  fantasai: What do you fall back to?
  florian: I'd propose just for it not to match so it falls back to
           the next of the list

  leaverou: If we need more granularity to system ui fonts why mapping
            them to apple?
  leaverou: why not system-ui-titletext?
  myles: When a platform has a different font for titletext we can
         consider that

  RESOLVED: Add them with the `ui-` prefix and make them not match if
            they're not available


  <bkardell> https://mathml-refresh.github.io/mathml-core/
  bkardell: Just letting everybody know that the spec considerably
            complete, and so is our initial implementation
  bkardell: Lots of wpt, lots of answers in the spec
  bkardell: total css proposals amount to four:
  bkardell: one of them is `display: math`
  bkardell: other three is to display the information that you need to
            extend mathml
  bkardell: We intend to send an intent to implement in October to
            upstream it so please open your issues and ask your
            questions and help us make that successful
  iank: mathml cg has decided on some of the mathml / css integration,
        it'd be great to take a look at those

  github: https://github.com/WICG/scroll-animations/issues/51

  majidvp: Last f2f I explained the 2 big issues that remained, the
           css syntax and the problem that the spec only accepts
           concrete scroll offsets and such and most use cases rely on
           viewport offsets and such
  majidvp: so we got lots of feedback from devs that it's hard to
           compute the right offsets
  <fantasai> basically, same problem as scroll-snap had in the

  majidvp: So we want to propose some changes to scroll timeline to
           make the scroll offsets not specified but match
           intersection of boxes or such
  majidvp: flackr has done a polyfill for that and the api
  majidvp: What we're proposing here is specifying offsets in terms of
           intersection observer semantics
  majidvp: which is start and end of animation as intersection
           observer offsets
  majidvp: Just one-dimensional rather than two-dimensional
  majidvp: [goes through the proposal in
https://github.com/WICG/scroll-animations/issues/51 ]

  majidvp: We're also proposing a function-like syntax
  majidvp: but let me show demos
  majidvp: [goes through
https://flackr.github.io/scroll-timeline/demo/parallax/ ]
  majidvp: [goes back to the proposed css syntax]
  majidvp: There are some open questions like how to fix the
           circularity in the case layout moves the element while
  majidvp: Proposal is to freeze the offset when the animation starts
  majidvp: also how intersections are computed and such
  majidvp: These are open questions that we're trying to work through
  majidvp: Not proposing concrete solution
  majidvp: happy to answer questions / feedback / concerns

  smfr: I like the way it generally looks, and I like the
        IntersectionObserver thing
  smfr: seems much more natural
  smfr: Can you do something like a spinner that stops as soon as soon
        as you scroll away?
  majidvp: ScrollTimeline should not solve that, you need a trigger
           for that...
  majidvp: I don't wanted to fix that use case here, but maybe a
           `:visible` pseudo-class or a CSS intersection observer like
  iank: You can polyfill that already with intersection observer, I
        think it's nice to keep it focused
  dino: I think this would be a simple addition now that we have the
        range to address this use case
  smfr: There's also the case where you stop the animation but let it
        run to complete a cycle
  smfr: so that it comes back into the viewport in a good position
  majidvp: May be addressable with the range

  smfr: Another piece of feedback is that it seems that the css api is
        getting a bit out of control
  smfr: I'd be fine with just a JS api
  majidvp: That's the opposite of the last F2F discussion, but it's
           fine for me...

  heycam: The small additions to the Intersection Observer model, they
          should just be added to Intersection Observer itself
  majidvp: I think they should be added to the spec even if they're
           not web-exposed.
  heycam: It'd be nice especially if you don't solve the time-based
          viewport-triggered animation
  majidvp: I _think_ you can compute that with the current
           IntersectionObserver given it provides the intersection area

  Rossen: Looks awesome, what are you asking from us?
  majidvp: Confirmation of general direction would be great
  majidvp: May be nice to bring into csswg-drafts, though may not be
           that important
  Rossen: I think we could do that
  smfr: Where does web-animations live?
  birtles: CSS

  RESOLVED: Move scroll-timeline into csswg-drafts

CSS Text

Update on word space expansion

  <florian> https://drafts.csswg.org/css-text-4/#word-boundaries
  florian: At the last f2f I presented a proposal to expand zero width
           spaces into ideographic spaces
  florian: I got spec text after the group discussion
  florian: Another request was to automatically insert them into the
  florian: Got review from fantasai and (less) i18n
  florian: i18n was working on line-breaking of Thai text, which needs
           some analysis on the text, which is not right all of the
  florian: since you can use Thai alphabet to write non-Thai languages
  florian: So the group wanted to be more explicit about line-breaking
           in Thai, which is similar to the word boundary injection
           feature we discussed
  florian: That's all in text-4, it'd be nice for you to review it
  florian: Will start to write text soon, may tweak naming

  florian: fantasai was a bit skeptic about the automatic insertion
  florian: about whether browsers will implement language-dependent
  florian: I think kindle did that, though kindle does have a bounded
           number of languages unlike browsers
  glenn: I'm with fantasai, don't do it, many business do this


Republishing transforms CR

  <Rossen> https://drafts.csswg.org/css-transforms/#CR20190214
  krit: We got some editorial changes
  krit: I don't expect a lot more changes to the spec
  krit: so I expect to be the last CR before the next step

  RESOLVED: Publish CR of css-transforms

CSS Tables

Calc for table layout
  Github: https://github.com/w3c/csswg-drafts/issues/94

  xiaochengh: So the issue is what to do with percentages and calc
  xiaochengh: Spec says a bunch of stuff may be treated as auto
  <fremy> "Given the complexities of width and height calculations on
          table cells and table elements, math expressions involving
          percentages for widths and heights on table columns, table
          column groups, table rows, table row groups, and table cells
          in both auto and fixed layout tables MAY be treated as if
          auto had been specified."

  xiaochengh: I'm proposing changing the MAY into MUST
  xiaochengh: It's pretty complicated if we don't treat it as auto
  xiaochengh: Second reason is that this is creating friction when
              implementing min() / max()
  xiaochengh: calc() is complicated, but min() / max() make it a
              pretty hardly solvable problem
  xiaochengh: so I propose to make this a MUST
  TabAtkins: This is what dbaron noted back in the day
  TabAtkins: and we punted min and max because of that

  heycam: Implementation status?
  fremy: All browsers match the spec
  fremy: for normal table layout
  fremy: The algorithm just doesn't make it possible
  fremy: In fixed table layout there's one browser that supports
         percentages based on the size of the table
  fremy: As to the question of whether we should remove the behavior
         for normal table layout is fine
  fremy: for fixed layout it'd be nice to also remove it, but Chrome
         and Safari
  fremy: Do respect it so it'd be nice to remove that
  fremy: or add to the spec that it is respected in fixed table layout
         and how, which should be straight-forward

  emilio: There's also the question of whether we should in presence
          of min and max...
  emilio: Firefox used to treat calc(%) as auto
  emilio: We no longer do that
  emilio: but it raises the question of how min and max behave with
          only percentages
  emilio: I guess that's fine to resolve?
  TabAtkins: I don't want to special case min and max on type
  TabAtkins: That's awkward
  TabAtkins: Having min and max work in some case if you have certain
             shapes of expression inside of it
  emilio: I think given the way we behave, all browsers treat calc
          with percentages as a percentage, we should do the same for
          min and max
  fremy: That sounds reasonable to me

  fremy: If there is a sum of % and px, after you've computed, then
         you decide not to do anything, follow the MUST
  fremy: If you have min(10%, 20%), the computed value will be 10%, so
         you don't have the problem
  fremy: I would be in favor of that wording
  emilio: What about calc(10% + 0)?
  emilio: That's simplifies to 10% in all browsers
  Rossen: Yes we've resolved that previously
  fremy: So what about fixed mode
  fremy: I assume it's probably fine to apply this rule to both?

  RESOLVED: Any math expression of a complex type is treated as auto.
            Simple typed things continue to work as today.

  TabAtkins: https://github.com/w3c/csswg-drafts/issues/3482#issuecomment-451590359
  <TabAtkins> calc(0% + 0px) is, per spec and Typed OM, absolutely a
             {length: 1, percentage:1} type.
  zoe: no objections

CSS Text

Hanging spaces cannot be scrollable overflow
  Github: https://github.com/w3c/csswg-drafts/issues/4297

  florian: fantasai points out that if we treat hanging spaces as
           scrollable overflow there's a bunch of cases where we got
           scrollbars where we don't want
  florian: but on editable stuff you want to create scrollable overflow
  florian: blink and webkit agree with me, gecko always treats it as
           ink overflow, edge always layout overflow
  florian: Proposed resolution is treat hanging spaces as ink overflow
           in general but layout overflow in editable context

  fremy: How did you test for editable context
  fremy: You may be testing a different `white-space` due to UA rules

  emilio: It feels weird to special case layout based on editable
          context, whatever that is
  Rossen: Why?
  emilio: There's no good reason for the layout engine to know the
          editable state of the DOM
  emilio: In Gecko this all works via UA sheets
  emilio: We change a bunch of stuff when something becomes editable,
          but it's explained through CSS properties
  emilio: Specifying something like this seems quite awkward
  florian: Make it specific to contenteditable only, and not other
           kinds of editable, would be weird
  florian: but if it's all kinds of editable, and good old fashioned
           textarea, ....
  <leaverou> But it can be detected with CSS selectors
  emilio: If you do that, I would prefer to have some kind of CSS
          value that causes this effect
  emilio: and specify in HTML or wherever that contenteditable and
          textarea input have this in the UA sheet
  florian: If you are editing the content, you never want to not reach
           the content
  florian: If you are trying to edit/delete them, if the cursor moves
           where you can't see it, that's not desirable
  emilio: Then the UA sheet can have an !important rule
  florian: If we define this how is it magical?
  emilio: What if it's something slotted into a contenteditable

  fantasai: The main thing that's happening here, if spaces are
            overflowing in the document, you don't want to create
            scrollbars for them
  fantasai: When you're editing text, it's nice to be able to see the
  fantasai: I don't think authors care. Don't think adding a CSS
            property, increasing the number of things authors could
            learn, is a benefit here
  emilio: Sure
  fantasai: It makes sense to allow the UA to make it scrollable
            overflow when that piece of text is editable
  fantasai: How you got to that state, doesn't really matter
  emilio: Why only when it's editable, and not selectable?
  emilio: The caret movement is pretty much the same
  emilio: Don't know why those would be different
  fantasai: The characters are still there, you can select if you go
            from one line to the next
  fantasai: but there's a higher priority on not introducing scrollbars
  emilio: Can we confirm Chrome is doing what you claim it is?
  florian: Elika pointed out, if this is awkward to do on the C++
           thing, you can have the dedicated CSS value, and make it
           !Important, and not accessible to users
  emilio: I know how to implement it, just don't want it defined in a
          magical way

  -- end --
Received on Tuesday, 3 December 2019 23:17:29 UTC

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