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

[CSSWG] Minutes Telecon 2016-07-27 [css-ui-4] [user-select] [css-values] [css-color] [css-tables]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 27 Jul 2016 21:13:28 -0400
Message-ID: <CADhPm3sP34HuZay6jX99U-N09ooDAU9E_6jYAQPSNS5YYEC1BQ@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.

Start adding things to TPAC agenda

  - Some items being discussed on github have mentioned that they
      would be good F2F topics. Please add these items (and any
      other topics) to the wiki.
  - Everyone planning on attending was also reminded to make
      bookings and pay for registration before prices go up.

Call for Ahem font editing

  - Myles will be handling the font editing.

[css-ui-4][user-select] value is used value?

  - Pretty much everyone agreed that user-select should be used
      value. gregwhitworth needed to check with his development team
      so the formal resolution will be recorded on next week's call.

[css-values] should allow <percentage> as a resolved type

  - RESOLVED: Accept the changes in this commit:
      to allow percentages as a resolved type.

[css-color][css-tables] should 'opacity' be hoisted from the table
    box to its wrapper box

  - RESOLVED: Hoist opacity from table box to its wrapper box.

[css-tables] Calc for table layout

  - RESOLVED: Defer this issue to V&U 4.
  - RESOLVED: A calc() with only percentage or only length is
              required to be resolved in V&U 4.
  - There was no decision on addressing a combined length and
      percentage. More thought on it was needed.
  - RESOLVED: Publish updated V&U 3 CR.

[css-color] Unnecessary comma in color()

  - RESOLVED: Use this color syntax: color( [ <colorspace>? [
              <number>+ | <string> ] [ / <alpha> ]? ]# [ , <color>
              ]? )
  - RESOLVED: Backport slash to the short functions like: rgb( [<r>,
              <g>, <b>] | [ <r> <g> <b> [ / <alpha> ] )

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

Agenda: https://lists.w3.org/Archives/Public/www-style/2016Jul/0065.html

  David Baron
  Bert Bos
  Tantek Çelik
  Dave Cramer
  Elika Etemad
  Simon Fraser
  Tony Graham
  Dael Jackson
  Brad Kemper
  Ian Kilpatrick
  Chris Lilley
  Myles Maxfield
  Michael Miller
  Florian Rivoal
  Geoffrey Sneddon
  Alan Stearns
  Lea Verou
  Greg Whitworth

  Rachel Andrew
  Rossen Atanassov
  Tab Atkins
  Daniel Glazman
  François Remy
  Jen Simmons
  Ian Vollick

Scribe: dael

Start adding things to TPAC agenda

  astearns: Let's get started.
  astearns: First thing, does anyone have anything extra to add?

  astearns: TPAC. It's coming up soon.
  <fantasai> https://wiki.csswg.org/planning/tpac-2016
  astearns: If you haven't added your name to the wiki please do.
            Please start filling the agenda with topics.
  astearns: I've noticed on a few github issues people have
            mentioned having them at a F2F so start linking those to
            the agenda so we can see what we'll talk about.

  ChrisL: If people have registered they should pay. I think the
          price goes significantly up after 2 September.
  astearns: And I believe flights will get more expensive too. So
            make plans and pay the W3C.
  Florian: And I'm coordinating if you want to AirBnB.
  dauwhe: I think some TPAC hotels are already full.
  astearns: I'm staying at a near AirBnB and there's lots of

  astearns: Any other TPAC items?

Call for Ahem font editing

  astearns: I think the second item is covered.
  astearns: There was a call and myles has volunteered, so thanks.
  myles: I've been doing similar in webkit.
  fantasai: There's an updated version from Sergey and MS so you
            want to edit that file.
  astearns: Any other testing font requests, get them in now!

  <ChrisL> please add tests for all of css3 fonts opentype features
  <fantasai> Thread wrt Ahem at
  <myles> ChrisL: i did in webkit, i could add the tests to the w3c
  <fantasai> ChrisL, see the other fonts. Ahem is for layout testing.
  <ChrisL> srsly? that would be super cool.
  <astearns> ++ to adding more WebKit tests to the w3c suite
  <ChrisL> fantasai, I know what ahem is for. and i was actually
  <fantasai> I mean.. we do need tests for all of those things :)
  <fantasai> myles: I'm going to update the font in the test suite
             with MSFT's updated version, and I'll send you a link.
             What we need is another copy of the square glyph
             assigned to some CJK codepoint...
  <myles> ChrisL: https://trac.webkit.org/changeset/189890
  <fantasai> Probably "water"
  <myles> fantasai: sounds good
  <ChrisL> myles, very nice test font

