[CSSWG] Minutes Telecon 2017-09-20 [css-variables] [css-position] [css-ui-3] [css21] [css-inline] [css-grid]

  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.

User Agent properties and variables

  - RESOLVED: Rename what was 'constant' variables to 'environment'
              variables using env().
  - RESOLVED: Add this as an ED of variables L2.
  - RESOLVED: Add dino as an editor of variables L2 with TabAtkins.
  - RESOLVED: The initial set is safe area top, bottom, left and

Events for stickiness changes

  - RESOLVED: Close issue 1660 no change.

Using non fixed size SVG in the cursor property

  - RESOLVED: SVG without intrinsic dimensions MAY be supported (not
              MUST), add a note (to indicate the working group's
              original intent to have this a MUST).

Meta bug for line height

  - Everyone was again reminded to review this issue and provide
      feedback - github: https://github.com/w3c/csswg-drafts/issues/1796

fit-content() vs 'stretch' alignment

  - RESOLVED: fit-content does not grow past its argument due to
              alignment stretch.
  - RESOLVED: Keep fit-content behavior as-is, to not grow past
              max-content in presence of stretch.

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

Agenda: https://lists.w3.org/Archives/Public/www-style/2017Sep/0037.html

  Rachel Andrew
  Rossen Atanassov
  Tab Atkins
  David Baron
  Bert Bos
  Tantek Çelik
  Dave Cramer
  Alex Critchfield
  Elika Etemad
  Simon Fraser
  Dael Jackson
  Brian Kardell
  Chris Lilley
  Peter Linss
  Myles Maxfield
  Manuel Rego Casasnovas
  Melanie Richards
  Florian Rivoal
  Jen Simmons
  Alan Stearns (IRC Only)
  Greg Whitworth

  Benjamin De Cock
  Tony Graham
  Lea Verou

Scribe: dael

Agenda Setting

  Rossen: Let's get started. Good morning/evening/your time. As
          usual, first is any additional items?
  smfr: Can I request a rearrange? Can we discuss #5 before 2 & 3
        because I have to leave early. #6 should be brief.
  smfr: I'm fine with proposal for item #6.
  Rossen: You want variables first?
  smfr: Yes, please.

  Rossen: Any other addition?
  florian: I just re-opened something. I'm trying to find a link.
  <florian> https://github.com/w3c/csswg-drafts/issues/1391
  florian: This ^
  florian: If there's time. On writing modes.
  Rossen: Is this against current version?
  florian: Yes. We closed, but I found new information so I wanted
           to check if we're still okay.
  Rossen: Okay. Any other changes to agenda?

Spec Rec Next Steps

  Rossen: There has been quite a bit of progress sense last time I
          was on a call. There were a few items I wanted to touch
          on. Those are the ones that seem to be a bit behind.
  Rossen: Background and borders. Besides that we need tests...did
          we make any progress? It was supposed to be converted to
          bikeshed by eric. Did that happen or can we assign to
          someone else? How can we move this spec forward?
  Rossen: I will take the silence as no one has an opinion. Since
          draft conversion is the first thing to do, can we have
          someone volunteer?
  TabAtkins: I can go through and re-write it.
  Rossen: Thank you very much.

  Rossen: Transforms 1. There was some work that had to be done a
          month or two ago between Simon & Bogdan on transforms &
          SVG. That was open for quite a bit of time.
  smfr: I haven't had time to make progress.
  Rossen: What are we stuck on?
  smfr: There's a number of parts of spec that need reading by an
        SVG expert. Those parts are listed in issue, I think.
  Rossen: Depending on if SVG folks will gather during tpac...
  Chris: They won't. The group wasn't chartered at the time so they
         didn't request at tpac.
  Rossen: Last time I spoke I had the opposite, but if that's a
          fact, great.

  Rossen: Chris are we done with fonts 3?
  Chris: Not yet. I'm still chipping away at parts without tests. I
         meant to do a report for this week, I'll send one next
         week. We're close.
  Rossen: Are the features to move approved?
  Chris: That's fine. Just spec work.

  Rossen: And on transforms I'll make sure Bogdan reaches out to you
          smfr and maybe someone from the newly rechartered SVG

  Rossen: Writing modes. What is the deal? Are we ready?
  Chris: I was writing a transition to CR. fantasai answered my last
         question the day before. Having done that some tests in the
         suite have tests for L4 items. We need to fix that before
         going to PR.
  Rossen: CR period on this?
  fantasai: Should be the min possible.
  Rossen: 4 weeks?
  Chris: Yes.
  Rossen: Looks like we might be able to close at TPAC.

  Rossen: Bert css 2.1?
  Bert: I put back all the text I removed as fantasai suggested. I
        added informative links to the css 3. THere were other
        sections that could get those links, but all the text is as
        it was.
  Rossen: Is this waiting on review? Do you need help? Are we done?
  Rossen: Bert?
  [it appears we lost him]
  Rossen: I'll catch up with Bert offline.
  <Rossen> Bert: please reply back to this email
           and let us know what help you need from the rest of us
  <Bert> to Rossen: will do

