W3C home > Mailing lists > Public > www-style@w3.org > June 2014

[CSSWG] Minutes Telecon 2014-06-25

From: Dael Jackson <daelcss@gmail.com>
Date: Thu, 26 Jun 2014 11:24:04 -0400
Message-ID: <CADhPm3sW+ZCBT5iwnrGcm4_OHfO1x_uUWht=2ObDmbKUCKNfzQ@mail.gmail.com>
To: www-style@w3.org
Charter Update

  - plh reported that the charter process is going well and nearing

Upcoming F2F location

  - As at least one group member has already made reservations for
      Sophia/Antipolis, the current focus is to try and have the
      meeting there.
  - plh will investigate if the W3C is prepared to host.

CSS Masking to CR

  - RESOLVED: CSS Masking to CR

Explaining <br>

  - The performance implications of creating a special case of
      display-box: content or creating a whole new display value
      were compared.
    - Some members thinking that the special case would potentially
         create negative performance implications.
    - Others felt that the new display value would create
         unnecessary complexity.
  - Ultimately it was decided that there still wasn't a good
      solution to this problem and it was put back on the shelf
      until someone comes up with a better solution.

Flexbox percentage heights in column direction

  - The basic issues of this problem were hashed out and clarified.
  - Discussion will now move back to the mailing list to try and
      find a solution.

background-blend on the root element

  - RESOLVED: Solve as Rik requests in

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

  Glenn Adams
  Tab Atkins
  David Baron
  Rik Cabanier
  Tantek Çelik
  Dave Cramer
  Bruno de Oliveira Abinader (IRC Only)
  Elika Etemad
  Simon Fraser
  Koji Ishii
  Dael Jackson
  Brian Kardell
  Philippe Le Hégaret
  Chris Lilley
  Peter Linss
  Edward O'Connor
  Matt Rakow
  Dirk Schulze
  Simon Sapin
  Alan Stearns
  Greg Whitworth
  Steve Zilles

  Bert Bos
  Sylvain Galineau
  Daniel Glazman
  Simon Pieters
  Lea Verou

Charter Update

  plinss: Let's get started
  plinss: Anything to add?
  plh: I can do a charter update
  plinss: Okay.
  plh: I've got all the necessary stuff. I expect the charter to go
       to the CRs and approved no later than Friday. We're all good
       on that front.
  plinss: Cool. It will be nice to be under a charter again.

