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

[CSSWG] Minutes Telecon 2017-02-21 [css-2018] [css-sizing] [css-grid] [filter-effects] [css-typed-om]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 21 Feb 2018 19:15:13 -0500
Message-ID: <CADhPm3su10podgr1S_quH-eTcW2xiH=waOC=nUdKtO-efui_UA@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.

TYPO talk

  - Anyone interested in coordinating the TYPO talk should reply to
      the thread on the member list.

CSS Snapshot 2018

  - Members were asked to add to the github issue
      (https://github.com/w3c/csswg-drafts/issues/2281 ) what items
      should be in the 2018 Snapshot.

CSS Sizing

  - The group agreed with the spec text for handling placeholder text
      as max(placeholder, value). (Issue #2141)
  - RESOLVED: Have a UA defined minimum on content based sizes for
              these new keywords with suggestions of possible
              minimums. (Issue #2141)
  - RESOLVED: Single line inputs have no breakpoints for purpose of
              calculating min and max. (Issue #2141)
  - dbaron and fremy will review the proposal in issue #1132 (
      Percentage sizing section is kind of vague) next week before
      it's re-raised for resolution.
  - RESOLVED: Publish an updated WD of CSS Sizing 3

Typed OM

  - RESOLVED: Specify USVString for all new Houdini APIs.

Filter Effects

  - The group agreed to make no change on FXTF Issue #178 (Why can't
      opacity() filter function ever increase opacity?)

CSS Grid

  -  RESOLVED: Have a minimum of 10k tracks in each direction as a
               recommendation. (Issue #2261)


Agenda: https://lists.w3.org/Archives/Public/www-style/2018Feb/0019.html

  Rachel Andrew
  Tab Atkins
  David Baron
  Amelia Bellamy-Royds
  Tantek Çelik
  Dave Cramer
  Alex Critchfield
  Benjamin De Cock
  Elika Etemad
  Simon Fraser
  Tony Graham
  Dael Jackson
  Brad Kemper
  Vladimir Levantovsky
  Chris Lilley
  Peter Linss
  Anton Prowse
  Liam Quin
  Melanie Richards
  Florian Rivoal
  Dirk Schulze
  Geoffrey Sneddon
  Alan Stearns

  Michael Miller
  Manuel Rego Casasnovas
  Lea Verou
  Greg Whitworth

Scribe: dael

  astearns: Let's get started.
  astearns: Does anyone have anything to add to the agenda?
  astearns: There are agenda order changes in IRC.

TYPO talk

  Vlad: I mentioned everything in my email. I got some desired topics
        from the organizers. It's a suggestion, not a requirement.
        Theme of conference is variable fonts and responsive web so if
        we introduced something from CSS on those subjects that would
        be in line.
  Vlad: My focus is to make sure we don't leave this to last minute so
        we can present the group best possible.
  myles: Is this recorded?
  Vlad: Yes and mostly video recording too.
  Vlad: You can see prior recordings by looking through the speaker
  Vlad: All talks are video so I believe CSS will be. It will not be
  myles: We should talk after the call.
  Vlad: That's why I wanted to make sure we're ready and have time to
        finalize the speaker list and items.

  astearns: myles and Vlad will talk after call. There's a thread on
            the member list and a wiki page someone started to talk
            about font metrics issues. Good to add to the thread and
  Vlad: I think it was fantasai that brought the wiki up and this
        would be the right audience for that discussion.
  astearns: I think it would be good to have several speakers fill
            that with short focused talks.
  astearns: I'll ping fantasai about a talk for font metrics. It was
            fantasai or dbaron bringing that up. It would be great as
            a 10 minute talk.
  Chris: I think it was dbaron.

  astearns: Please contribute to the thread. I will start wrangling
            people with Vlad to get things more set.
  Vlad: Thanks.

CSS Snapshot 2018
  github: https://github.com/w3c/csswg-drafts/issues/2281

  Chris: I listed a few things, florian added more. I'd like more
         discussion. Editing work is small. I think we should be able
         to do this quickly if we can agree on in and out.
  astearns: Shall we have this as a reminder to look at the thread?
  Chris: Sure.
  astearns: There are suggestions in the thread. If people could add
            their opinions perhaps we can resolve on a future call.

  florian: Reminder to TabAtkins there is a bug in bikeshed or my
           brain and indexes aren't gen properly. Please look at that.
  TabAtkins: Cool.
  astearns: Hopefully we can get that squared away.
  <florian> TabAtkins: direct link to the indexes issue:

CSS Sizing

Please add vertical auto-resize textarea field
  github: https://github.com/w3c/csswg-drafts/issues/2141

  TabAtkins: We've got a few details we weren't sure of. First: right
             now we have it specified that the width of something with
             a placeholder is the larger of the widths of the
             placeholder or contained text. That way you won't get
             size jiggle when you click inside.
  TabAtkins: Have a comment from fremy it's the right thing to do but
             hard to implement in Edge. Any other opinions or stick
             with spec?
  astearns: Seems like right thing to do to me.
  astearns: Other opinions?
  astearns: Want a resolution?
  TabAtkins: Just a check.

  TabAtkins: Next: We could that empty inputs...a 0 size is hard to
             click into. There's probably some measure of min size
             that should come from UA in width and height. We wrote UA
             can enforce the size required to hold a single character
             as a minimum size, even if it's empty.
  TabAtkins: Sound fine? More specific? Remove text?

  bradk: Suggest that could be in UA stylesheet.
  TabAtkins: Maybe as a min width or min height. Possibly.
  fantasai: fremy sent a comment why we shouldn't do it with min
            height in UA stylesheet. Comment here:
  fantasai: Authors might animate height from 0 and if we impose a min
            now the animation would clamp at non-0 size. He's got a
            form control with a height of less than the min we
  TabAtkins: And more generally there's no reason to impose a min size
             on arbitrary form controls. But when they're being
             content sized there's a reasonable minimum. I agree we
             shouldn't use min width and height for this.
  astearns: Sounds like discussion is landing with not having a
            minimum content base size?
  TabAtkins: No, we're explaining why not use min-width and height to
             impose it. We still think you should impose it.

  astearns: I'm wondering since at the moment if you don't specify a
            height on one of these you'll get something with 0
            height...is imposing min a breaking change?
  TabAtkins: That's not what happens right now.
  fantasai: Textarea takes its height from the rows.
  TabAtkins: This isn't about auto size. This is when you activate
             content based sizing which is a new feature.
  fantasai: Using min-content keyword. It's a minimum on the used
            value of this keyword.
  fantasai: [missed]
  astearns: We're going to add a minimum height to the behavior of
            these new keyword values when there is no content to size
  TabAtkins: Height and width.

  florian: Is this only inputs and text areas?
  TabAtkins: Only these.
  fantasai: Not about content editable things.

  astearns: Shall we have a resolution on adding a minimum size to
            these new keywords?
  astearns: Does anyone what to discuss what the size should be?
  florian: UA defined.
  fantasai: Yes, it's UA defined but there is an example.
  astearns: Is that really UA defined?
  fantasai: The UA gets to choose what the minimum to be. Our
            suggestion is the size for a single 0 width character
            because that gets you straightforward behavior when you
            focus the item.
  astearns: Why do we want to let UA?
  fantasai: It's a font control and they have a lot of UA defined
            behavior. Some UA might decide if they want the form
            control easier and it should be big enough to contain the
            letter 'n' for example.
  astearns: uuuuu....okay. I prefer spec something so you can get more
            interop if there's no pushback.
  TabAtkins: I support fantasai in that we should support UAs wanting
             to be large enough to be a tap target, for example.
  astearns: Can you put that suggestion is as the example? Like you're
            free to make it larger, but not suggest 1px in either
            direction is useful?
  fantasai: It really depends on how they're implement form controls
            in terms of UA defined items. There's a reason form
            controls are UA defined and this is the category where too
            precise definition locks us in. UA should look for best
            user experience. If every platform is the same we can
            standardize then.
  TabAtkins: I don't disagree that we can put in tap target size as
             another suggestion.

  astearns: Proposal: Have UA minimum on content based sizes for these
            new keywords with suggestions of possible minimums.

  RESOLVED: Have a UA defined minimum on content based sizes for these
            new keywords with suggestions of possible minimums.

  TabAtkins: Next is min-content for <input type=text>. There's no
             breakpoints there. But right now it's magic only. UA
             style sheets don't clarify, they just strip lines and
             render as a pre. We probably want additional magic
             clarified. If it's intended to be a single line we'll
             clarify that the min and max content are the same and the
             full size of the stuff inside.
  TabAtkins: This might be accomplish-able through a UA important rule.
  fantasai: Alternate definition is to have min and max content mean
            different things based on where there could be a
  TabAtkins: Doesn't sound useful can't get it to size to that. It
             wouldn't do anything useful.
  fantasai: Not sure what you mean. If you set input to be min-content
            then it's the size of the longest word.
  TabAtkins: That has no meaning if content isn't breaking. There
             would still be scrolling because you'd have lots of
             content on their size of the big word.
  fantasai: There's no word that wouldn't fit.
  astearns: I think I agree with TabAtkins. I don't see how it's
            useful. It would have the weird effect of making input
            larger as you add characters.
  florian: And i18n problems on what's a word.
  TabAtkins: Not in that case because breakpoints.
  fantasai: We know where the breakpoints would be.

  fantasai: Question is is there a reason for these things to be
            different. We as spec writers don't have a reason. If
            authors do we can make it different.
  fantasai: If there's no compelling use case for different then they
            shouldn't be different.
  astearns: If we're not going to have min-content on an input be the
            longest word are we saying min and max is same result?
  TabAtkins: Single line inputs have no breakpoints for purpose of
             calculating min and max.
  astearns: I'd be fine with that.
  <dbaron> +1 to what TabAtkins said
  astearns: fantasai okay?
  fantasai: Yeah. As long as there's no one with a reason to do
  astearns: Objections to resolving?

  RESOLVED: Single line inputs have no breakpoints for purpose of
            calculating min and max.

  astearns: Last item looks to be a review of the new text. There's
            quite a bit so a few eyes would be good.

  astearns: One question is we want to republish sizing as updated CR.
            This is a new feature, is there a reason this is L3 as
            opposed to L4?
  fantasai: Keywords are introduced in L3 so we need to define their
            behavior in L3.
  TabAtkins: We could undefine the keywords and move the definition to
  fantasai: That's true.
  fantasai: I don't think it's necessary at this point.
  florian: Depends on if we prioritize rec faster.
  Chris: Is it WD or CR?
  astearns: It is just a WD. My concern is moot.
  gsnedders: There are no tests for sizing so it won't get rec very
             fast unless people provide tests.
  astearns: Okay. I was wrong on my concern. Anything else on this
  TabAtkins: No.

Percentage sizing section is kind of vague
  github: https://github.com/w3c/csswg-drafts/issues/1132

  fantasai: There's...the last comment is a summary.
  <astearns> https://github.com/w3c/csswg-drafts/issues/1132#issuecomment-363623845
  fantasai: Proposed edits for the behavior is [reads]
    If the box is non-replaced, then the value of any sizing property
    specified on it as an expression containing a percentage is
    treated for the purpose of calculating the box’s intrinsic size
    contribution only as that property’s initial value. For example,
    given a box with ''width: calc(20px + 50%)'', its max-content
    contribution is calculated as if its 'width' were ''width/auto''.
    The percentage is honored as usual, however, during the actual
    sizing of the box itself.
  fantasai: Seems to be interoperably implemented.
  fantasai: If you have a mix width of calc(20px+50%) we consider it
            as [missed] and once containing block resolves we resolve
            the percentages. There's a WPT PR and we're asking for WG

  astearns: Has anyone reviewed the test PR?
  fantasai: There's no spec text. Somebody needs to look at tests and
            see if that's what people want to add to the spec. We need
            a review of the tests.
  dbaron: Proposal is matching the behavior of percentage widths?
  fantasai: There may be cases I didn't test correctly.
  dbaron: I think it does. But I think if it doesn't it ought to match.

  astearns: dbaron could you review?
  dbaron: Probably but maybe next week.
  astearns: Is that enough for now fantasai?
  fantasai: If anybody else wants to review I'd prefer they do it in
            parallel with dbaron. This is the last open issue as far
            as I'm aware at which point we'd like to republish and
            issue LC.
  fantasai: It's been on the agenda for 2 weeks. If someone needs to
            review and they need time let's assign it to that person.
  astearns: Any other engines have a volunteer? fremy can I ask you to
  fremy: I guess yes. It may not happen this week, but in theory yes.
  astearns: Other volunteers?
  fantasai: You can just defer to dbaron. But if you want more time I
            need to know how much.


  astearns: Since this is a WD we can publish what we have and leave
            this open.
  fantasai: Yes, but I'd like to get to a point where we can ask for
            final review. But I am happy to publish a WD.
  astearns: Opinions on an interim draft or wait for this to resolve?
  astearns: It is a WD so fantasai I can leave it up to you. I'm happy
            to call for resolution at any point.
  fantasai: Now is fine. It's out of date.
  astearns: Objections to publishing an updated WD of CSS Sizing?

  RESOLVED: Publish an updated WD of CSS Sizing 3

  Chris: That's an update WD so it can auto publish?
  fantasai: Yes.
  Chris: Thanks.
  <fantasai> TabAtkins, can you publish?

Typed OM

Should we be using DOMString, USVString, or CSSOMString?
  github: https://github.com/w3c/css-houdini-drafts/issues/687

  TabAtkins: Should things be specified as DOMString, USVString, or
             CSSOMString. I need guidance. I got that URL should be
             USVString, but for the rest I'm not sure what to do. Any
             guidance appreciated.
  plinss: In general I think we should be doing USVString and only
          DOMString where we need it for backwards compat
  TabAtkins: And we did CSSOMString to allow that but for engines that
             are more efficient on DOM to do that.
  plinss: That's why I'm thinking for new APIs let's do USVString and
          not propagate more DOMStrings.
  florian: Reason for CSSOMString was an implementation difficulty I
  gsnedders: But elsewhere in platform spec have changed DOMString to
             USVString. I'm not sure why we have CSSOMString at all
             rather then we expect will change.
  florian: CSSOMString is for should do USVString but do DOMString if
           you have to
  plinss: Reality is they will do the DOMString if they can't do
          anything else so why give them permission to do it wrong if
          they can do it right?
  <gsnedders> what plinss said

  astearns: Sound to me like general consensus is to use USVstring.
            I'm not hearing anyone cheer for CSSOMString.
  florian: Then we should move away from CSSOMString everywhere.
  astearns: Fair but we can try it with this new API and any in the
            future and see how much we can go back as we find out if
            this one works.
  astearns: Objections to spec USVString for this Houdini API? Is it
            just this one or all?
  TabAtkins: Might as well be all.
  astearns: Objections to spec USVString for all new Houdini APIs?

  RESOLVED: Specify USVString for all new Houdini APIs.

Filter Effects

Why can't opacity() filter function ever increase opacity?
  github: https://github.com/w3c/fxtf-drafts/issues/178

  AmeliaBR: We have an opacity shorthand filter function. It takes any
            integer >0 but any >1 is clamped to 1. So opacity filter
            reduces but cannot increase opacity. So a number of
            features like taking a blur or drop shadow and increasing
            opacity of blurred areas is not possible.
  AmeliaBR: We're getting late in the process for major changes. All
            engines currently implement as specified. Problem is
            because the way it's specified it won't be easy to add
            this in later. If it was currently written that >1 is
            invalid we could add it later without worrying about
  AmeliaBR: As far as an author prospective I found this to be an
            arbitrary restriction so I wanted to change, but I
            recognize it's late in the game.

  krit: 2 comments. Spec was following implementation already, that
        was already implemented. Point 2 that I think TabAtkins
        mentioned if you have some areas with a 0 they will not get
        opaque again. There might be issues there. Also some browsers
        might have optimizations.
  krit: Biggest issue is there might be content already that can
        increase >1 and this code will result in 2 different results.
  TabAtkins: I take back my objection. AmeliaBR pointed out that's
             exactly what you do want.
  AmeliaBR: It's consistent with behavior of other shorthands like
  smfr: There are other issues. 1 is that some browsers may rely on
        platform graphics libraries that expect 0-1 value. Second is
        with premultiplied alpha. Many engines will store in that and
        you have very small rgb units and when you multiply that you
        get this gray. I think that'll happen with >1 opacity.
  krit: For some effects we require to go back to unmodified, yes.
        Depending on how impl is done you get very different results.
  smfr: You've got data loss with premultiplied alpha.
  smfr: I also don't like because it gives us different behavior in
        opacity. If we want this we should think about a different
        filter - component transfer.
  AmeliaBR: Yes, that one lets you modify each channel.
  Chris: Agree. Exposing that is the best way forward.
  AmeliaBR: That is something that could be added in the future
            without web compat. Add a separate function in the future.
  smfr: That would be fine.
  TabAtkins: sgtm.
  AmeliaBR: Sounds like a reasonable way forward. Hoping to get
            filters stable so I'll accept.
  astearns: So we'll close this issue no change and put in component
            transfer as future work.
  AmeliaBR: I'll open an issue on filters 2.

CSS Grid

"Clamping Overly Large Grids": Perhaps have a minimal required track
  github: https://github.com/w3c/csswg-drafts/issues/2261

  TabAtkins: Earlier in the draft we had a minimum required grid size
             and it was fairly large. We removed that because it was
             too much. Implementations can't actually support a
             million cells by a million cells. Still good to have a
             min. Firefox has 10,000 in positive and negative
             direction. Seems reasonable. Does the WG like that
             number? Different number? Don't like having a min?
  fantasai: Min should be the lowest possible number that we think is
            reasonable to consider. This should be that the author can
            count on there being at least this many tracks.

  fremy: Can we verify what browsers accept?
  fantasai: Report from implementors. Gecko is 10k. Chrome is 9,999.
  fantasai: If Edge is lower we can go with that. We don't prefer the
            number, just that it's there. And it's a should.
  astearns: fremy do you know if Edge has a limit?
  fremy: I don't know but we should be fine with 10k in each direction.
  astearns: Anyone not okay with the idea of a minimum?
  astearns: Proposal: have a minimum of 10k tracks in each direction
            as a recommendation. Obj?

  RESOLVED: Have a minimum of 10k tracks in each direction as a

  astearns: That gets us close to the end and I'm not seeing a 1
            minute issue. I think we'll call it a couple minutes
            early. Thanks everyone and we'll talk next week.
Received on Thursday, 22 February 2018 00:16:08 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 22 February 2018 00:16:09 UTC