User Agent properties and variables
  github: https://github.com/w3c/csswg-drafts/issues/1693

  smfr: Apple is proposing constants which are UA defined variables.
        They're supplied by the UA and not assignable in CSS. Work
        everywhere variables work. We intend them for metrics that
        are of interest to web authors to layout their pages. You
        can imagine one for things like scrollbar.
  smfr: Ones we're most interested in is iPhone X where it tells
        authors how to avoid rounded corners.
  smfr: Two aspects to this discussion. Is the constant function the
        right name? Second part is should we have a specific set and
        list them out?

  TabAtkins: Hitting the second one. You cannot have this as a
             feature and have a bunch of UA specific values. It
             doesn't help authors.
  smfr: I agree
  TabAtkins: Values need to be in spec. You can have UA ones behind
             a flag, but general set of values need to be specified
             and interop.
  smfr: We agree.
  TabAtkins: I love this and this is great. One bit I think I
             disagree. This should be usable wider than variables.
             You should be able to use a global in a MQ or
             something. It shouldn't be limited to use in properties.
  smfr: I think that's reasonable.
  florian: I'm not sure. 2 reasons. If it's not like variables we
           need to decide how it works. We'd have to invent a new
           thing. Also, it's not crazy to imagine that this might
           have different values per element in the DOM, like what's
           the default font and that's language dependent so you
           need a DOM. I'd be careful about expanding it.
  TabAtkins: That sort of thing would not be super compat with how
             we're thinking about this. But if we did something like
             that I would be fine to say in that case it's an
             invalid reference. Same as using color in a link MQ.
  florian: Okay.
  smfr: One concern with using this in MQ. We found authors often
        want them in conjunction with min and max. So that gives you
        feature creep where you want min and max in MQ.
  TabAtkins: Calc is allowed per spec, which you and then do min and
  smfr: Does any browser implement?
  TabAtkins: Dunno.
  smfr: If it's in spec, it's reasonable.
  TabAtkins: You might as well be able to. It makes sense.

  TabAtkins: Regarding names, I'm fine with constant, but thread had
             people object to that. They suggested global which was
             fine to me too.
  TabAtkins: fremy also pointed out this is the use case I was
             trying to reserve $ for. So that might work.
  smfr: I don't like $ because if someone doesn't know CSS it looks
        like magic. You can't google it. I think 'constant' is way
  florian: I think we want the extra param on it so if we have $ and
  <tantek> "you can't google it" is an interesting critique of any
           new symbol-based syntax
  TabAtkins: A function names $ so $(stuff)
  fantasai: These are environment variables so you could use the
  <fantasai> env() because these are environment variables
  <florian> +1 to env()
  myles: Other programming languages let you use $ for things that
         do vary.
  Chris: I quite like env option. It's an environment variable.
  TabAtkins: Except we want people be able to set the custom ones.
  Chris: Ah.

  TabAtkins: We recognized a lot of variables are a single global
             set at the root and the entire inheritance machine for
             that is a lot. We're working on if a variable is only
             set on the root we pop it in a separate storage area.
             This would let authors declare this sort of thing.
  TabAtkins: So you set it once and you have a global variable
             across the page.
  smfr: So you want the same syntax for that and these?
  TabAtkins: Names would have to be -- prefix to distinguish name
  fantasai: How to declare?
  TabAtkins: Options. Suggested JS API so you can monitor in JS and
             watch for changes so you can respond to them. If we
             have that structure it will give you read only access
             to these. We can allow write access too if it's in the
             right form. That's the basic.
  fantasai: That's not a good answer.
  TabAtkins: That's the basic.
  fantasai: I don't consider that basic.
  TabAtkins: Secondary is an @'function name' rule in your
             stylesheet. Give it a name and a value. It looks same
             as property, but as an @ rule. Only problem there is if
             you want to respond to changes we need to expose it in
             some JS API. So you either delve into CSSOM or we have
             to do some mapping between a JS object.
  TabAtkins: I have suggestions to this in a thread from where dino
             is suggesting edits.
  TabAtkins: Current idea is the big JS API can also be used from JS
             to demote both user and UA defined ones. @global lets
             you do it in stylesheets and they grow a similar
             map-like object that's a proxy. Therefore if you need
             to watch the values you can do so, but if you want to
             set up in JS you can do that. Whichever is best for you
             you have access to.

  smfr: How does that impact the naming?
  TabAtkins: Not at all. Whatever the function name is the @rule is
  smfr: Does it promote any of the options?
  TabAtkins: I don't think so. Any of the ones we've come up with
             are available and reasonable to read.
  smfr: Can we try and resolve on a name?
  Rossen: I heard env and global in the running
  smfr: Let me type them.
  <smfr> options: constant(), const(), env(), global()
  smfr: Those ^
  <fantasai> prefers env() out of that list
  <bkardell> I will go against the grain and say I like const()
  Rossen: So constant and const() since they do change can we rule
          those out?
  <florian> prefers env, ok with global
  fremy: global is what I prefer. I quite like the $, but of those
         global is most clear to authors.
  <dauwhe> "env" seems most descriptive
  <bkardell> prefers env
  Rossen: I see some people saying env, some people global. Which is
          easier to understand for non-English native speakers?
  ??: I voted for env
  Chris: The problem with env is it doesn't work for everything that
         TabAtkins does.
  TabAtkins: It's the same as for what bash uses.
  <bkardell> author-env variables like bash
  <bkardell> yes, what tab said !
  <Chris> I like env

  Rossen: Let's try and resolve on env. Let's get this one on the
          books for now.
  Rossen: Objections to renaming what was constant variables to
          environment variables using env()?
  smfr: I'm not particularly happy because we have an impl, but I
        guess we can change.
  TabAtkins: Given there is 0 spec text, I think we'd be angry if
             you pull a we can't change due to impl.

  RESOLVED: Rename what was constant variables to environment
            variables using env()

  <hober> much prefers constant() to env()

  Rossen: Did we resolve on the list of predefined?
  smfr: Well what spec do they go in?
  fantasai: variables
  Rossen: variables L2?
  TabAtkins: Either own or variables. Variables 2 is good.
  Rossen: Makes most sense given how far variable spec is.
  Rossen: Obj adding this as ED of variable L2?
  <tantek> seems reasonable
  <fantasai> sgtm
  <Chris> +1 to variables-2
  <bkardell> +1

  RESOLVED: Add this as an ED of variables L2.

  Rossen: Editor?
  smfr: I think I'd like to say dino will do it.
  TabAtkins: He put text together so he sort of self-volunteered.
  Rossen: Object?

  RESOLVED: Add dino as an editor of variables L2 with TabAtkins.

  Rossen: Now that we know what we're calling them and where, what
          will be the initial set of predefined values?
  Rossen: Should we take this back to github?
  florian: I think so.
  smfr: We'd at least like safe area top, bottom, left, right.
  TabAtkins: Let's get a list in GH.
  fantasai: I think we can resolve on those 4 values.
  Rossen: Objections to adding the initial set as safe area top,
          bottom, left and right?

  RESOLVED: The initial set as safe area top, bottom, left and right

  <fantasai> Further additions to the list should go into their own