[css-ui-4][user-select] value is used value?

  <astearns> https://github.com/w3c/csswg-drafts/issues/336
  Florian: This is about user-select. There is a bit of computation
           about computed value of user-select.
  Florian: There's a couple cases where you don't want to do
           inheritance- i.e. when your element is editable. You want
           contain there. The question raised was do we do the
           computation at used time or computed value time?
  Florian: I specced at computed because it wasn't layout, but I
           don't think anything else depends on it so moving to used
           would be fine. What do people want?
  astearns: So the question is if for this property we return the
            used value?
  Florian: Not if we should return. I've defined that auto computes
           to this in foo situation. The question is if we should
           say auto behaves as this or that so behaves at means done
           at used value time.
  astearns: Ah. Okay

  Florian: Personally I like computed value for theoretical
           completeness, but if used value is better for
           implementors I can switch. Is that what you guys want?
  astearns: Implementor opinion?
  astearns: koji said Blink prefers used.
  Florian: And I think Xidorn said Mozilla would agree.
  astearns: Given that you have 2 implementors preferring change and
            silence on the call, I say let's change.

  gregwhitworth: I think we'll sync up. It seems odd to me. I'll
                 check with our devs and see what we do and give
  Florian: I'd rather not resolve and wait on feedback then.
  gregwhitworth: Okay, sure.
  tantek: We can resolve with current info and if there's new info
          we reopen. And Florian you can delay making the edits. But
          we can get a resolution on the record.
  astearns: Yes. If we had no other person we're waiting on input.
            Since gregwhitworth is asking I'd rather wait on
            resolving until we have info. It's known unknown.
  tantek: I'd just prefer since we're so close to a resolution we
          resolve. This makes less friction in the likely case we're
  fantasai: We can resolve conditionally. There's a general caveat
            that new information makes us revisit, but this is a
            specific thing we're waiting for. The resolution should
            record we're waiting a week before it's considered final.
  astearns: I'm happy enough to wait. It'll be on the agenda next
            week and we'll do that after we get gregwhitworth

  gregwhitworth: And this is when you query the dom element with
                 user-select set you want to know if we're storing
                 at used or computed?
  Florian: The other difference is if we do it at used value it
           makes it impossible for other property's computed value
           to depend on this property's computed value. I don't
           think there's a probable use case, but I'm not sure.
  Florian: If there's implementor difficulties we can flip to used.

  Florian: For the resolution I'm okay to wait or resolve
  astearns: I'd prefer to wait.

[css-values] should allow <percentage> as a resolved type

  <astearns> https://github.com/w3c/csswg-drafts/issues/250
  fantasai: The issue is that there is in theory a possibility that
            a property could accept percentages and not compute to
            an equivalent thing and all percentages compute away.
            The edit is to allow percentages to resolve to
            themselves. I think it's straightforward, but it's a
            change to CR so I wanted to bring it to the group.
  <fantasai> https://github.com/w3c/csswg-drafts/commit/054f195a222718e182352a0ff1f87affaafb7114
  fantasai: Here's the commit.

  gregwhitworth: Seems reasonable to me. I haven't been here since
                 we've added a new length type, though. Do other
                 implementors have any worries?
  fantasai: It should have no effect on implementors until there's a
            value that only accepts percentages in which case it
            would allow calc in that context.
  astearns: Is there a particular case for percentages not resolving
            to anything else?
  fantasai: I don't think there's anything in mind, but they want to
            allow it. TabAtkins is arguing opacity should only have
            taken percentages so that could have been such a
  iank: This is for Houdini and the layout API where you want a
        percentage not something resolved against a length. If that
        adds more context.
  astearns: So you want to have the custom layout code be able to
            decide what a percentage means. Makes sense to me.

  astearns: Other opinions?
  astearns: Objections to the change?

  RESOLVED: Accept the changes in this commit:
            to allow percentages as a resolved type.

