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

[CSSWG] Minutes Telecon 2017-10-25 [css-ui-3] [css-ui-4] [css-fonts] [css-text-decor]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 25 Oct 2017 21:34:52 -0400
Message-ID: <CADhPm3sRW=FPv8yr_wF9e=MGDGnqUKSvHQQovMhEW9Lb0vDqbw@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 UI 3 & 4

  - RESOLVED: Take CSS UI 3 to PR.
  - RESOLVED: Take CSS UI 4 to an updated WD.
  - RESOLVED: Re-point CSS UI link to CSS UI 4 spec.

Fonts 3

  - RESOLVED: Publish a new Fonts 3 CR.


  - Though the group is generally supportive of the effort to
      incorporate better typography in issue #1888, the proposal to
      change <sup> and <sub> has a very high likelihood of causing
      breakage. This should instead be filed as a bug against Fonts 4
      or 5 as a proposal to change CSS. Any request should also have
      test cases to demonstrate what would be different between the
      current and proposed approach.

CSS Text Decor

  - RESOLVED: Add the statement that stroke should follow the curve of
              the glyph as well as adding a non-normative note that
              points out anything captured in the Github issue and add
              better pictures.

CSS Grid

  - The remaining open topics on issue #509 (percentages and intrinsic
      sizes: https://github.com/w3c/csswg-drafts/issues/509 ) will be
      discussed at the F2F.

F2F Meetings

  - RESOLVED: Have the mid-2018 meeting held week of July 2nd in
              Sydney with Google as host.


Agenda: https://lists.w3.org/Archives/Public/www-style/2017Oct/0042.html

  Rossen Atanassov
  Daid Baron
  Tantek Çelik
  Dave Cramer
  Alex Critchfield
  Benjamin De Cock
  Elika Etemad
  Javier Fernandez
  Dael Jackson
  Chris Lilley
  Peter Linss
  Myles Maxfield
  Anton Prowse
  Manuel Rego Casasnovas
  Melanie Richards
  Florian Rivoal
  Jen Simmons
  Alan Stearns
  Greg Whitworth

  Rachel Andrew
  Tab Atkins
  Tony Graham
  Michael Miller
  Lea Verou

Scribe: dael

  Rossen: Let's get going. Hello everyone.
  Rossen: Are there any additional items for the agenda or any changes
          we need to make?
  Chris: I sent one for CSS Fonts 3 which could do with a republish.
         Updated CR.
  Rossen: Thank you.
  Rossen: Any others?

Spec Rec Next Steps

