W3C home > Mailing lists > Public > www-style@w3.org > January 2017

[CSSWG] Minutes Telecon 2017-01-25 [css-sizing] [css-rhythm-1] [background-4] [css-2017]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 25 Jan 2017 21:03:52 -0500
Message-ID: <CADhPm3sONHu4ApQrESxATUfLskcD_XxUNNC=5U9p0JBRF2Ga2w@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 Sizing Level 3 WD

  - RESOLVED: Publish WD of CSS Sizing L3

Avoiding accidental double spacing

  - Florian was concerned that the current spec for the
      line-height-step property would lead to an author accidentally
      getting the double height in a browser he/she didn't test
      against due to a variation on the value of line-height:normal
      caused by each browser calculating it slightly differently.
  - There was broad agreement that the use case was valid and should
      be solved, but no agreement on how to solve it.
      - After some modifications, Florian's proposal was clarified
          to specify that line-height:normal is a TBD fixed value
          when the user sets line-height-step to anything other than
      - The concerns with this proposal is that the authors may not
          know why something that works with line-height:normal
          suddenly stops working.
      - If this proposal does go forward the initial value of
          line-height-step should be none.
  - Conversation will continue on the github issue to try and reach
      consensus: https://github.com/w3c/csswg-drafts/issues/938

Add background-repeat-x/y

  - Though at the most recent F2F there was a resolution to add
      background-repeat-x/y due to web usage several browser
      vendors didn't want to add the property because they didn't
      feel there was such a strong need.
  - RESOLVED Do not spec background-repeat-x/y for now
  - It is Chrome's responsibility to gather more data to either
      persuade other vendors to implement it or to decide that they
      can remove it.

2017 Snapshot Issues

  - TabAtkins will look into the index problem so that the snapshot
      can be published.

Revising CSS2 via NOTEs feedback

  - There were concerns about the decision from the F2F to use a
      NOTE to maintain pending updates CSS2 not being the correct
      process approach.
  - This conversation will continue on the mailing list as that's a
      better forum for this type of conversation, but people were
      encouraged to actively reply on the list and to give specific
      alternate proposals.


Agenda: https://lists.w3.org/Archives/Public/www-style/2017Jan/0058.html

  Rachel Andrew
  Tab Atkins
  David Baron
  Bert Bos
  Tantek Çelik
  Dave Cramer
  Alex Critchfield
  Elika Etemad
  Simon Fraser
  Daniel Glazman
  Tony Graham
  Dael Jackson
  Brad Kemper
  Chris Lilley
  Peter Linss
  Myles Maxfield
  Mike Miller
  Rachel Nabors
  Simon Pieters
  Anton Prowse
  Liam Quin
  Melanie Richards
  Florian Rivoal
  Jen Simmons
  Geoffrey Sneddon
  Alan Stearns
  Lea Verou
  Greg Whitworth
  Steve Zilles

  Rossen Atanassov
  Vladimir Levantovsky

Scribe: dael

CSS Sizing Level 3 WD

  astearns: Let's get going. Anything to add to the agenda?
  astearns: Does anyone have an objection to publishing what we have
            in the draft now?

  RESOLVED: Publish WD of CSS Sizing L3