[css-color][css-tables] should 'opacity' be hoisted from the table
    box to its wrapper box

  <astearns> https://github.com/w3c/csswg-drafts/issues/324
  ChrisL: Is dbaron on?
  ChrisL: He's critical to this.
  astearns: I believe dbaron expressed regrets.
  <dbaron> oh, I guess I could join, actually
  fantasai: His opinion is in the issue.
  fantasai: If we all think he's right I don't think he'll object to
            us resolving on what he suggests.

  astearns: Does anyone have a yea/nay opinion on dbaron's weak
            preference for not hoisting?
  fantasai: I think opacity should be.
  <ChrisL> I agree opacity should be hoisted.
  fantasai: Opacity we're pretty sure. And in that vein you would
            say filters should have the same. I don't know if
            they're sensitive to coordinates. If filters are hoisted
            and therefore coordinates are effected then making
            masking hoisted would make sense so it uses the same
            coordinate as filters.
  <ChrisL> filters generally apply to the bounding box so yes the
           difference would be visible
  fantasai: Following that argument, which I'm not sure is accurate,
            then we should hoist them all.

  astearns: dbaron said he'd join.
  astearns: And my not hoisting comment as dbaron's preference was a
            mis-read. That was just to not hoisting masking.
  dbaron: That sounds like an accurate summary.

  astearns: Would it make sense to resolve on hoisting opacity and
            not decide on filters and masking because we're not sure
            if people want those things to be hoisted when
            coordinate changes could cause odd effects?
  dbaron: Seems reasonable to me.
  astearns: fantasai is that okay with you?
  fantasai: I don't mind for today. We need to decide eventually.

  ChrisL: Do we tests or check web compat. I'm not sure filters is
          used much on HTML tables. Are we worried about breaking
          existing or right thing to do?
  fantasai: Right thing to do. Seems unlikely there's a web compat

  <smfr> https://drafts.csswg.org/css-transforms/#grouping-property-values
  smfr: The transform spec has the grouping properties which is
        opacity and filters, but also others listed here ^
  smfr: We may want to consider if these hoist.
  fantasai: Makes sense. Probably all should.
  <ChrisL> sounds good to me
  <ChrisL> and I agree that all should, probably
  <fantasai> ChrisL, except overflow, which is defined already to
             apply to the table box
  <ChrisL> oh, good catch
  astearns: What if we resolve to hoist opacity today and put the
            rest on TPAC agenda? Drawing things may help.
  astearns: Does anyone object to hoist opacity from table box to
            its wrapper box?

  RESOLVED: hoist opacity from table box to its wrapper box

  astearns: I'll add the rest of the hoisting discussion to TPAC.