CSS UI 3 & 4

  Rossen: First one is CSS 3 UI.
  <florian> http://www.w3.org/mid/BBBF6365-4251-426D-A3F0-4F3E7D6C48A4@rivoal.net
  Email Body:
      ## CSS-UI-3 ##
          * There are 0 open issues:
          * The change section is up to date:
          * All changes are fairly minor: mostly clarifications, and
              some small tweaks to align the spec with implementation
          * All testable / normative changes since last CR have tests
              updates or additions, linked to from the changes section.
          * The test suite is (IMO) sufficiently complete for REC
              advancement purposes.
          * The pass rate of the test suite meets CR exit criteria:
              (minus one test, which is pending the next build of the
              test-suite builder, and will be fine once that happens)
          * Implementation report:
          * The DoC is up to date:

  <Rossen> https://drafts.csswg.org/css-ui-3/implementation-report
  Rossen: florian sent an email yesterday summarizing state. There are
          no issues open, changes are up to date. Test suite is, in
          his opinion, meeting exit criteria. There is an
          implementation report ^
  <Rossen> https://drafts.csswg.org/css-ui-3/issues-2017-2
  Rossen: DoC is up to date.

  florian: Clarification. Since I wrote this there was a new test
           using box-sizing with grid. That test has bugs and isn't
           passing, but since it's grid I don't think we need to take
           it into account. Test isn't fail/pass it's just buggy.
  Rossen: Is the test necessary?
  <Chris> mark the test as optional
  florian: No, it's just linked because it uses box-sizing. I just
           wanted to clarify.
  Rossen: Reasonable.
  Chris: florian I suggest we mark the test as optional.
  florian: It's not optional for grid.
  florian: We can't mark it as optional just for UI.
  Chris: Okay. Then we just have to explain in the request.
  florian: I'll update the impl report to mention that.

  Chris: Everything looks great. Are there substantive changes since
         last CR?
  florian: Yes, there are some. I think that we might not have to
           cycle CR, but that's a judgment.
  Chris: My preference would be assemble a proposed PR and if it fails
         cycle CR.
  Rossen: Okay, that sounds great.
  Rossen: Are there any reasons why we shouldn't take this to a PR?
  Rossen: Chris any reasons?
  Chris: Nope.
  tantek: We should do it.
  Rossen: Not hearing objections.

  RESOLVED: Take CSS UI 3 to PR.

  Rossen: Congrats to editors and all involved.
  florian: Thanks tantek for giving me the shoulders to stand on to
           get this done.
  tantek: Thanks for all the work for the tests.
  florian: Chris will you work with me on requests?
  Chris: Yes. You notice I've been doing them as markdown. Is that
  florian: Yes.
  Chris: I'll give you the checklist after the call.

  tantek: Do we have a PR template?
  tantek: The markdown template, is there a blank?
  Chris: No. That's a good idea.

  Rossen: There was a tag on topic to this summary about UI 4.
  florian: UI 4 was a delta over 3, but since 3 is kinda done I merged
           in the 3 stuff to L4. I also caught up on pending actions
           and warnings on unstable sections. I think that warrants a
           2nd public WD. Should we?
  Chris: Go for it.
  Rossen: Objections?

  RESOLVED: Take CSS UI 4 to an updated WD.

  florian: Two follow-ups on this topic.
  florian: Should we switch unversioned prefix to be L4?
  Rossen: I don't see why we wouldn't.
  Rossen: CSS UI 4 will be the currently worked on.
  tantek: Do we have a policy of when we do that switch?
  Chris: We don't. We do it when the current one worked on switches.
  plinss: Policy is what's considered current. Someone looking for the
          first time, where do they look.
  Rossen: 3 isn't intended to move so 4 is the current.
  plinss: It's no longer a delta.
  florian: Yeah.
  plinss: Then it should be 4.
  tantek: It's reasonable to do at same time as PR request.
  florian: A resolution on that would be nice.

  RESOLVED: Re-point CSS UI link to CSS UI 4 spec.

  <plinss> (switch css-ui to css-ui-4 done)

  florian: Last, there is one thing in CSS UI that doesn't really
           belong. It's box-sizing. It's a patch over from CSS2.1.
           Some other spec should cover that...it should go into css
           sizing I think. Once that happens we can remove the patch
           from L4. For now it will be there, but I think other
           editors should look into doing this.
  tantek: That's a long standing request.
  florian: I think it was waiting for this patch to get to REC so it's
           a decent time to start looking at that.
  tantek: We looked at the permalinking.
  florian: Keep the section heading, but if a non-patch version starts
           to exist I can point there.
  plinss: No one should use unversioned short paths for permalinks.
  tantek: Is there a github?
  florian: No, but I'll make one.


  Rossen: Moving on. Flexbox testing.
  Rossen: There was a bunch of work by gregwhitworth and company. I
          called for volunteers last week. I don't think there were
          updates. gregwhitworth can you summarize what you need help
  gregwhitworth: Melanie offered, but it would help for there to be
                 more people. I opened all the issues about
                 non-trivial stuff on github. At somebody's leisure
                 they could start squashing those. Melanie and I have
                 started pivoting in that direction. They are where
                 they should live. If you can do any part of if and
                 submit a PR it helps me out.
  Chris: I can try and help depending on what else I have to do.
  Rossen: Thank you Chris.

  Rossen: gregwhitworth You said you needed help with bucketizing?
  gregwhitworth: No, I sent it to the list yesterday.
  gregwhitworth: I bucketized the non-trivial ones. I need to do some
                 trivial stuff but these are the buckets of tests we
                 need. If you can help, please self-assign and
                 describe what you're going to do. These are the 6
                 categories of areas we need help.
  gregwhitworth: Reach out to me if you have questions or update it on
                 the thread.
  Rossen: Thank you gregwhitworth for this awesome work and thanks
          Chris for volunteering.