Avoiding accidental double spacing

  <astearns> https://github.com/w3c/csswg-drafts/issues/938
  <tantek> for the record: https://drafts.csswg.org/css-sizing-3/
  Florian: I raised this because the general mechanics are fine but
           there's a case where we can improve.
  Florian: You have your line-height that works normally and with
           the line-height-step property you can round up. If you
           provide a value that is some margin larger then the
           line-height everything is fine. The problem is if your
           line-height is unreliable.
  <fantasai> [Florian is talking about the case of line-height:
  <fantasai> [which varies between 1-1.2 depending on implementation
             and available fonts]
  Florian: If you don't set line-height and just set
           line-height-step to a value somewhere within the usual
           range of variations when you test on your machine it may
           be fine but somewhere else it could be larger than your
           step height and everything is double height.
  Florian: I have a proposed solution. If you don't set line-height
           but do line-height-step you compute line-height to 1
           instead of normal.
  Florian: If you're using line-height-step as intended this does
           the right thing. koji isn't enthusiastic.
  * fantasai thinks Florian's problem should be solved, and his
             solution makes sense

  koji: I think we already said in the notes that the author has to
        set line-height for these properties. I'm not a big fan to
        add more magical behavior. I understand the benefit but to
        me looks like the down side wins.
  Florian: Is there any downside beyond impl complexity? I don't see
           a behavior downside.
  koji: It looks like we rec not to set line-height if using step
        sizing which makes it quite different.
  astearns: I don't quite understand that objection.
  astearns: We're just dealing with where line-height is normal. I
            don't get how it follows that we're asking people not to
            set line-height.
  koji: I don't understand. Normal is initial value. So we ask
        authors to set line-height and other things. This recommends
        that the author not to set line-height.
  astearns: I would expect us to say you should set line-height when
            using step sizing. In the odd case where an author
            chooses not to set line-height we fix a possible,
            accidental double sizing.
  Florian: If we make it more robust we encourage reliability. But
           the breakage is subtle and only on some systems.
  <fantasai> florian++
  koji: Same for line font size too. I understand intent, but it's
        clear that if things work they will not set the line-height.
        Even if it's not our intention we're implicitly recommending
  <fantasai> koji, that's the problem: on the author's machine it
             works, but on the viewer's it doesn't
  <fantasai> florian, one issue with your proposal: currently the
             initial value of line-height-step is zero, and this
             creates discontinuous behavior.
  <fantasai> florian, we'd need to introduce none as the initial

  dauwhe: When I played with it it was quite common for me to
          trigger this behavior. I also think of line-height as
          fairly fundamental and most authors will use it and expect
          it to work seamlessly.
  <fantasai> dauwhe++
  astearns: I take it dauwhe you're not in favor of changing the
            unset line-height behavior?
  dauwhe: I'm not sure on a solution, but I agree there's a problem
          here and it's a general problem that it's too easy for the
          property to create unexpected results.

  Florian: fantasai made a point in irc too.
  koji: The same happens to a font size too because initial for font
        size varies by platform.

  fremy: If you're doing it right you're using em to define the
         line-heights based on font size. You should do the same for
         step. You should never use px to define a line item. Using
         em you should get right result.
  <dbaron> you should really be using <number> values rather than
           <length> values in em
  koji: If you set correct values it works correctly. Florian wants
        to solve when author forgets.
  Florian: I'm not saying this is the only problem like this in css,
           but either way we should have robust default. If we have
           another way to solve I'm all ears, but I wouldn't be
           happy about not solving it.
  <fantasai> Agree with Florian, robust defaults are an important
             CSS design principle
  koji: I understand but it's as robust as without step sizing.
  Florian: If you don't have step sizing it'll be somewhat okay in
           all browsers.
  koji: It's relative.
  Florian: Double sizing is not okay when not intended.
  koji: I'm not saying it's okay. I'm saying different line-height
        is not okay.

  TabAtkins: Florian proposed that line-height-step is non-initial
             value we agree on a specific value for normal.
  Florian: Correct.
  TabAtkins: So what's wrong with that?
  myles: Setting it to 1 it's very easy to get overlapping lines.
  Florian: But you have line step height as well.
  TabAtkins: That would ensure everything is 2em tall. The point is
             does it seem reasonable to say the normal value should
             be a known value to avoid cross browser difference in
  myles: Known value would be something derived from font.
  TabAtkins: No. Right now normal is set to a specific value per UA
             but it's allowed to vary. It's not based on font.
  dbaron: It is.
  Florian: It is to some degree.
  Florian: If you set the line-height to a value wrong for your font
           you'll get lines that overlap. If you set the step to
           that same value you will get the overlap.
  Florian: So that setting of line-height to a value when you set
           line-height-step to a thing that makes sense creates no
           new problem.
  Florian: It's still terrible if you picked a terrible value, but
           that's something else.

  <dbaron> Another option here might be to define how 'normal'
           depends on font metrics and try to become interoperable
           on it!
  <fantasai> dbaron, that helps but only somewhat: it doesn't handle
             the case of using a font other than the one on the
             author's computer!
  <fantasai> dbaron, not that we shouldn't do it anyway, but it
             won't solve this problem specifically
  fremy: fantasai made my point on IRC. dbaron said we could
         standardize for normal but it doesn't help if you choose a
         font you don't have even if you say you use the font's
  TabAtkins: If you say use the font metrics for normal...but the
             proposal was a specific value.
  fremy: Yes. I think for the value we should investigate what
         browsers are using. But I'm okay to fix a value...choose a
         value in the case where you spec the step height.
  fremy: We could even say line-height normal...it seems easier to
         just choose a value.
  <fantasai> https://www.w3.org/TR/CSS2/visudet.html#propdef-line-height
  <fantasai> "Tells user agents to set the used value to a
             "reasonable" value based on the font of the element."

  myles: What is step size it's a multiple of the line-height of the
         primary font.
  Florian: So you turn step size on and off?
  astearns: Then the step size varies as line-height varies so you
            don't get a vertical rhythm.
  <fantasai> astearns, line-height-step inherits as an absolute
  <fantasai> astearns, it won't vary by font throughout the document
  Florian: It needs to stay constant as you go down the tree.
  dbaron: It's also problematic if you mix fonts because you don't
          know ratio of font line-heights.

  astearns: I'm cautiously enthusiastic by saying line-height:normal
            should be 1.2 instead of this weird inconstancy.
  Florian: If 1.2 makes more people happy I'm okay with that.
  TabAtkins: I think it's more common.
  Florian: Sure.
  dbaron: What we do now often is from font metrics. You're saying
          not to use font metrics anymore?
  Florian: Only if line-height-step is set.
  TabAtkins: So astearns was saying let's set it at all times. If
             that's problematic I say don't do it yet.
  Florian: For line-height:normal in general it's probably useful
           because some fonts are weird. But in this case the author
           is setting a value.

  koji: What about tall scripts that line-height:normal works great
        today and an author turns on step sizing and all lines
  TabAtkins: They will overlap on every browser so the moment you
             turn it on you'll see that they do and you'll change
  koji: If it's dynamically generated only some scripts overlap. So
        author can't always predict.
  astearns: The author won't necessarily see the connection is my
            concern. They turn on line-height and we do magic, how
            do they know to set the line-height
  fantasai: You can use the line-height-step property and adjust
            that. The numbers we're working with you set the
            line-height-step to 1.2em and you're going to get the
            behavior of 1.2 lines. If you set it to a value smaller
            than 1em you'll get surprising behavior, but that seems
            a rare case.
  fremy: The rule is the step line should be at least as big as
  fantasai: I don't think so. You'll want that for headings.
  fremy: Yes, yes.
  fremy: Makes sense.

  astearns: We've spent 20 minutes and I don't see an agreement. I
            do hear consensus that this is an issue we should have a
            solution for. Can we continue discussing in an issue?
  TabAtkins: Can we see if there's objection to fixing
             line-height:normal to a specific value when
             line-height-step is not initial?
  TabAtkins: We can set this down.
  astearns: We can try, but I read that koji would object.
  koji: I'm not sure I follow.
  astearns: TabAtkins suggests we solve this problem by making
            line-height:normal set to a particular value when step
            size is set to something other than initial. Basically
            Florian's proposal but without picking a number.
  koji: I see. I'm not strong enough to object, but I'm not sure if
        losing normal is good for authors.
  koji: It's probably better for Latin, but international scripts
        have higher heights.

  fantasai: If you want to allow normal with line-height-step then
            we need to add normal as a value to line-height-step
            because anything you set line-height-step to it will
  fantasai: So if we want to allow the use of normal we have to add
            it as a keyword.
  <gsnedders> fantasai yes
  koji: What I'm saying is to use a fixed value as a rhythm it never
        wants to overlap lines.
  TabAtkins: I'm not sure you understand fantasai's suggestion, koji.
  astearns: I'm not sure adding normal to step sizing is that useful
            because in a lot of cases you want something slightly
            larger than line-height.

  astearns: In any case, TabAtkins I don't think we have consensus
            on the direction.
  astearns: fantasai can you add your suggestion on the normal
            keyword to the issue?
  fantasai: Sure. If we make any behavior rely on the line-height
            initial the initial value needs to be none.
  TabAtkins: Yeah.

  Florian: I would like to urge people to discuss this because I
           think there is intent to ship from Blink so we need to
           solve this soon.
  fremy: It's fine to take time.
  Florian: Yeah. But let's do it over a couple weeks not years.
  astearns: There is consensus that this is a problem to solve.

Add background-repeat-x/y

  <astearns> https://github.com/w3c/csswg-drafts/issues/116
  astearns: We decided to spec these and mark as deprecated, but
            gregwhitworth noted it means there's an expectation
            everyone will implement. He'd rather mark as obsolete so
            there's no requirement to impl.
  gregwhitworth: I noted most of this in github. I'd really prefer
                 to have these marked as obsolete because they don't
                 even work as correct longhands to the short hand.
                 I'm looking for other opinions.
  TabAtkins: Other browsers don't need to impl. I haven't heard
             details on this not a long hand business.
  gregwhitworth: It's in the issue. You can't do multiple
                 backgrounds in the long hand.
  TabAtkins: Okay. That's fair.
  gregwhitworth: I'd prefer...I don't want to impl these things.
                 That's where we're at. I'd like to hear other
  Florian: I don't think Google cares about spec compliant. Do we
           need interop? If we do interop we need implementations.
  gregwhitworth: There's only 1 browser with this. If it was a web
                 compat issue there would be other impl.

  fremy: The problem is Chrome barely impl it. You can only set
         repeat or no repeat. I checked on github and the majority
         is just a test case file. That's prob why it's there is not
         break the test case.
  TabAtkins: Let's go back...you're looking on github for HTML
             source code?
  astearns: Let's not debate prevalence. There was data shown about
            a significant number of pages using it.
  <TabAtkins> (The number is .1% per our usage numbers, btw.)
  fremy: We don't want to impl the property. What Chrome is impl is
         something we don't want to impl. If they're willing to fix
         maybe we can impl.
  TabAtkins: We'll fix. Whatever.
  Florian: I'm so confused about it being so prevalent Chrome needs
           it but not prevalent.

  smfr: I think it's because they inherited it from webkit and they
        exposed it by mistake. We almost did it too. It's an easy
        way to pass the background repeat.
  Florian: That explains how it got there, but not the prevalence.
  TabAtkins: Based on raw numbers it's above the level we're willing
             to remove. If there's compat data that says a lot
             aren't needed we can remove.
  fremy: Is it more effort to remove than fix the impl. I think it's
         easier to remove then fix.
  Florian: I think the question is does it break the web. Easy
           evidence suggests it might. Other browsers not seeing it
           suggests otherwise. Deep data dive doesn't seem to have

  astearns: The request to the group was to make
            background-repeat-x/y as obsolete, not deprecated. This
            is the least resistance path. I saw shans asking for
            details from other browsers. TabAtkins are you okay with
  TabAtkins: We'll just not put it in the spec in that case.
  <fantasai> +1 to Tab
  <fantasai> if we don't need to implement it, then we don't need to
             invest time in speccing it
  Florian: If it was spec in the past that makes sense for obsolete,
           but if we've never had it and add it that makes no sense.
  TabAtkins: It's a historical note at best, not obsolete. We're
             proposing it because pages use them. We're trying to
             make our custom stuff exist in a spec or remove. Based
             on the least-effort-data-gather it looks like we won't
             be able to remove. So it should probably be part of the
             web platform and speced.
  <tantek> whether or not it is "in the spec" historically is
           irrelevant. it's whether or not it exists that's relevant

  astearns: Given the resistance to the F2F resolution can I resolve
            to wait on more data on background-repeat-x/y usage?
  tantek: I think we need a straw poll on the record.
  fremy: There's no need.
  [everyone talks]
  TabAtkins: I don't need a straw poll if I agree to what astearns
  tantek: I mean on the poll to obsolete it.
  <gregwhitworth> My only desire for obsolete is for author knowledge
  <gregwhitworth> I understand no one will implement it - and
                  understand you feel it's silly
  TabAtkins: I'm not going to put an obsolete feature in a spec
  tantek: I want people on the record saying they aren't going to
          impl and want it in the spec as obsolete.
  TabAtkins: It'll only come back if we say we won't kill it or
             someone else says they will impl.
  fremy: TabAtkins would you be fine marking as at risk?
  astearns: It's not in a spec.
  fremy: If we add it at risk.
  TabAtkins: I'm not going to spec it. Let's leave as is until we
             decide we don't need it or you'll deceit to impl it.
  <liam> +1 to Tab
  <zcorpan> TabAtkins++
  <Florian> TabAtkins ++
  <dbaron> Can we hear what Alan was going to propose before Tantek
  astearns: Yes. That's what I was trying to get at.
  astearns: I suggest to put it on browser compat data. We need to
            find out if it should be spec, at the moment it
            shouldn't go into a spec. We need to wait on data.
  fremy: Who will provide data.
  astearns: Chrome is the one that has to deal with it, so it's on
            them to show if it's needed or not.
  TabAtkins: Yeah.
  <fantasai> https://developer.microsoft.com/en-us/microsoft-edge/platform/usage/css/background-repeat-x/
             looks very wrong, btw

  <tantek> so we're agreed on not specing it now?

  astearns: Proposed is not to spec background-repeat-x/y for now
  <tantek> +1

  RESOLVED Do not spec background-repeat-x/y for now

  gsnedders: do we need an action to look into it?
  astearns: Because this is an internal Chrome thing it's on them
            and at their priority. That's my take.
  <gregwhitworth> agreed
  <jensimmons> +1

  <fantasai> well, the more we delay on this the more likely we are
             to be backed into a corner
  <fantasai> having one implementation in Chrome and none in other
             browsers isn't a stable situation
  <tantek> fantasai, hence I was trying to get at least a strawpoll
           to capture current opinions

2017 Snapshot Issues

  <astearns> https://drafts.csswg.org/css-2017/#issues-index
  <Florian> https://github.com/w3c/csswg-drafts/issues/935
  ChrisL: Earlier we discussed what should go in there...
  ChrisL: What modules. The only thing preventing it is the indexes.
          They don't work because bikeshed needs an update or
          Florian needs to be taught how to use it. That's why it's
          not published.
  Florian: I just posted the issue for how I tried to make it work.
           TabAtkins needs to fix or document how to do it right.
  TabAtkins: [catches up]
  TabAtkins: Easy enough.
  Florian: You need to tell me why my patch doesn't work.
  TabAtkins: Will do.

  ChrisL: Assuming that's done, we need a resolution to publish.
  Florian: I think we have one.
  ChrisL: Okay.

  ACTION TabAtkins help Florian with index issue
  <trackbot> Created ACTION-827

Revising CSS2 via NOTEs feedback

  ChrisL: Publishing as a note seems weird to me.
  ChrisL: It's by definition non-rec track so something rec track as
          a note is weird.
  Florian: What we really have is an ED to track, but that leaves it
           off the w3 domain. So we're suggesting a note mirror of
           the things we're preparing to put in the stable draft.
           It's not separate, it's a scratch pad.
  Florian: That's why we went with that idea.
  ChrisL: Is there anything there that requires patent disclosure?
          If it's not CR or FPWD the review is not triggered.
  Florian: We indeed only want fixes to 2.1. Also, these things will
           get back to rec track. We put them on the real ED and do
           CR/PR/REC every time there's something stable enough.
           We're not jumping steps, we're cooking them on the side.
           But if we had them on the real ED we'd have the immature

  tantek: ChrisL your intuition is correct. It is weird. However,
          the note itself is not rec track. The thing that is the
          note will never be rec. This is a hack of the process to
          achieve the goal we have of maintenance. Being aware of
          this I took the task at the F2F to bring this to the AB
          and say here's the group trying to do the maintenance
          that's suggested and there's a hole in the process and it
          needs a fix.
  <fantasai> We're essentially publishing the "proposed errata" page
             as a NOTE
  tantek: In my opinion the use here of a note to get wider review
          of errata makes sense. It's the only mechanism for us to
          get a TR link for review. There could be better, but there
          isn't one today.
  ChrisL: Every rec is published with an errata link even if it's
          empty. Is this because we want inline?
  tantek: Yes.
  ChrisL: AB is fine with this?
  tantek: I didn't say that. I took an action to take this process
          to the AB to point out this it is weird but this is the
          best we can do following the spirit and letter of the
          process to achieve the goal of maintenance.
  ChrisL: Thanks.

  Bert: We publish a WD and this note will be the same as the WD.
  fantasai: We're not taking it to rec.
  Florian: We're going to cherry pick things from it to send to rec,
           but the draft itself isn't going.

  astearns: The suggestion is publish a WD of css2 itself
  Florian: It'll go to rec but over the next 15 years. We'll be
           errata-ing for a very long time.
  fantasai: I think we'll declare it's obsolete at that point.
  fantasai: It'll be identical to REC-CSS2.
  Bert: So this will be the last time we publish as a whole. Next
        one we'll have holes in there. But why not do that as a WD?
        The WD and the note are the same. The 30 errata are agreed
  <gsnedders> https://dvcs.w3.org/hg/AB/raw-file/default/cover.html#rec-modify
              seems relevant in the Process

  liam: I think we have a process already. You publish the doc you
        will cherry pick from as a requirements doc. It's on the rec
        track and then becomes a note when satisfied. The process is
        light weight and it doesn't sound weird.
  Florian: But is it supposed to look like requirements?
  fantasai: This is a copy of CSS 2 with some edits. It's not a
            requirements document or a list of changes. It's an
            exact copy with a few updates

  Florian: To reply to Bert there are two ways for the WD. One is
           keep it ongoing for however long it takes to stabilize
           which will be long. We'll have 2.2 in many years.
           Alternately we have a 2.2 every so often and then we do a
           2.3 with some more things that have since stabilized. And
           carry on. This is higher overhead and people that look at
           2.1 won't auto-look at 2.4 even though it has been fixed.
  Florian: We leave a trail of unfixed specs. It's higher overhead.
  Bert: This new spec updates CSS2. It'll be a new 2. The latest
        link will go to the latest.
  Florian: The 2.1 link would be old.
  Bert: Go to the dated one, yes.

  gsnedders: I thought we had resolved.
  Florian: Yes.
  tantek: We did

  Florian: Bert the 2.1 undated is the first link that shows if you
           google css 2.1
  Bert: We can fix that.

  Bert: You said you doubt we'd get to rec quickly but the impl do
        what the errata say.
  tantek: That's a false assumption.
  tantek: I don't think it's productive to brain storm this on the
          call. Bert if you see a different cohesive process I'd
          suggest you post that to the list or github so we can see
  <gsnedders> +1 to what tantek just said (not productive)
  astearns: I think bert did post it to the list and I'm the only
            one that responded.
  astearns: I agree it's more productive on the list, but people
            need to respond on the list.
  tantek: I didn't see it and I didn't see a link to it.

  astearns: Okay.
  astearns: We're out of time for today.
Received on Thursday, 26 January 2017 02:04:57 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:06 UTC