Events for stickiness changes
  github: https://github.com/w3c/csswg-drafts/issues/1660

  Rossen: Summary, issue is someone asked if we can have an event to
          be able to know when the element goes into a stuck state
          and if it transitions to unstuck.
  Rossen: There were a few suggestions given, fremy pointed out if
          you use intersection observer everything works. After a
          little while people confirmed this is the case. They
          proposed to close no change.
  Rossen: I want to hear if you agree with this.
  smfr: I agree
  Rossen: Objections to close, no change?

  RESOLVED: Close issue 1660 no change.

Using non fixed size SVG in the cursor property
  Github: https://github.com/w3c/csswg-drafts/issues/1813

  Rossen: Thanks florian for progress updates. Remaining issue is
          non-fixed size SVG as cursor.
  <tantek> hmm - I thought we solved that by referencing a profile
  <TabAtkins> https://drafts.csswg.org/css-images/#object-sizing-examples

  florian: We mandate support for SVG and forgot to say anything
           about those without an intrinsic size. For general SVG
           there is support, but no one supports it without
           intrinsic size. I'm not seeing progress despite having
           bugs, so therefore I think we should change the spec,
           maybe to a may.
  florian: It's defined how you would do it, but nobody is.
  Chris: There is clear spec text to say what to do. It's not a case
         we can clarify, but no one seems to want to impl.
  TabAtkins: Does anybody allow other sizeless types?
  florian: Not, but they're a may.
  TabAtkins: I'm fine with it in same category as those.
  Chris: I am too, but won't be fixed by same method so that's even
         more of a may.

  dbaron: One comment is that when we change things in order to
          weaken requirements to have impl, I'd like to have notes
          to say what we intended so that people 5 years from now
          know why it's a may.
  florian: The behavior is not tied to SVG, it's anything without a
           size. So that would stay in and I would add prose to say
           if svg doesn't have intrinsic size you may support it.
           I'm happy to add spec text saying we wanted it.

  tantek: I think I agree with dbaron's point to add a note to give
          the intent of the group, but I kinda disagree with leaving
          it in as a may for something never implemented. If we had
          one implementation I'd be comfortable, but given no one
          implements that means it hasn't been incubated.
  Chris: In abstract I agree, but on this do you see a specific
  tantek: I don't, but I wouldn't know until we try and impl. It's
          unknown unknowns.
  Chris: It's the do we add 32 32 problem. This isn't rocket science.
  tantek: In this case I'm going to say display density is highly
          variable and changing.
  Chris: Okay.
  TabAtkins: I don't understand why density is relevant. There's a
             size the UA uses for the default to render cursor.
  <fantasai> tantek, if we don't allow this with a MAY we have to
             forbid it, which means any implementation that tries
             will be non-conformant

  Rossen: Let's step away from process and go back to the issue.
  Rossen: I didn't hear anyone disagree that the current lack of
          support suggests we might have to weaken current spec text
          with a may. Is this something people are objecting to? Or
          is this how to do better as spec editors.
  tantek: I am.
  tantek: I propose we do a note instead of normative text.
  florian: We can't do that instead of a may.
  florian: If we do a note instead of a may, we fallback to you must
           support svg or you must not support. That's not a good
  <tantek> the point was to explicitly *drop* from normative text
           what has not been implemented, AND add the NOTE: with
           explicit text indicating consensus intent of the WG
  <fantasai> tantek, you can't "drop" the text, you can forbid the
             implementation of this subset by *adding* text

  Rossen: Can I hear from dbaron? I understood it was a may with a
          note saying it wanted to be a must.
  dbaron: They're different points. I'm saying when we make changes
          to enter PR we should say what the old thing way.
  florian: And I'm happy to do that.
  dbaron: And that's different then tantek's point.
  Rossen: And tantek is about process which I don't want to do now.

  Rossen: Objections to changing a the must to a may for svg cursor
          and add a note explaining the intended must behavior?
  tantek: I object because that's not reflecting what florian wants.
  florian: It's a specific case.
  tantek: The way you phrased it isn't florian's proposal.
  florian: Rossen you said svg in general, it's just the
           non-intrinsic sized ones.
  Rossen: florian can you put the actual text?
  Rossen: thanks for the correction tantek
  <florian> PROPOSED RESOLUTION: SVG without intrinsic dimensions
            MAY be supported (not MUST), add a note
  <tantek> alternatively how about restricting the MUST to intrinsic
           sized SVG?
  <tantek> and then just leave non-intrinsic sized unspecified, and
           documented in the NOTE?
  <tantek> see alternative
  <fantasai> tantek, you'd have to explicitly undefine it to make it
             undefined, it's defined in css-images

  Rossen: Objections to florian's proposed resolution?
  <tantek> -0
  fantasai: I agree with that.
  Rossen: Anyone favor tantek's?
  florian: It's editor wordsmithing.
  Rossen: Objections to florian proposed resolution?

  RESOLVED: SVG without intrinsic dimensions MAY be supported (not
            MUST), add a note.

  <tantek> Florian I still think including normative spec text for
           something never implemented is a bad (risky) idea in
           general, even if in "this instance" it seems likely ok (
           per Chris's points). It sets a bad example and precedent,
           and I'd prefer if we encouraged trending toward more
           conservative normative spec text when attempting to exit
  <tantek> that is, rather than MAY for something unimplemented, we
           choose the "explicitly undefined" and NOTE with details
           we had consensus intent for in the WG.
  <TabAtkins> tantek I don't see the meaningful difference in those
              two wordings?
  <tantek> TabAtkins normative vs. informative text. Keeping it
           informative allows for more implementation
           experimentation (contradicting any such MAY even) without
           being non-conformant
  <tantek> MAY allows for non-implementation, but AFAIK does not
           allow for contradicting it.
  <TabAtkins> So your fear is that implementations might want to
              size SVGs for cursors in a totally different way than
              they do any other image?
  <tantek> in general I'm opposed to aspirational normative text at
           this point.
  <tantek> TabAtkins yes I'm claiming it is a case of sufficient
           possibility of unknown unknowns as to be lower risk to
           unspecify than specify as MAY.
  <TabAtkins> I disagree that this has any reasonable fear of having
              unknown unknowns crop up. It's unimplemented due to
              low priority, not due to it being hard or confusing.

Meta bug for line height
  github: https://github.com/w3c/csswg-drafts/issues/1796

  florian: I still want people to review. There hasn't been review
           in github. Repeating subject:
  florian: I wrote a bunch of test cases to figure out if we're
           interop on various aspects of line-height. First, please
           confirm tests are right. Area I found we're not interop
           is a bit deeper on something discussed where first
           available font doesn't include the space character.
  florian: That's and the font file for font metrics are only places
           with changes. Please, please review my work. This is
  Rossen: Anyone have reviewed? If not, we can consider this a CTA
          to give feedback.
  Rossen: Okay. Please give feedback to florian.

fit-content() vs 'stretch' alignment
  github: https://github.com/w3c/csswg-drafts/issues/1732

  Rossen: fantasai can you take this?
  fantasai: I haven't looked lately. Looking now.
  Rossen: I think you brought this up 3 weeks ago.
  fantasai: I think in order to make progress on writing modes we
            should do florian's extra.
  Rossen: Grid issue you want to discuss on GH?
  fantasai: no...it's okay.

  fantasai: Issue was we have a stretch value for align and justify
            content. These align and justify grid tracks from a high
            level. One of the options is stretch, kinda like flex
            lines. If you choose stretch we do so by distributing
            space to auto-size columns equally. No auto sized
            columns, nothing happens.
  fantasai: Question is if it should apply to fit-content or not.
            Looks like rachelandrew asked a few authors and they
            expect it not to go past argument of fit-content, but
            there was a question of should we apply the extra space
            at all.
  fantasai: For sure I think we can say fit-content doesn't go past
            its argument due to stretching.
  <rachelandrew> this was the issue as it came up
  Rossen: I'm in favor as an implementor.
  Rossen: Objections to resolving that fit-content does not grow
          past its argument due to alignment stretch.

  RESOLVED: fit-content does not grow past its argument due to
            alignment stretch.

  fantasai: Second is should fit-content grow past it's max
            content...if we're below the argument, the clamping one,
            do we grow fit-content it the stretch is set.
  fantasai: For that question, I don't know. We don't seem to have
            any feedback one way or another of what should happen
  jensimmons: Alternately the content would not stretch?
  fantasai: If there's auto tracks there, if not start.
  jensimmons: And they could adjust by not using stretch?
  fantasai: Yes, case where it would make a difference is if there's
            fit-content and an auto column. They have very similar
            behavior except fit-content has additional clamp.
  Rossen: This scenario was a canonical example we had originally
          when working on grid. The ability to have a menu system
          based on size of items inside and let the extra space go
          into the rest of the content area. Using fit-content with
          auto columns or fr columns was the way to achieve this.
  Rossen: If you take away the guarantee of fit-content that's not
          just for grid and we start changing what fit-content means
          then this is a pretty, in my opinion, radical change.
  Rossen: I haven't seen any really strong cases to change that and
          I would prefer if we don't (as an impl).
  jensimmons: You want to stretch beyond max-content?
  Rossen: I don't.
  fantasai: Auto will go beyond max-content, but fit-content won't.
  Rossen: fit-content was designed to fit-content
  rachelandrew: I'd agree with Rossen I don't think people would
                expect it to stretch. I'd prefer fit-content stays
                the way it is.

  Rossen: We're at top of hour.
  fantasai: We should go for resolving
  <tantek> +1
  Rossen: Objections to keep fit-content behavior as-is, to not grow
          past max-content in presence of stretch.

  RESOLVED: Keep fit-content behavior as-is, to not grow past
            max-content in presence of stretch.

  Rossen: florian sorry we didn't get to writing modes, but I urge
          everyone to look at this issue and we'll discuss next week.
  <tantek> please link issue for writing-modes
  <dael> writing modes issue https://github.com/w3c/csswg-drafts/issues/1391
  Rossen: Thanks everyone.

  <rego> I'm late, but I think that the previous resolution
         contradicts the last one somehow :-)
  <rego> the first resolution was that "fit-content does not grow
         past its argument due to alignment stretch"
  <rego> but it's affected by stretch
  <rego> in the last comments it seems we want it to fit the content
         and not be affected by stretch at all
  <fantasai> They're not contradictory, the first resolution
             restricts what would be possible if it were affected by
  <fantasai> Then we discussed whether it should be affected by
  <fantasai> Because we knew for sure we didn't want to stretch past
             the argument, so we resolved on that first.
  <rego> fantasai, ok, I understand it now

Received on Wednesday, 20 September 2017 23:50:30 UTC