Fonts 3

  Rossen: Next and final is Fonts.
  Chris: What's happened is there are a few sections marked as at
         risk. Some may need to move, some we're not sure. Seems
         worthwhile to update the spec that was last published in 2013
         so people know things are at risk. Means if we drop moving to
         PR we're good.
  Chris: I believe changes list is up to date. Maybe need to mention
         more on OM stuff.
  myles: I thought it was, but you're probably right I need to make
         another pass.
  Chris: I think it's just putting it in the changes section.
  myles: Sure. And if we republish I'll need help.
  Chris: Right.
  Rossen: Is this CR or WD?
  Chris: Updated CR with technical changes?
  Rossen: When will you be ready?
  Chris: I'll leave it to myles.
  myles: End of the week.
  Chris: Ping me when you're ready and I can send the request.

  Rossen: But you want a resolution.
  Chris: Yes, please.
  Rossen: Objections to publish a new Fonts 3 CR spec?

  RESOLVED: Publish a new Fonts 3 CR

  Rossen: Thank you chris and myles for all the awesome work.


Change default <sup> and <sub> styling?
  github: https://github.com/w3c/csswg-drafts/pull/1888

  Rossen: Anyone want to take this? florian and dbaron were involved,
          I know. Or myles.
  myles: I can summarize.
  myles: In HTML there's <sup> and <sub> that are defined in UA
         stylesheet to do vertical align and reduce font size. Now
         that open type fonts are available it may be that there are
         specific information in the font for this.
  myles: Issue proposes we change UA style sheet to turn on the font
  * tantek is going to go out on a limb and say there are likely major
           compat issues with touching this
  <tantek> perhaps experiment with MathML super/subscripts first?

  fantasai: Problem with this is that it doesn't handle anything that
            is nested so if you have any elements inside it like
            something to an exponent and the exponent has an exponent
            in it the feature won't work. So this breaks cases that
            would have worked.
  fantasai: We had when designing font variant feature it was decided
            not to do that which is why font spec doesn't recommend
            this as a replacement. Given that's the case we should
            advise HTML to not make this change.
  <tantek> fantasai's answer makes sense and would likely make a good
           FAQ in the spec.

  florian: I followed up trying to make a hybrid using font features
           for first level and then fallback for nesting. I'm not sure
           it handles all cases. If people want to keep investigating
           if we can write such rules maybe we can look into that. I'm
           not confident it's sufficient.
  Chris: I think it's a good approach. The PR is sent for tests for
         CSS 3 fonts actually mentions that. I think it's better to
         make the single level of nesting use the open type feature
         which will give you a better result in the common and if
         you're complex maybe you should use MathML.
  dbaron: I don't think...I think what chris suggests for top level
          won't work if the font metrics are inaccurate which is
          common. There's no guarantee it'll work or that a subscript
          will align anywhere correct so you could distinguish the
          super script of a superscript.
  florian: I think it works mostly.
  dbaron: It depends on how well the font metrics match the characters.
  fantasai: It also doesn't handle images in the subscript so I think
            there's a lot of things that will break.

  myles: First, I'd like to agree with fantasai and dbaron. Apart from
         that we would like some ability for the UA to use the glyphs
         if it can figure out the right way. We don't think this
         proposal is sufficient, but it is possible for a UA to use
         these glyphs. This proposal isn't the right way but we'd like
         some sort of affordance in the future.
  fantasai: But that would require new CSS features. We've discussed
            that in the past and people didn't want to do it. We can
            re-open those discussions. We should close this request
            and say you can't do that, but if you want to make a bug
            against Fonts 4 or 5 to make this possible you can do that.
  myles: I agree. This isn't the right place but the goal is noble.
  fantasai: We appreciate the effort to incorporate better typography,
            but this isn't the right place and it's not able to handle
            it currently.
  Rossen: Any other comments or suggestions?
  Rossen: If not we can close with fantasai's suggested rec.

  tantek: A couple of comments. I would suspect that changing this for
          sub and sup it will break compat in unpredictable ways
          since those tags have been used so long.
  tantek: Second question is, I didn't see a URL to a test case that
          demos what this would look like old vs new style. I think at
          a minimum we need that to consider this proposal.
  <fantasai> tantek's got a good point
  * bradk agrees with tantek, just didn’t want to beat a dead horse
  Rossen: Anyone have a test case or code that can demo this side by
  Rossen: I don't hear any. We can go back to the issue and wait for
          the people discussing it to see if anything will come

  fantasai: I think tantek has a good point about how this has been
            used a long time. People have tweaked their style sheet to
            make these tags look better and may be relying on
            vertical-align or font-size cascading through. We will
            break pages if we try and change the default stylesheet.
  * bradk always changes font-size, vertical-align, and relative
          position in order to “fix” SUPs
  fantasai: That will apply to any case where we try and make things
            better unless it's really automagic.

  Rossen: Anything else on this topic?

