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

[CSSWG] Minutes Sydney F2F 2018-07-05 Part IV: CSS Multi-Column Layout, CSS Text Decoration, CSS Scrollbar Width [css-multicol] [css-text-decor]

From: Dael Jackson <daelcss@gmail.com>
Date: Tue, 24 Jul 2018 19:52:43 -0400
Message-ID: <CADhPm3vXS2CubBYrgT=5ximXc36TUsihCTEY0oTPqR+2c4if_w@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 Multi-Column Layout
-----------------------

 - RESOLVED: Column boxes are BFCs
 - RESOLVED: Second solution in the issue (spanners are BFCs that
             collapse margins).

CSS Text Decoration
-------------------

 - RESOLVED: ink-skipping is determined by the decoration originator,
             not descendant elements (Issue #2817)
 - RESOLVED: underline position is also determined by the decoration
             originator, not descendant elements (Issue #2817)
 - RESOLVED: underline offset is also determined by the decoration
             originator (Issue #2817)

CSS Scrollbar Width
-------------------

 - WG discussed feature for controlling scrollbar width.
   Conclusion seemed to be to publish FPWD with auto | thin | <length>,
   and a prominent warning that <length> was contentious and might be
   dropped. FPWD resolution was deferred due to lack of time to discuss
   scrollbar colors.

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

Agenda: https://wiki.csswg.org/planning/sydney-2018#schedule

Scribe: TabAtkins

CSS Multi-column Layout
=======================
  github: https://github.com/w3c/csswg-drafts/issues/2582

  florian: I don't remember exactly how I found this problem, but;...
  florian: In example 25 of multicol, sentence says the margin between
           adjacent spanners collapses together.
  florian: I think everyone agrees with this, but it's only stated in
           an example
  florian: We *could* say that it's already explained by "multicol is
           a BFC", but that doesn't explain why things have columns,
           so...
  <astearns> example 25 in https://drafts.csswg.org/css-multicol-1/#column-span
  florian: [reads out from issue]

  iank: Why do you want the margins to collapse together?
  florian: Not sure I do, spec just says it and implies it's a
           consequence already.
  florian: Impls already do that
  Rossen: This is an issue Håkon and I went back and forth with
  Rossen: He argued it should behave as much as possible as block
          layout when you have a single column
  Rossen: I still disagree and think they shouldn't collapse
  * fantasai agrees strongly with Håkon

  astearns: [draws example with some spanners next to each other]
  florian: Right now you can only span 1 or span all, so not possible

  dbaron: I think I filed an issue with this earlier, but...
  dbaron: If the columns themselves don't form BFCs, then floats don't
          float to the column
  florian: They definitely do
  dbaron: I don't see that in the spec.
  RESOLVED: Column boxes are BFCs

  florian: So either the multicol is a "multicol formatting context"
           that knows how to place columns and spanners, or we have
           some concept of an anonymous box that wraps a column row...
  fantasai: I think defining the entire model is a distraction, should
            figure that out when we deal with < all spanners.
            Let's focus on the issue.
  astearns: So you propose we add text that column spanners collapse
            margins between each other as if they were in block layout
  astearns: Objections?
  Rossen: As long as it's only between spanners
  Rossen: Are spanners BFCs?
  fantasai: Yes
  Rossen: So let's collapse margins!
  rachelandrew: We do that anyway to support spanners.

  fantasai: Let's do a limited version of this. There's a box around
            the column row. That box and the column spanners are laid
            out as if they were block-level siblings in a block
            container.
  florian: Yeah, either that, multicol is a BFC laying out the row
           boxes and spanners, or there's no row boxes and multicol
           just magically knows how to position things.
  florian: This might make it more difficult to introduce not-all
           spanners.
  dbaron: Already hard.
  dbaron: Does anyone remember whether position: relative on an
          ancestor of the column-span box that is a descendant of the
          multicol moves the spanner?
  dbaron: That might affect whether you have wrapper boxes around the
          spanners.

  <dbaron> Florian mentioned somewhere in there that the definition of
           adjacency for column-span boxes isn't clear.
  florian: And if we just want to reuse the margin-collapse def from
           2.1, we may need to revisit the notion of adjacent.
  fantasai: We do layout on the box tree, not the element tree.
  TabAtkins: adjacency is box-tree, not element tree
  dbaron: The rules for whether an empty column row is generated
          might need to be made more specific, to give us good
          results for adjacency.
  dbaron: Like if there was an empty block between the two spanners,
          does that create a column row that breaks adjacency?
  fantasai and iank: yes
  dbaron: Okay, needs to be made clear.

  florian: Example - piece of text with two <em> elements following
           each other. Both have a border. Both contain a div.
           The div is column-span:all. There is a border between the
           two divs, but they're taken out-of-flow. Are the spanners
           adjacent?
  fantasai: No, the em splits into two boxes around the div, so
            there are boxes between the divs.
  dbaron: So the end of an inline causes the creation of a line box,
          you're asserting?
  dbaron: Maybe if it has a border...
  fantasai: We discussed this earlier, but it matches block-in-inline
            splits.
  florian: I don't want to deep-dive this, I suggest we keep to the
           two issues
  dbaron: spanners margin collapsing still needs things defined...
  florian: We should just resolve on the collapsing in general.

  <dbaron> block-within-inline behavior is that it's a function of
           whether there's a border: toggle "xborder" to "border" in
  <dbaron> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0A%0Aspan%20%7B%20xborder%3A%20thin%20solid%20fuchsia%3B%20%7D%0Aem%20%7B%20display%3A%20block%3B%20border%3A%20medium%20solid%20blue%3B%20padding%3A%203px%3B%20%7D%0A%3C%2Fstyle%3E%0A%3Cspan%3Ea%3Cem%3EB%3C%2Fem%3E%3C%2Fspan%3E%3Cspan%3E%3Cem%3EC%3C%2Fem%3E%3C%2Fspan%3E

  dbaron: We might have someone reviving our column-span impl
          sometime this year, so...
  astearns: So are you saying we just add a statement that adjacent
            spanners collapse their margins?
  florian: For now depending on 2.1's definition of adjacent, and
           open an issue to track whether it's sufficient or not.
  [discussion about whether column rows should have boxes in the
    layout model, or not]
  florian: I think that option is easier now. I wonder if it makes
           life harder when we do non-all spanners.
  fantasai: I don't think so.
  fantasai: I think Gecko won't actually create the boxes...
  dbaron: In our impl we do, moved nsColumnSetFrame to be the row boxes
          wrapped them in a new box.
  fantasai: Great, even better.

  florian: So that means we're taking the original issue that starts
           with "alternatively..."
  TabAtkins: So back to original issue?
  florian: Original issue is that it seems impls say that spanner
           margins collapse, but spec doesn't say how. So this will
           solve that.
  astearns: So "alternatively..." with extra details, like spanner
            boxes are bfcs...

  florian: I think we already have that one
  astearns: So proposed resolution is second solution in the issue,
            in order to define spanner margin collapsing.
  astearns: objections?
  RESOLVED: Second solution in the issue (spanners are BFCs that
            collapse margins).
  florian: I'll figure out with Rachel who does these edits.

CSS Text Decoration
===================

How text-decoration-skip/ink interacts with text-decoration
-----------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/2817

    xidorn: problem here is that text-decoration properties generally
            are not inherited, because we want the decoration line
            to be one line across a whole element.
  xidorn: But text-decoration-skip and text-decoration-skip-ink is
          inherited.
  xidorn: So it's unclear whether the decoration line on an element
          should respect the -skip/-ink on the element, or on the
          element that the line originated.

  fantasai: Original design of text-decoration-skip had several values,
            ink was one of them. Could say you want margin skipped,
            etc.
  fantasai: Also just "skip me", entirely.
  fantasai: That value can't possibly work if it only works on the
            element establishing the decoration.
  fantasai: Whole point is to set it on an element and have it affect
            a line established by an ancestor.
  koji: text-underline-position has same issue
  fantasai: text-underline-position should be attached when the
            decoration is set, otherwise if you're switching languages
            it'll switch sides

  emilio: In gecko we implement the spec that says text-decoration
          properties are reset...
  emilio: With multiple decoration, webkit/blink keep track of them
          in effect using an inherited property, which you add stuff to
  emilio: I wonder what edge does
  emilio: In webkit/blink decorations aren't propagated in box-tree,
          which is supposed to happen.
  emilio: Does edge implement the spec?
  emilio: Right now the only ones affected by this operation are Gecko
  frremy: edge does one underline for the whole thing, not one per span
  myles: how we implement - if you have an outer that's underlined,
         inner that's strike-through, you're supposed to add so the
         inner gets both
  myles: that's what emilio's talking bout
  frremy: I think we have a field for underline and one for
          strike-through
  myles: Sounds like a different mechanism

  dbaron: testcase with three different renderings...
  <dbaron> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0A%0Au%20%7B%20text-decoration%3A%20underline%3B%20color%3A%20blue%20%7D%0Aem%20%7B%20text-decoration%3A%20underline%20line-through%3B%20color%3A%20green%3B%20vertical-align%3A%200.5em%20%7D%0A%0A%3C%2Fstyle%3E%0AThis%20%3Cu%3Eis%20%3Cem%3Esome%3C%2Fem%3E%20text%3C%2Fu%3E.
    Firefox: blue underline stretching across whole thing, green
             underline under "some" at its baseline.
    Chrome: no blue underline under "some", it has green at its
            baseline
    Edge: blue underline stretching across whole thing (maybe), green
          underline overlapping it (rather than at "some"'s baseline)
  dbaron: This is the difference emilio is talking about
  Rossen: We align the two underlines
  myles: So we have a bunch of impls that are wrong. If you don't
         consider impls today, don't consider spec today, what's
         best behavior for users?
  frremy: I think it depends. I think Firefox is a bit better in this
          specific case.
  frremy: But in some vertical cases, you want the underlines to align.
  fantasai: The spec for underline says if you're gonna collide with
            the text, you can move it down.
  astearns: We're getting afield

  florian: "skip-me" can't possible work unless the skipping applies
            based on the descendant element, not the originator.
  astearns: And the example in the issue - the div has skip-ink on it,
            but a descendant wants no skipping - we want the descendant
            to not skip.
  dbaron: Another example is hyperlinks.
  dbaron: A piece of a11y advice is that if you have multiple
          hyperlinks, you should have a space between them, so the
          user can tell they're separate links
  dbaron: I think text-decoration skipping...
  fantasai: We have a feature for that, text-decoration-skip: edges
  <fantasai> https://drafts.csswg.org/css-text-decor-4/#text-decoration-skip-property
  myles: Links with no space between them?
  fantasai: That's why there's an "edges" value
  dbaron: So some people might want for hyperlinks to *not* have
          skipping, so you have continuity of underlines and can more
          easily tell it's not multiple links.
  dbaron: Where I'm going is that it's an argument for skip:none on the
          thing setting the decoration, and having it not overrideable.
  fantasai: I can see that for the ink value specifically.
  fantasai: I think some of the other values we have that makes less
            sense

  myles: Any impls of the other values?
  fantasai: Don't think so, and I think we resolved to split it apart
            into multiple properties anyway, just hasn't been edited in
  florian: Yes
  myles: So for those other longhand properties we're still in the
         design phase and can change them
  florian: So we could decide which element it keys off depending on
           the property
  fantasai: Some of the properties are already bound to the decorating
            box

  TabAtkins: Once you've established a type of underline wrt
             ink-skipping or not, don't want children to set it
             differently
  heycam: Is this fundamentally an issue with ink-skipping on by
          default?
  florian: I think we can set ink-skipping to work on the originator,
           and others can be on children
  fantasai: Fine with me.
  fantasai: I do want to point out that if we do this, you can have two
             underlines on one element, one that skips ink and one
             that doesn't.
  myles: You can do art with overlapping underlines!
  TabAtkins: Proposed resolution is that text-decoration-skip-ink is
             bound to the decoration where the decoration is
             specified, and propagates with it
  astearns: So resolving only on skip-ink, not skip.
  fantasai: yeah

  RESOLVED: ink-skipping is determined by the decoration originator,
            not descendant elements
  RESOLVED: underline position is also determined by the decoration
            originator, not descendant elements

  heycam: Does this mean they're not inherited?
  myles: No, unrelated. It's just determined when you establish the
         decoration, regardless of how the property changes on children
  koji: I think text-underline-offset should also propagate with the
        decoration
  RESOLVED: underline offset is also determined by the decoration
            originator
  plinss: Any properties that *don't* go with the originator?
  <fantasai> plinss, text-decoration-skip: objects
  TabAtkins: yes, some of the other skipping functionalities, because
             the children can say "skip *me*"

Scrollbar Width
===============
github: https://github.com/w3c/csswg-drafts/issues/1958
  tantek: We had a rough consensus among people who cared to add a
          scrollbar-width property.
  tantek: We think it's implementable.
  tantek: Wanted to bring it to people's attention in case there are
          opinions.
  tantek: This is one of the key things I wanted to resolve one way
          or the other before FPWD. Other was color properties.
  * fantasai notes that
      https://lists.w3.org/Archives/Public/www-style/2017Feb/0059.html
    probably belongs in this spec fwiw

  heycam: This sets the maximum width? Why?
  astearns: That was some feedback from Xidorn where the UA might want
            to display something smaller sometimes...?
  tantek: Right. You might want to limit how wide a scrollbar can be,
          but not force platforms that do narrower ones to draw wide.
  frremy: scrollbar-max-width?

  myles: Worried for two reasons.
  myles: First is MacOS scrollbars have two widths, they switch
         between.
  myles: Such a model can't express that.
  myles: Second is that on windows, scrollbar widths will change if
         you're using touch or not.
  myles: So that also doesn't fit with this property
  myles: Also, OS should be the one that sets these complicated models,
         not websites.
  TabAtkins: A lot of websites have very narrow scrollbars, and that is
             exactly the reason why they are using non-native
             scrollbars

  tantek: You brought up a good reason for the max treatment.
  tantek: Platforms can switch between widths *within* the property's
          value.
  tantek: so like on MacOS it starts small and gets bigger on hover -
          you can still do that with max-width.
  frremy: When it gets bigger it's overlay, right?
  myles: When you're using non-overlay scrollbars, it doesn't change
         size on hover.
  frremy: So the width should just be the layout size
  tantek: Maybe the size is just the initial size, the expanding can
          ignore that?
  myles: Problem is just that there's already three modes on MacOS.
         I worry about letting pages control this.
  astearns: Not allowing this property doesn't save users from terrible
            scrollbars. Pages will use custom (terrible) scrollbars.
  astearns: This just lets them specify a max width, you can still do
            nice native scrollbars.
  xidorn: I guess myles' point is whether the width should apply to
          overlay scrollbars, which I'm not sure.
  xidorn: I discussed with tantek before, and thought it should be
          applied to overlay as well.
  xidorn: But then we have problems - it may restrict the ability to
          expand the scrollbar.

  myles: One other piece I want to mention is that setting this
         property shouldn't force scrollbars to be take up layout
         space.
  tantek: It doesn't.
  xidorn: It might make the layout space *smaller*.
  xidorn: Whether this should apply to the appearance of overlay
          scrollbars is another issue.

  heycam: What is the use-case for allowing a specific width to be
          specified, and whether it's sufficient to just request
          "thin"?
  myles: So if our users select that they want scrollbars to take up
         layout space, we don't have a thinner version.

  tantek: I think the problem to solve is that users are creating a
          totally new scrollbar just to make it thinner. The work
          there is suboptimal due to usability.
  tantek: Hope is that we can reflect the underlying platform's
          behavior better.
  myles: I'm sympathetic to the idea that giving authors a way to get
         the behavior they want without building it themselves is
         better.
  myles: I'm not very convinced that this will be the impetus to stop
         building things themselves.

  Rossen: From xidorn's comment; if i set the max-width, at least we're
          going to affect the layout size
  Rossen: If that exceeds the width of the scrollbar, that'll be weird.
  TabAtkins: That's why it's a max width.
  Rossen: So it doesn't go above the visual width of the scrollbar.
          With hidey-scrollbars, the width stays at zero.
  [something from me]

  tantek: Side issue - there are a lot of people discussing on the
          issues *demanding* the webkit model. If there was a
          canonical link I could point people to, it would be useful.

  <astearns> https://lists.w3.org/Archives/Public/www-style/2017Dec/0040.html
  <astearns> https://lists.w3.org/Archives/Public/www-style/2017May/0010.html

  frremy: I think the more recent proposal was for having a "thin"
          keyword sounds good. And if they want "thin", maybe use
          overlay for that specific element?
  frremy: Request we get often is that people want dark scrollbars,
          and people want tinier scrollbars, for things like chat
          windows.
  frremy: So yeah, maybe rather than a specific size, we just have a
          "thin" keyword that opts into the OS's smaller version.

  myles: So let's pretend I'm on gtk linux that only has one size...
  frremy: Then it's just the one size, that's an OS limitation
  myles: So this can't be tested?
  TabAtkins: We try to minimize manual tests, but it's not a case o
             if it's not possible to machine test it doesn't exist.
  myles: So what happens if you test on an OS that only has one
         scrollbar size?
  tantek: It passes.
  myles: So author has to know what all the platforms do...?
  TabAtkins: Don't worry about GTK, everyone uses macos, windows,
             or chromeos. ^_^
  dbaron: And GTK *does* have two widths anyway.

  tantek: So if we just add a thin value we can see what feedback we
          get.
  TabAtkins: I'd accept that in my use-case, yeah.

  ...
  tantek: A lot of what we do is replace JS hacks.

  xidorn: I'd like to raise that there was actually another use-case
          I'd like to solve with scrollbar-width
  xidorn: Some authors just want to make their own scrollbars, and want
          to make the native be hidden, but still be scrollable.
  xidorn: I think that's a reasonable use-case as well. Even if their
          custom is terrible, it's still better than "overflow:hidden".
  TabAtkins: Rich Byers had some proposal for having a scroller but
             without a visible scrollbar

ScribeNick: fantasai
  Rossen: Couple points, the first one is for the length value
  Rossen: If we were going to go with a length value as it's currently
          specified
  Rossen: There has to be some affordances, or at least explain how
          scaling works
  Rossen: E.g. in Edge we go to a great extent to make sure that the
          frame scrollbars never scale as you pinch-zoom, so that your
          scrollbar doesn't take over the entire surface of your device
  Rossen: At the same time, content will scale
  Rossen: So already a discrepency at least in our case
  Rossen: between scrollbars attached to the frame and the content in
          the frame
  tantek: gestures or other other zoom-like zoom property?
  Rossen: For browser zooms, we always keep the same scrollbar size as
          every other scrollbar in the system
  Rossen: Not expecting any action, but it has to be considered

  <tabatkins> fwiw, ChromeOS's native scrollbars are space-taking but
              tiny, and they overlay-grow on hover.
  <tabatkins> I lied, ChromeOS's native scrollbars are purely overlay.

  Rossen: The other thing is that scroll spec started off that you
          have a lot of interop bugs that were being reported to
          you and since the last time we talked about this
  Rossen: couple things I realized
  Rossen: Firstly, we removed all styling of scrollbars in Edge 4 yrs
          ago
  Rossen: and we have absolutely no bugs reported to us about styling
          scrollbars
  Rossen: so curious where we're going with this
  frremy: Actually, we keep getting bugs from Outlook complaining to
          us about this, so it's not true
  ...
  Rossen: To myles's point, ppl want more control
  Rossen: Are we trying to go more towards this model, or try to lock
          it down?
  Rossen: thin/medium/thick scrollbars and some colors and leave it
          there
  tantek: The hope is that a small number of properties is enough to
          satisfy users
  tantek: There are sites that will outright block browsers based on
          support for scrollbar styling
  myles: New thing won't solve existing problem?
  tantek: They're putting effort into trying every possible way to
          style the scrollbars, so expect they'll update with new
          thing if it's available
  myles: Sites are saying that color of the scrollbar is so important
         they'd rather people not use their service?
  tantek: Yes.
  <tantek> https://www.w3.org/wiki/Css-scrollbars#Sites_blocking_browsers
  <tantek> https://webcompat.com/uploads/2017/7/96051d95-3863-4285-8b02-245403aeb160-thumb.jpg
  xidorn: It's not so much about specific colors, but e.g. they have
          a dark interface and they don't want light scrollbars

  Rossen: I think the keyword values would be better
  Rossen: Either adding or replacing <length>
  myles: Scrollbars are a evolving technology
  myles: A few years ago MacOS scrollbars had up/down arrows
  myles: Then we went to overlay and dropped the arrows
  myles: Then went to two different overlay
  myles: Windows has similar evolution
  myles: You need to consider how this works with all of the complexity
         today, and also how it could work in the future
  tantek: I agree with that, and been resistent to speccing this in
          general
  tantek: So trying to figure out with specific use cases
  tantek: As much as scrollbars have evolved, some way to control color
          has been constantly desired. Same with width
  tantek: I would agree with your statement of being mindful of the
          future.
  tantek: Question is, do folks want a thin keyword?

  astearns: Choice is between having width that allows for zero, or
            having at least two keywords
  astearns: thin/none/auto
  Rossen: Can we take the length value out of the picture?
  astearns: So do we have <length> or thin | auto | none ?
  fantasai: If you wanna get rid of the scrollbar you can put it to 0
            or none, same effect.
  fantasai: But what do you mean by "thin"? If the author is caring
            about the width of the scrollbar, they want it to be
            narrower than a particular amount.
  astearns: Tab's use-case was fine with "thin".
  fantasai: So what if scrollbars are 10px by default, but a thin
            version is 5px. They say "thin", because they want the 5px
            version. But then later scrollbars default to 5px, and
            thin is 2px, it's smaller than they needed!
  TabAtkins: If it's 10px and 5px for thin, and author says 6px it's
             fine, it'll choose 5px one
  TabAtkins: Later OS change such that it's 8px and 3px, it'll go down
             to only 3px
  frremy: I don't think scrollbars will keep getting smaller, they're
          about as small as they'll get.
  Rossen: Disagree, we keep changing them as well.

  Rossen: Going back to Simon's statement that scrollbars as OS-level,
          and we shouldn't mess with them. I don't disagree with this.
  Rossen: If the platform offers multiple sizes, maybe we give control
          over choosing that, ok. Maybe we want to give a little bit of
          color control, okay. But taking over system controls, you
          either take it over or you don't.
  Rossen: For any other system control, like a button, they take it
          over totally. They use an image and script.
  myles: So you're saying that authors should have no control, and
         should use JS entirely if they want any control.

  dbaron: An idea floated around was specifying a size and getting
          nearest-available size.
  dbaron: Problem with that is people try out sizes and fiddle around
          until it looks good.
  dbaron: They can end up getting a different size than they ask for,
          but it looks okay, and then later changes violate what they
          want while still technically respecting what they say.
  dbaron: naming the property well can mitigate that risk

  frremy: Reason I disagree - if you ask for "thin" on Mac you'll get
          overlay, 0 layout size.
  frremy: It seems way easier to just say "normal" or "thin", and
          they're up to the UA.
  myles: On macos, there's layout and overlay scrollbars.
  myles: If the author's threshold is larger than layout scrollbars
         they get that, if thinner they get overlay. Right?
  myles: So the functionality seems to end up being flipping overlay
         on and off, which isn't what it's meant for!
  tantek: I don't think flipping that layout switch is what was
          intended.
  myles: But macos has just two scrollbars - 16px and 0px. If your
         max-size is 15px, it'll turn on overlay.
  myles: This is what I was getting at - we need to think deeply about
         how this affects scrollbar models today and in the future.
  frremy: Problem is that the longer we wait, the more custom
          scrollbars we get.

  myles: Authors want to control everything, never satisfied
  TabAtkins: What they want and what they'll accept are two different
             things
  TabAtkins: And we're hoping we can hit their accept threshold with
             fairly little stuff.

  florian: Re fantasai's point about getting something ridiculously
           tiny - maybe in the keywords we can have more than just
           auto|thin, we can add |hairline. That's definitely distinct
           in intent, while still allowing threshold.
  myles: What if the OS's thinnest scrollbar is wider than the desired
         length?
  TabAtkins: This is why frremy suggests just doing keywords, eliminate
              that problem.
  florian: Note that scrollbar-gutter can solve some of those problems
           too.
  <tantek> https://drafts.csswg.org/css-overflow-4/#scollbar-gutter-property
  fantasai: And scrollbar-gutter should be in the same spec as this,
            if we go to FPWD.

  myles: So tantek you don't need resolutions yet, right?
  tantek: My normal approach is to put in all the possibilities so we
          can discuss it with wider population.
  tantek: So my inclination is to add "thin" and keep length for now.
  Rossen: I think if we have the keyword and everyone revolts, we can
          think about adding lengths back.
  TabAtkins: I agree, and I think lengths have a harder time of getting
             through the committee anyway.

  myles: My preferred solution is still option 3 - none of this
         proposal at all.
  Rossen: +1
  TabAtkins: I strongly disagree, as do our a11y people, but I
             understand your position, because it's what Simon has
             said every time this has come up.

  tantek: So I guess question is - would anyone object to going to FPWD
          with the width property at all, and would width with <length>
          draw objection?
  Rossen: I won't object to keywords. I'd object to length
  myles: We don't object to it in either form.
  florian: I don't object to any particular, but to me FPWD signals we
           have details to figure out, but general agreement on the
           approach.
  florian: I'm not sure we have agreement on approach yet. Not
           objecting, just noting.
  myles: In addition to what I just said, which sounded positive, we're
         actually reluctant.
  [talking about fpwd vs patents]
  tantek: I'm hearing the least objection to putting *something* about
          length in there.
  myles: Two browsers are reluctant.
  tantek: If you really objected you'd drop the ::-webkit stuff.
  myles: We don't comment on future software releases.

  xidorn: Our position is that pushing this would help webkit/blink
          drop the pseudo-elements.
  xidorn: This is one of the use-cases we've heard.
  tantek: Right. We think some of the users currently using
          ::-webkit stuff will be amenable to switching,
          and the -width property will contribute to that.
  tantek: So my goal is to put it in for now. We can always decide
          in a subsequent draft to drop it.
  florian: I'd be happier for FPWD if we agreed on earlier discussion.
  fantasai: I think we're clear that this is about the simplest
            possible thing we could to control the width
  astearns: Rossen objected to "-width:<length>". If there was a scary
            warning, would that get through your objection?
  Rossen: Yeah.
  proposed resolution to add "thin", and a big warning note about
           <length>, then go to fpwd.
  [discussion about whether keywords, length, or both]
  astearns: And you should include a note about disagreement about
            the existence of the property itself

  [discussion about colors]
  astearns: Would you object to fpwd with the colors as stated?
  fantasai: I think I would.
  fantasai: If a key use case is light/dark, we should have those as
            choices
  astearns: Then we're out of time and will have to come back to this.
Received on Tuesday, 24 July 2018 23:53:44 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 24 July 2018 23:53:44 UTC