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

[CSSWG] Minutes Telecon 2018-09-19 [css-scrollbars] [css-fonts-4] [css-break] [css-display] [css-text-3] [css-text-4] [css-overflow]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 19 Sep 2018 20:38:41 -0400
Message-ID: <CADhPm3uLnBSs4qjtQPLrG82faDWXdw4mC4CzKeCHJGaEzAJ_jw@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.
=========================================


Scrollbars
----------

  - RESOLVED: Request publication of FPWD of scrollbars

CSS Fonts 4
-----------

  - RESOLVED: Higher level properties a positive angle will be a
              forward leaning slant, lower level properties will be
              what is written by the author (Issue #3091)
  - RESOLVED: Publish fonts L4

CSS Break & CSS Display
-----------------------

  - RESOLVED: Use 'should' in the patch (Issue #1746)

CSS Text
--------

  - RESOLVED: Add florian as an editor to Text 3
  - RESOLVED: Revert the previous resolution [break-word will no
              longer affect intrinsic sizing] (Issue #2951)
  - RESOLVED: Make the normative change [to apply a min width to
              rendered tabs] (Issue #2883)
  - RESOLVED: Publish a new working draft as text-3
  - RESOLVED: Publish a new WD for text-4

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

  - RESOLVED: text-overflow affects non-breakable portions of the
              block-overflow string (Issue #2882)

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

Agenda: https://lists.w3.org/Archives/Public/www-style/2018Sep/0015.html

Present:
  David Baron
  Tantek Çelik
  Emilio Cobos Álvarez
  Benjamin De Cock
  Tony Graham
  Dean Jackson
  Brad Kemper
  Chris Lilley
  Peter Linss
  Nigel Megitt
  Thierry Michel
  Michael Miller
  Melanie Richards
  Florian Rivoal
  Jen Simmons
  Alan Stearns
  Lea Verou
  Greg Whitworth

Regrets:
  Rossen Atanassov
  Chris Harrelson
  Dael Jackson
  Stephen McGruer
  Manuel Rego Casasnovas
  Sean Voisen
  Jeff Xu

Scribe: gregwhitworth

  astearns: anyone have any extra agenda items?
  astearns: one change, we're going to skip item 8

Scrollbars
==========

Publishing FPWD of scrollbars
-----------------------------
  github: https://github.com/w3c/csswg-drafts/labels/css-scrollbars-1

  astearns: We discussed this at the f2f, but didn't get there - quite
            a few issues have been worked on since then.
  astearns: fantasai - you wanted some things working on, are you ok
            with it going to fpwd?
  fantasai: It looks like there is an outstanding pr that should be
            merged first, but probably it's fine
  astearns: Any other concerns?

  <chris> please let me know when that merge has happened
  chris: I'll put in the transition request now and wait until that PR
         is merged
  astearns: That sounds fine
  Proposed Resolution: FPWD of scrollbars

  RESOLVED: Request publication of FPWD of scrollbars

CSS Fonts 4
===========

Angle direction of font-style
-----------------------------
  https://github.com/w3c/csswg-drafts/issues/3091

  chris: It's about the slant axis and the range of values that are
         supported
  chris: The opentype spec takes negative values that it slants in an
         odd direction
  chris: Every single example I've seen uses a positive angle
  chris: When you're using high level things, like font-style you need
         to use positive integers
  chris: but we also need to take into account the lower level things
         and you have to pass in specifically what the font is asking
         for
  chris: For font-style a positive angle will make a forward slant and
         under the hood it will map to what the font needs
  <fantasai> wfm
  astearns: The lower level will just pass through what is written by
            the author
  <bradk> +1
  fantasai: It makes sense to me. It is what we would do if OpenType
            was only one of multiple font formats, and the others
            matched expectations and OpenType didn't. Of course we
            translate from CSS syntax to the correct font settings,
            and values in font-variation-settings of course get passed
            directly to the font.
  <florian> Sounds good to me. Let's make things sane for people
  myles: This is similar to how we handled optical sizing

  Proposed Resolution: Higher level properties a positive angle will
      be a forward leaning slant, lower level properties will be what
      is written by the author

  RESOLVED: Higher level properties a positive angle will be a forward
            leaning slant, lower level properties will be what is
            written by the author

Publication
-----------

  astearns: Fonts level 4
  astearns: We had an update to l3 this week, does anyone have an
            objection to updating a regular WD for L4
  <fantasai> +1 to publishing
  astearns: Hearing none

  RESOLVED: Publish fonts L4

  <fantasai> \^_^/

CSS Break & CSS Display
=======================

box-decoration-break and multi-box inline elements
--------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/1706#issuecomment-420474809

  astearns: [describes what is in the issue]
  fantasai: Do we want to allow box-decoration-break to close the
            fragments similar to what would occur when there is a
            forced line break?
  astearns: It describes non-contiguous fragments
  fantasai: I could possibly make that a little bit clearer with
            regards to bidi
  fantasai: The two fragments may end up adjacent to each other, the
            way the inline happens to break
  fantasai: The rule for bidi, on an infinitely long line you end up
            with something in the middle of the inline box to split
            into two. The intruder are meant to be two separate
            fragments even though they end up next to each other it
            provides us with the information we need
  fantasai: In that case if you did, box-decoration: clone you would
            end up with text in between them because the bidi algorithm
  fantasai: I think I can try to make it slightly clearer
  fantasai: The part about non-contiguous is an example - it's not
            exhaustive
  astearns: That's fair
  fantasai: I think the wording is ok

  dbaron: One comment about the bidi thing
  dbaron: Where implementations would create a separate fragment
          logically but they can never be separate
  fantasai: Or if you have an inline which has English text, a little
            bit, there is nothing that lets the user know there are
            multiple fragments
  dbaron: What you're saying is that it's on a visual perspective of
          whether it has the capability of breaking
  dbaron: That seems complicated to implement
  fantasai: This is about where it's defined to have a fragmentation
            break
  fantasai: from a rendering perspective, the user can't tell that
            it's doing that
  fantasai: The only case this should be known, is where there is text
            outside of the inline is intruding on the inline
  dbaron: I'm a little worried about.... <garbled>
  dbaron: This section has a lot of mays in it, we should have an
          issue for better definition
  fantasai: For sure
  dbaron: Please open an issue
  fantasai: I can open one
  astearns: Just open an issue for defining it better and leave the
            may out of this draft
  fantasai: We don't have any implementations so the may is there
  dbaron: If it's actually what you want implementations to do - then
          I would say that whether it's a should, with a may it's not
          clear it's what you want an implementor to do
  fantasai: ok, that's fair

  fantasai: How would the WG prefer, a may with a note - or a must
  astearns: I'm thinking a note that states that a future level will
            completely specify what occurs in this situation
  florian: I think that's what should is for
  florian: 'should' implies the note that astearns described
  dbaron: I support 'should' as well

  Proposed Resolution: Take the patch substituting should for may
  astearns: Objections?

  RESOLVED: Use 'should' in the patch

CSS Text
========

editor for text
---------------

  <fantasai> https://drafts.csswg.org/css-break-3/issues-cr-2016
  astearns: add florian as an editor to text L 3?

  RESOLVED: Add florian as an editor

Reverting resolution about overflow wrap break word
---------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/2951#issuecomment-421705003

  florian: We tried to have break-word affect intrinsic sizing
  florian: We had some hope that changes in the UA stylesheet would be
           sufficient, but it is not true unfortunately
  florian: So the only option it seems is to revert the previous
           resolution where it does not affect intrinsic sizing
  astearns: Is that separate issue somewhere?
  fantasai: Yeah we re-opened the issue
  astearns: Objections?

  RESOLVED: Revert the previous resolution

Applying a min width to rendered tabs
-------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/2883#issuecomment-421733978

  florian: When you have tab stops, if you have a tab - you're
           supposed to go forward in the line
  florian: If your text is coming extremely close to the next tab
           stop, should there be a minimum size?
  florian: Chrome, it jumps to the next one at a specific size and it
           seems reasonable in a monospaced font
  florian: I was thinking about going with 1 space, but maybe we
           should go smaller than a space
  florian: In a proportional font, spaces are already really small -
           0.5ch
  florian: I'm wanting to take this normative as makes sense

  Scribe: emilio

  astearns: Any comments from the non-chrome team?
  <fantasai> +1 from me anyway
  astearns: Proposal is minimum spacing is 0.5ch
  astearns: Objections?

  RESOLVED: Make the normative change

  myles: Should link to the primary font concept
  <fantasai> https://www.w3.org/TR/css-values-3/#ch
  fantasai: It already does via the ch value, though it's not actually
            the primary font
  fantasai: It's ch, it's not ambiguous
  emilio: Is it what Blink implements?
  myles: If the code is the same as WK it's not exactly the same, but
         we can say ch on the spec

  astearns: The test for this is not going to test this exactly
  fantasai: Why not?
  astearns: Flaky tests / pixel differences
  fantasai: Fine

Publication of text 3/4
-----------------------

  astearns: Both text-3 and text-4 are working drafts, proposal is
            publishing a new WD as text-3
  astearns: No objections?

  RESOLVED: Publish a new working draft as text-3

  astearns: Any objections for text-4?

  RESOLVED: Publish a new WD for text-4

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

block-overflow and text-overflow
--------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/2882

  florian: So the issue is about whether their interaction is
           well-defined. There's only one case where it's not defined.
  florian: If you have a break opportunity during the line we'll
           insert the ellipsis after that break opportunity and
           block-overflow doesn't have the chance to apply
  florian: The only case where it's not defined is where the ellipsis
           is longer than the whole line, right now the spec doesn't
           define it
  florian: Seems like we don't want the ellipsis to climb the line
           back up, so for now I think we should go for 'when the
           ellipsis is longer than the line then it does overflow, and
           text-overflow must apply'
  tantek: I think we need an example that we could look up
  florian: It's something like a very narrow paragraph with a very
           long block-overflow ellipsis
  florian: The spec says that if block-overflow ellipsis overflows
           then it may overflow to the next line, but it's undefined

  tantek: Any implementation experience?
  tantek: We should construct some examples and experiment, keeping
          the issue open for now
  tantek: Rather than spec something that is not easy to implement
  <dbaron> It seems like "use multiple lines for the block-overflow
           indicator" is probably the better behavior from a user
           perspective, but it does seem hard to implement.
  fantasai: Seems fine to leave it open as people implement it
  florian: So I'd expand on the proposal with examples in the issue
  florian: I'm ok with that

  dbaron: [what he wrote above]
  dbaron: Saying that it needs to fit on one line definitely makes
          implementation easier, but it's not clear how much
  tantek: I'd prefer to specify the better behavior for the user, and
          we don't know how much harder it is
  fantasai: So what we're hearing is that we should the issue open to
            wait for block ellipsis breaking across multiple lines,
            but we probably should say that if the block-overflow
            string still doesn't fit withing the block then
            text-overflow applies in that case as it would to any
            other text
  astearns: I like the idea of working out concrete examples so that
            people get better idea, but also so that we can put them
            in the spec
  florian: Does it sound reasonable to resolve on what fantasai said
           and add examples for the block-ellipsis on multiple lines?
  fantasai: I think we should resolve that text-overflow applies to
            the overflow string if there's an unbreakable string on it
            like it does to the rest
  fantasai: Also that we should put some example in the spec about
            this interaction, and also on the issue about what happens
            if the block-overflow string can break
  fantasai: We could narrow down the behavior as 'either you treat is
            as unbreakable' or 'treat it as breakable and grab space
            from previous lines'

  astearns: So the first bit is to resolve that text-overflow affects
            overflowing, unbreakable portions of the block-overflow
            string. Objections?

  RESOLVED: text-overflow affects non-breakable portions of the
            block-overflow string

  astearns: Probably the examples doesn't need a resolution
  astearns: We're going to work on those to put them on the spec
  florian: I'm going to put examples in the spec on what we just
           resolved, and then in the issue about the wrapping
  astearns: Should that be a different issue?
  florian: Maybe, sounds reasonable
  astearns: We'll leave it to your discretion
  florian: Should we resolve on the breaking to narrow it down to the
           two discussed options?
  astearns: Don't care
  florian: I think I prefer to leave as-is for now
  florian: Then we can narrow if we don't resolve soon
  astearns: I think that's reasonable, I prefer to resolve soon, the
            examples would be really helpful
Received on Thursday, 20 September 2018 00:39:38 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 20 September 2018 00:39:39 UTC