[css-tables] Calc for table layout

  <astearns> https://github.com/w3c/csswg-drafts/issues/94
  fantasai: Currently if there is a calc value in table and heights
            is a percentage the UA can treat it as auto. There was a
            comment about things being stupid obvious such as if
            calc contains only percentage or length then this isn't
            more complex, just do the adding. So those should not be
            treated as auto.
  fantasai: My opinion is the spec isn't wrong, the UA could do
            either. I'd defer it to level 4 V&U. For that I think
            it's reasonable to require calc only with length or only
            with percentage should be resolved.

  dbaron: Is this tables or table parts?
  fantasai: Table parts.

  dbaron: There's another option. If you have calc (length +
          percentage) you treat it as though you had a cell with a
          length and one with percentage which isn't quite the same.
          But there's also a question on - so maybe not great.

  fantasai: So I propose resolve that we're deferring to 4. Resolve
            in 4 that a calc with only percentage or only length is
            required to be resolved. And third we don't resolve on
            what to say about mixing the two yet.
  fantasai: We may decide on requirements later, but we're in early
            stages of level 4 so we don't need to lock down yet.
  astearns: Other opinions?
  Florian: For the first two parts it's reasonable. For the
           combination does anyone implement that?
  gregwhitworth: From my testing I couldn't find anyone that did
                 anything nice on percentage despite the one bug
                 fremy found on the thread.
  gregwhitworth: The one thing to echo is I don't want to discuss
                 anything, just document what exists in the world.
                 If that's level 4 that's okay.
  gregwhitworth: I'm not against talking about in the future, but I
                 don't think people use percentage now.
  Florian: The three parts are fine. I'm just thinking on the 3rd
           that the combination may be a must not support. But we
           can deal with that later.

  astearns: So, 3 parts. Objections to defer this to level 4 Values?
  fantasai: Level 3 of Values says when specified for width and
            height on tables.
  astearns: So objections to deferring the question to level 4 of
  gregwhitworth: I wasn't aware this lived in V& U as well.
  gregwhitworth: But since it's future it's okay. If we dig into
                 this and have width and height change the algorithm
                 we may want to bring it into Tables.
  astearns: Yeah. If there's a web compat issue it would be tables 3.
  gregwhitworth: Yeah. I'm not aware of one.

  RESOLVED: Defer this issue to V&U 4

  astearns: Objections to having a calc with only percentage or only
            length is required to be resolved in V&U 4?

  RESOLVED: A calc() with only percentage or only length is required
            to be resolved in V&U 4

  astearns: And since we're not saying anything on mixing I don't
            think we need a resolution.
  fantasai: I'd like another CR resolution for V&U 3 before these
            issues came up.
  fantasai: So I'd like another resolution.
  astearns: Objections to update to V&U 3 CR?
  <tantek> +1

  RESOLVED: Publish updated V&U 3 CR