Upcoming F2F location

  plinss: TabAtkins was looking in Zurich?
  TabAtkins: I'm in a restaurant. Can you hear me?
  TabAtkins: I've not yet done so. Sorry.
  plinss: What's an ETA?
  TabAtkins: Next week if we don't decide to go somewhere else prior.

  SteveZ: I assumed that we were set for Sophia/Antipolis so I have
          reservations for those dates and would object to changing.
  plinss: Is that a non-refundable situation?
  SteveZ: It is.
  plinss: Any other input, or should we commit to Sophia/Antipolis?
  TabAtkins: I have no problem with that.

  plh: I don't know if we have approval to host in Antipolis. Is W3C
       hosting there?
  SteveZ: That was the proposal.
  plh: I won't object, but I want people to realize we're not doing
       it in Zurich. I hope ChrisL and/or bert made sure we have the
  plinss: ChrisL or bert are you there? [silence] Doesn't look like
          it. We need to do research.

  action plh to ping bert or ChrisL about budgeting for the Sept F2F
  <trackbot> Created ACTION-633 - Ping bert or ChrisL about
             budgeting for the sept f2f [on Philippe Le Hégaret -
             due 2014-07-02].

  plh: FYI for those on the call the next extensible web is in
       Berlin on Sept 11.
  plinss: There's something else in Berlin too.
  plh: On the 12th there's a CSS conference and on the 13th there's
       another conference.

  SteveZ: If you fly on Luftansa you can get to Berlin easily from
  plh: Yes.

  <dbaron> As I said before, I and other Mozilla folks probably
           won't be able to make the week of Sept 8-12
  <dbaron> Although I still don't know for sure.

  <SimonSapin> (plh, was the September extensible web summit
               announced yet? I only find stuff about the one last
  <plh> Simon, not yet, it will be announced before the end of the
        week. I'm working with Dan on this.
  <SimonSapin> thanks plh

CSS Masking to CR
  <krit> http://www.w3.org/TR/css-masking-1/
  <krit> http://dev.w3.org/fxtf/css-masking-1/issues-lc-2014.html

  krit: The LC period is over. I got a lot of positive feedback.

  krit: I got one piece of feedback with one issue so there's a typo
        with border-box initial value. I changed it to auto.
  krit: Other than that there were no change requests, so I'd like
        to go to CR.

  plinss: Any objections?
  TabAtkins: No
  fantasai: I didn't review, but I can't object because of that.

  RESOLVED: CSS Masking to CR

  plinss: How are the test suites? I see 53.
  krit: It's particular to SVG, but I'll upload from webkit. For the
        new parts we need more tests for coverage since they're not
        in browsers yet.
  plinss: You'll prepare the draft and ping ChrisL or bert?
  krit: Yes.

Explaining <br>

  plinss: TabAtkins?
  TabAtkins: At the last F2F we discussed defining the style of <br>
             using display-box: content and other properties.
  TabAtkins: Since then in the whatwg bug dbaron objected due to
             performance implications.
  TabAtkins: That's fine, but I want to define it in some way. One
             way would be to create a new display value for new

  TabAtkins: Does dbaron think the performance concern is large
             enough to pursue a new method?
  dbaron: I don't know off the top of my head. Maybe we can special
          case the one thing.
  dbaron: If something is display-box: content and has this thing
          inside we don't take the normal code path, but do this
          other thing.
  TabAtkins: I would prefer not odd special cases if possible.
  <ChrisL> I would prefer not having had a br element, but there we
  dbaron: Special is in code.
  TabAtkins: If our recommended style for it requires weird special
             cases, we should address it more directly.

  fantasai: I don't agree. I think if we have a special code path
            that constructs a frame with equivalent behavior, but if
            other properties are different you use the normal code
            path, that's fine.
  fantasai: As long as to the author it behaves in a consistent way
            that's good. If we create a display value for new lines
            that's harder to understand for the author.
  fantasai: In addition you have various code paths you have to
            write in the engine.
  fantasai: If we're doing this for performance improvements,
            creating a whole new feature seems like overkill and
            extra work for testing and implementation and especially
            for authors.
  fantasai: I think it's fine.
  fantasai: We do something weird and special because this is
            common, else wise we do the normal path.
  <ChrisL> agree with fantasai. This is a legacy special case that
           we can't get rid of

  TabAtkins: While I would agree in the past, as I have more
             implementor experience, I think having these special
             paths slows things down.
  fantasai: You'd need one anyway for a new method.
  <SteveZ> Is the issue one of code path complexity and therefore
  TabAtkins: But specifically if you have this style as this way do
             something magic, that's different, from having a
             special display value.
  TabAtkins: Having the special case path where "if something has
             this part treat it different" ends up being annoying
             for the code and slows everything down. Removing these
             helps performance. I'd prefer if we do a weird special
             thing, I'd rather it being it's own case.
  TabAtkins: I don't like where if you make a small change it goes
             to hell because there's a specific optimized path.
  <tantek> yes that ^^^
  <tantek> very bad for web authors
  <gregwhitworth> Agreed
  <ChrisL> /* Don't change this code, it will <br> */
  TabAtkins: What we're asking is, if you do this in this particular
             way it's fast, but else wise it goes slow.

  <SteveZ> How much slower will this BR form be?
  fantasai: How many people will style <br>?
  fantasai: I don't think it is worth a new feature that we have to
            work on and create a generic implementation.
  tantek: Lots of style sheets do style with universal selector. I
          think there's lots of cases out there and we don't know it.
  dbaron: I think that authors not changing it much is an argument
          for not worrying about <br>.
  TabAtkins: You mean we should make <br> special magic?
  dbaron: Yes.
  TabAtkins: I don't like it, but I like it better than a weird
             special case.
  plinss: Sounds like it's a special case one way or the other.

  fantasai: Maybe your implementation doesn't need that optimization.
  TabAtkins: We almost certainly do. If it's a problem for Mozilla,
             it's likely a problem for us.
  dbaron: I don't know it is, but I suspect it will be slower.
  TabAtkins: That's our expectation for display-box. It'll be useful
             but slower.

  plinss: Sounds like this goes back on the shelf?

  rossen: If we were to implement with display-content it would have
          performance implications. For us now <br> is line-layout
          without more drama. Anything more will add something to
          performance time.
  fantasai: Would it be possible to define <br> as rendered
            equivalent to this CSS rule, except impl are allowed to
            make it non-override-able.
  fantasai: Then browsers can keep their current implementations,
            but at least the rendering is defined.
  rossen: I think people mentioned that they do style <br> a bit and
          I've seen evidence of it.
  rossen: We'd take a compat hit with breaking <br> styling and I'm
          not a fan of that.
  rossen: If we end up breaking the content it'll likely be old
          legacy content and not likely to change. I'm not sure
          that's an odd trade-off.

  plinss: My concern is if we explicitly define it, it makes it
          harder to come up with a better approach later.
  TabAtkins: Another problem is that we're assuming we won't have
             anything in the future that would over-ride that style.
             I don't think it's a stable solution overall.

  plinss: I think we need to let this percolate until we come up
          with something better.
  * tantek agrees with plinss
  fantasai: I thought the conclusion was we can't come up with
            something better because it involves making this a style-
            able box.
  plinss: I'm saying one day someone might come up with another
          solution. I'm not willing to declare it forever unsolvable.
  <tantek> yes that ^^^

Flexbox percentage heights in column direction

  TabAtkins: There is some disagreement between browsers about when
             a length is definite or indefinite when it's the size
             of a flex-item.
  TabAtkins: Chrome says indefinite unless there's a defined
  TabAtkins: Other browsers have different rules that I haven't been
             able to intuit. I'm not sure when they decide they're
             definite for purposes of inheriting to their children.
  TabAtkins: The things we defined as definite would say that things
             are definite when they have a defined flex-basis, but
             I'm not sure.
  fantasai: Even with a definite flex-basis, they're flexible so
            should we be defining?
  TabAtkins: With a definite flex-basis and they're flexible, it's
             at least theoretically okay to resolve percentages.
             Firefox does. Chrome calls it indefinite.

  rossen: Question, what is the test case? You have a flex box with
          column direction and a flex item that's auto-size and an
          item inside that is percent height?
  TabAtkins: There's variations. The flex item is always flexible
             but the basis is auto, percentage or fixed size. The
             three implementations are different on every one of
             those cases.
  TabAtkins: I don't know the correct answer.
  TabAtkins: The postings from gregwhitworth aren't loading for me.
             I'm having trouble giving a sensible answer.

  fantasai: If you resolve percentage against any of these things,
            you'd resolve against a hypothetical size that may or
            may not be the size of the flex item?
  TabAtkins: Why?
  fantasai: It's flexible.
  TabAtkins: When child percentage is resolved against a flex item,
             it's after flex sizing.
  rossen: That's our code.
  TabAtkins: You run flex, lay out children, resolve percentage.
  rossen: I think we do the same for grid.
  rossen: This is the same argument that was being made where with
          components it is nice to resolve at the top and let grid
          take care of the inner layers and outer shape.
  rossen: I think we resolved on this issue back in Lyon TPAC.
  rossen: We discussed allowing percentages inside auto-size.
  TabAtkins: You're thinking of the cross dimension where what we
             have is a solution that right most of the time and that
             solutions is in the spec already. This is the main

  dbaron: For what it's worth dholbert prefers the Firefox/IE
          behavior where we treat it as definite if it's definite at
          the time that matters.
  TabAtkins: I don't know if that applies to flex items with a auto
             base size.
  TabAtkins: That should be fine for the other cases when you have a
             length, flex, and then lay out your children. In auto
             you count your children and then lay out and I'm not
             sure if that's definite.

  rossen: Did we resolve that flex-basis is a use time value and
          defined as used not computed?
  rossen: I think about a month ago we decided that flex-basis was a
          use value, not computed. It assumes that all the flex
          items are already measured to their flexibility and then
          we have a use size we can resolve percentage against.
  TabAtkins: Hmm.
  TabAtkins: You may be right on that.
  TabAtkins: Okay. I need to go and research that.

  TabAtkins: I've been avoiding the thread, but I think I need to
             load flex into my brain.
  TabAtkins: Now that I have a grasp on the discussion, let's go
             back to the thread and sort out how our previous
             resolutions deal with this. I think I can be convinced
             Chrome is a bug with some or all of these cases.
  rossen: I'm fine with that.
  TabAtkins: Cool.
  <fantasai> Tab, I don't think used vs. computed value of flex-
             basis is a relevant thing here.

background-blend on the root element

  <TabAtkins> http://lists.w3.org/Archives/Public/www-style/2014Jun/0280.html

  TabAtkins: Is cabanier around?
  cabanier: Yes, sorry. I was on mute.
  cabanier: So it looks like there was feedback from Alan this
            morning. I'm not sure what's supposed to be happening,
            there's different Firefox and WebKit behavior.
  cabanier: Firefox pulls up the background layer and draws. Webkit
            draws an external layer in white.
  cabanier: Now that we expect these layers to be in order, it's
            different. It's possible for others to work around it,
            but it's a bit weird.
  TabAtkins: I completely agree with your question on the thread. We
             should say the root element blends and then transposes.
             It's odd that the final background is white and that's
             an odd detail we shouldn't expose
  dbaron: I don't think the final is white in iframes, in some cases.
  cabanier: It seems it's only the root elements. There's something
            going on.
  TabAtkins: It may be an implementation bug.

  cabanier: Firefox sometimes draws differently. That's a bug.
            Should it be fixed in blending or color?
  cabanier: We need to define that the root element is different.
  krit: Does it apply to SVG as well?
  cabanier: I think it would apply there, I haven't tried it because
            there isn't blending in SVG.
  TabAtkins: If you're doing background blending in SVG you wouldn't
             use white, you'd do transparent.
  TabAtkins: Likely we want to do it in colors so that if we want
             anything that goes and uses root it blends against the
             transparent and untouchable background.
  TabAtkins: The backdrop color is untouchable and you can't do
             anything with it except map your page.
  cabanier: I think that's the behavior most would expect.
  plinss: I think that's correct. I don't want to bake an opaque
          background into the platform.

  plinss: So are we ready to resolve?
  cabanier: That CSS Colors needs to define this?
  TabAtkins: That whatever browsers do for the backdrop, the page
             mattes against that.
  TabAtkins: I'll wordsmith it.

  RESOLVED: Solve as Rik requests in

  plinss: I think that's it. We had Animations issues from Sylvain,
          but he sent his regrets.

  plinss: Anything else?
  plinss: Talk to everyone next week.
Received on Thursday, 26 June 2014 15:24:31 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:14:41 UTC