CSS Text Decor

ink skipping should conform to glyph shape
  github: https://github.com/w3c/csswg-drafts/issues/1093

  <Rossen> illustration https://twitter.com/TobiReif/status/839809400529383424
  fantasai: There was a complaint about how implementations, when they
            cut off the underline they cut off in a straight line. You
            don't want the underline to stop with a blunt edge and
            then have a gap between glyph edges, you want it to follow
            the edges of the glyph.
  fantasai: The spec doesn't say anything specific so I was thinking
            we could have advice, you should have underline edges hug
            the glyph.
  fantasai: There was a concern on performance which is why I'm
            suggesting a should. An implementation could decide to do
            it if font size is large enough, but not in general case.
            That would resolve a lot of performance considerations. I
            think spec should offer this advice.
  <fantasai> https://www.ietf.org/rfc/rfc2119.txt
  <fantasai> proposed text: "stroke endings should follow the curve of
             the glyph"

  myles: You can have a description of good typography. There's more
         to good underlining then having it follow contours of glyph.
         You'll want a larger explanation of good typography of
         underlines and that doesn't feel like it should be a
         normative description. It feels another spec or note.
  florian: Are they big enough that they cannot be phrased as shoulds?
  florian: Do you think it's too high level for normative?
  myles: Yeah.
  myles: If you're going to have a couple paragraphs on good
         typography it shouldn't be normative.

  Rossen: I'm hearing one proposal for adding the should which
          suggests how a good typography works for underlining and I
          heard some push back on why is this normative and not
          informative somewhere.
  dbaron: One comment on myles' statement. I don't want to get into a
          situation where you need to be an expert in other fields to
          impl the spec. The spec ought to say what you need to do to
          impl. If there's advice on good typography that should be
          known by an impl it should be on the WG to have that as part
          of the behavior the spec describes.
  myles: I think the spec does that as is.
  fantasai: It describes certain necessary things. We'd like the
            impl...given the option we'd say yes you should have the
            curve follow the glyph curve. What follow means, you have
            to think about that, but that's why we shouldn't be over
            specific. That's why we word things with an appropriate
            level of specificity so you know what to do.
  myles: Point I was trying to make...for example if the spec says
         underline should follow contour of glyph and implementors
         could use mask-base and then you have underlines in the curve
         of the g and that's worse typography. If you're going to have
         this it needs to be much longer. If it's a general of how
         underlines should work...
  fantasai: Typography is very broad. If you want more description on
            ways you can mess this up, that's fine. Typography of
            underlines in general is out of scope for this.
  myles: Right. Doing this..
  fantasai: It's not out of scope for the spec. L4 has the ability to
            adjust underline and will have much more detail. This
            topic isn't position, this is where you don't draw a line.
            A description here should assume position and thickness
            was chosen already.
  myles: I'm not talking position and thickness.
  <dbaron> If the spec says "use the position and thickness specified
           in the font metrics" then position and thickness aren't
           something that implementors need to think about

  Rossen: myles is your push back on adding this statement very strong
          or is this something you can live with?
  myles: I'm not going to object.
  Rossen: Okay. And fantasai if this was a non-normative note would
          you be okay or would you prefer the should?
  fantasai: I'd prefer the should so it's clear to implement this is
            the behavior that we want. We can add a note saying
            there's things you need to watch out for and if myles
            wants to point out anything not in the issue when doing
            the note I can add that.
  Rossen: In summary you propose to add the stroke of the underline
          should follow the curve of the glyph. That's the text?
  fantasai: Yes and a note to address myles's concerns.
  myles: We should also add a picture because the one in the spec is
         2px tall.
  fantasai: Good idea. We can have some of those Gs.
  dbaron: Will the note have the thing about maybe doing it only at
          large font sizes?
  fantasai: I can do that.
  <tantek> "large" = when it uses a lot of physical pixels
  <fantasai> probably px units is appropriate here, as resolutions
             increase we don't want to be doing it for paragraph-size

  Rossen: Proposed resolution: add the statement that stroke should
          follow the curve of the glyph as well as adding a
          non-normative note that points out anything captured in the
          Github issue and add better pictures.

  RESOLVED: Add the statement that stroke should follow the curve of
            the glyph as well as adding a non-normative note that
            points out anything captured in the Github issue and add
            better pictures.