[css-color] Unnecessary comma in color()

  <astearns> https://github.com/w3c/csswg-drafts/issues/266
  astearns: As far as I vaguely understand we have options. 1) just
            a space 2) a slash 3) alpha keyword
  astearns: Is that correct?
  <fantasai> https://github.com/w3c/csswg-drafts/issues/266#issuecomment-234131024
  fantasai: I think what we've got here is ^
  <fantasai> color( [ <colorspace>? [ <number>+ | <string> ] [ /
             <alpha> ]? ]# [ , <color> ]? )
  fantasai: That's the current proposal state.
  fantasai: The idea is you would separate by spaces, use commas for
            fallback colors. There's some back and forth on if the
            slash is needed or should be a keyword.
  fantasai: I'm inclined to the slash.
  fantasai: I think it helps readability, and keyword is too long
            for something so common.
  <tantek> some explicit syntax for separating opacity would likely
           reduce unintended (overtyped) opacity
  <tantek> slash seems ok to me
  ChrisL: I think the keyword is too verbose. I agree with fantasai.
  <tantek> having at least a slash also makes it easier to detect
           authoring errors at validation time

  gregwhitworth: I missed the original conversation. Why are we
                 moving away from commas?
  fantasai: We're trying to take CSS functional notations to be a
            named segment of CSS values. Using CSS values syntax
            means it's not necessarily positional and it allows
            reordering of names or dropping optional. There's a lot
            of advantage there over commas.
  fantasai: What we want to do is bring color more in line. So here
            we needed a fallback and it lets us use the comma
            without nesting parenthesis. It lets us make the color
            space optional.
  gregwhitworth: Sounds good
  <fantasai> https://wiki.csswg.org/ideas/functional-notation#general-principles

  ChrisL: It does in general. Does that mean parameters are
  fantasai: Depends on what we decide. If there's property values in
            general we don't allow reordering. So if you can't parse
            with reordering if it's not allowed. There are cases
            where something is required first. So in this case the
            name of the color profile.
  Florian: Don't know if you need that. There's no other ident in
           there. You have a color name, but that's a string.
  ChrisL: I don't see the benefit. I like it first and optional and
          if it's missing it's sRGB.
  Florian: I think the 3 colors should be in order. But name first
           or last I don't see a reason to prohibit

  <gregwhitworth> this would be valid then color(/.5)
  ChrisL: [reads gregwhitworth ]
  <fantasai> gregwhitworth, the color is required currently. We
             could in theory make it optional so that would be
  dbaron: The argument for first is it says what the rest means. It
          helps readability.
  astearns: Main benefit is the color space is optional. There's
            other syntaxes where rearranging is useful, but I'm not
            sure this is one.
  Florian: The other benefit is that we'd need to nest and that's
  <ChrisL> so I like using commas for fallback and avoiding nesting
  BradK: I think avoiding nesting is important. That's where the
         keyword came about is if the color mod could be a keyword.
         I'm fine with a slash, I think it works better.
  astearns: I have a slight preference for the keyword because it's
            easier for me to remember that alpha needs an alpha
  fantasai: You'd be using colors so often you'd hate typing it.
  astearns: I don't do colors often so I bow to others
  <ChrisL> yeah I would hate typing "alpha" all the time
  <leaverou> me too
  BradK: rgba is so common forcing people to write opacity is too
  <gregwhitworth> I agree in full notation, this is very legible
                  color(AdobeRGB 255 255 255 /.75, #fff);
  <ChrisL> also can we stop using 0 to 255 numbers in examples? It
           is 0.0 to 1.0
  <ChrisL> because we will also support 10bit and 12bit per
           component, especially for wide gamut spaces

  gregwhitworth: When I see the / I think division
  gregwhitworth: If you read the second part, I would think it's
                 division. If you have rgba you would have it
                 automatically. You wouldn't think it's rgb divided
                 by something.
  <leaverou> gregwhitworth: that ship has sailed, we use / as a
             separator in a bunch of places
  astearns: I agree with leaverou. We have it as a separator
            elsewhere. So if it's not a bare space a / is the thing
            to use.
  Florian: And since this isn't 3 parameter, it's an arbitrary
           number of colors, visually you'd have no clue with a
           space. I think we need a separator. And if we have one it
           should be /
  myles: You need the content to make meaning out of the other
         numbers, so it doesn't seem bad on the last.
  Florian: But if you have a 7 color profile seeing if it's 7 or 8
           isn't easy.
  <ChrisL> florian, exactly
  <BradK>  1color( [[ <colorspace>? [ <number>+ | <string> ] [ /
          <alpha> ]? | <hex> ]# )

  fantasai: And you could want to change the alpha without changing
            or understanding all the others. You just know you want
            that color at 50% opacity and you can tell if there's an
            argument there already or if you should add one.
  <Florian> +1 to fantasai
  <dauwhe> +1 to fantasai
  Florian: There's two ways to make it special, put the / or require
  fantasai: I prefer the / because I think we should allow color
            arguments to be percentage at some point in the future.
            We'd be blocked from making that change.
  Florian: Okay.
  fantasai: Also, opacity in the rest of CSS allow numbers, so we
            with a slash we can be consistent and allow them here

  astearns: I'm hearing consensus on using the /. I propose we add
            the / to the syntax and develop some examples on various
            color profiles we're expecting to handle and get it out
            to authors and they can let us know if they like it.
  <tantek> +1
  <fantasai> color( [[ <colorspace>? [ <number>+ | <string> ] [ /
             <alpha> ]? | <hex> ]# )
  <ChrisL> wait, what is that hex thing? and where is the fallback?
  <fantasai> (ignore that)
  fantasai: Several resolutions here. We can take this ^ syntax from
  Florian: Where is the hex?
  BradK: I put that. the earlier said color as a fallback, but hex
         is an odd one out.
  Florian: For a fallback I think the most useful is to allow
           anything other than the color notation. If we just allow
           a color in general it means people can comma separate the
  fantasai: It would allow variables.
  fantasai: Otherwise I'd say don't allow. It's better to use the
            notation with a keyword or hex, but if we want variables
            in fallback I don't see why not so it should take any
            color value.
  Florian: It's not harmful and a bit useful.

  ChrisL: fantasai can you write it out correctly?
  <fantasai> color( [ <colorspace>? [ <number>+ | <string> ] [ /
             <alpha> ]? ]# [ , <color> ]? )
  fantasai: This one?
  <fantasai> https://github.com/w3c/csswg-drafts/issues/266#issuecomment-234131024
  BradK: And a note in the spec with what you just said to
         discourage embedding.
  astearns: I like that.

  ChrisL: Can I put color space after the comma?
  Florian: You can put any kind of color. hsl, blue whatever.

  astearns: So we are resolving on the last color syntax in IRC:
            color( [ <colorspace>? [ <number>+ | <string> ] [ /
            <alpha> ]? ]# [ , <color> ]? )
  <ChrisL> +1
  <ChrisL> yes
  astearns: Objections:
  Florian: Like it.
  <tantek> +1
  fantasai: Me too.

  BradK: Are we also resolving that colorspace can take a keyword?
         Any of them. RGB, sRGB.
  astearns: Let's resolve first on the syntax.
  <ChrisL> huh?

  RESOLVED: Use this color syntax: color( [ <colorspace>? [
            <number>+ | <string> ] [ / <alpha> ]? ]# [ , <color> ]? )

  astearns: So BradK asked what does colorspace mean in that syntax
  ChrisL: So hsl and those are in sRGB color space. If we want to
          add all previous syntaxes I can see the reason. It's not
          really a colorspace, but okay.
  BradK: So colorspace or color defining keyword.
  <astearns> <colorthingy> : <colorspace> | <other>
  ChrisL: It means we can't remove something like hsl from sRGB but
          I think it's fine.
  fantasai: You can, but a different keyword.
  Florian: If you write 'AdobeRGB hsl' that means different than hsl.
  ChrisL: It makes it complicated.
  Florian: I'm just saying we're not stuck.
  ChrisL: Okay. I can write this up.

  Florian: Only thing I'm not sure is to allow rgb.
  Florian: It should be srgb or omitted.
  BradK: You'd allow lab and the others?
  ChrisL: Yeah. We're not removing the short functions, though.
  BradK: I'm ambivalent.
  fantasai: We should keep short.
  <tantek> I think we should keep short.
  astearns: And it's because web compat, right?
  BradK: For the ones that exist.
  <tantek> keep existing short functions for webcompat, and
           author-friendliness, more readable style sheets etc.
  ChrisL: Also because it's more convenient. If you want lab being
          able to say it and the numbers is convenient. People like
          hsl and 3 numbers.
  BradK: I wouldn't object.

  leaverou: Are we backporting / into other color functions?
  fantasai: We could.
  fantasai: It would be a variation with no commas and a / for alpha.
  <tantek> agreed about backporting "/" to short functions too
  Florian: Might be a good idea. We would try and do rgb with rgba
           and we're not sure we can, but the space and / would be

  BradK: Do the new functions allow commas?
  Florian: I would not allow.
  BradK: Keep as legacy?
  ChrisL: The new ones are doing it as fantasai described.

  astearns: Sounds like ChrisL will explore drafting things other
            than colorspaces in the colorspace part of the syntax.
  astearns: Do we need to decide on backporting the / or see it
  fantasai: I think we have consensus

  astearns: I agree. Is anyone worried about backporting / to the
            short functions?
  <Florian> rgb( [<r>, <g>, <b>] | [ <r> <g> <b> [ / <alpha> ]? )
  <ChrisL> yes
  fantasai: What Florian typed is right
  <tantek> backporting "/" to short functions is a nice to have (I
           am for it), but not going to object to not
  Florian: That's better than allowing the r, b, g, alpha in rgb
  astearns: Objections to backporting / to the short functions like:
            rgb( [<r>, <g>, <b>] | [ <r> <g> <b> [ / <alpha> ]
  <tantek> same for rgba? or?

  RESOLVED: Backport slash to the short functions like: rgb( [<r>,
            <g>, <b>] | [ <r> <g> <b> [ / <alpha> ]

  <ChrisL> rgba deprecated?
  Florian: I suggest we don't go to the ones with an a. Or does rgba
           work without the a?
  astearns: I would assume rgba you could omit the commas and add
            the slash.
  Florian: Do we depreciate rgbs?
  BradK: rgb and rgba become the same.
  Florian: I don't think rgb can take comma separated without web
           compat issues.
  astearns: It's the non-comma version that they share.

  astearns: We're at the top of the hour. The details of backporting
            will need discussion, but we've resolved to do it.
Received on Thursday, 28 July 2016 01:14:28 UTC

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