CSS Grid

Percentages and intrinsic size
  github: https://github.com/w3c/csswg-drafts/issues/509

  Rossen: mats added a quick explanation of what Mozilla's back
          computation looks like for grid-gap.
  <rego> https://github.com/w3c/csswg-drafts/issues/509#issuecomment-334075296
  Rossen: I want to ask if anyone is prepared to speak to this issue.
  Rossen: If not we can push to next week or F2F.
  rego: Last week we said we'd leave for TPAC. We need more
        implementors. We resolved that we should back compute, but
        anyway it needs a lot further discussion.
  Rossen: I agree. It sounds like...I don't see in last week's
          resolution we'll discuss for F2F. I'll tag for F2F and
          remove the agenda+ for weekly calls.
  Rossen: I propose we switch topics if there are any.

F2F Meetings

  Rossen: If there's no other topics we can end early or we can
          discuss mid-2018 F2F.
  Rossen: Are we ready to discuss mid-2018 F2F meeting?
  Rossen: If not we can push this off.
  tantek: I'd like thoughts on that.

  Rossen: The last discussions were about Google hosting either at
          Australia or Toronto.
  <tantek> +1 to both
  ericwilligers: We thought we were picking Sydney and dates the week
                 of July 2nd
  <nainar> I'm not on the call. But what ericwilligers said.
  ericwilligers: Do we need to wait for someone to confirm?
  Rossen: We did pick dates, but there was an open question as to if
          Toronto was still on the table. That's my recollection. If
          we agree it's Sydney week of July 2 we can put that on the
          record and go with it.
  ericwilligers: That's my understanding.
  Rossen: I see nainar confirmed on IRC that's the proposal.
  Rossen: Objections to having mid-2018 meeting held week of July 2nd
          in Sydney with Google as host?
  <tantek> for some reason I recall August, but ok with July
  <nainar> I would say lets lock in July 2nd week for Sydney.
  <tantek> note US Holiday July 4th
  <tantek> just a note, no objection :)

  RESOLVED: Have the mid-2018 meeting held week of July 2nd in Sydney
            with Google as host.

  Rossen: Any 4 minute topics?
  Rossen: Thank you everyone and thanks Google to host us mid-2018.
          We'll talk next week.
  <nainar> Rossen happy to host! :)
  Rossen: Please remember to add agenda, book travel, book
          accommodation for F2F.
  Rossen: Remember next week is different time.
  <dbaron> next week's call will also be an hour earlier for Europeans
           than other APAC calls
  <dbaron> since Europe will have changed off summer time, but the US
Received on Thursday, 26 October 2017 01:35:48 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 26 October 2017 01:35:49 UTC