W3C home > Mailing lists > Public > www-style@w3.org > April 2015

[CSSWG] Minutes Telecon 2015-04-01

From: Dael Jackson <daelcss@gmail.com>
Date: Thu, 9 Apr 2015 06:37:01 -0400
Message-ID: <CADhPm3sjxDNsDQs3q2y+gda4HpmXfDAKyWarHt3678JkDnsHow@mail.gmail.com>
To: www-style@w3.org

  - The WG will request to meet on Monday and Tuesday during TPAC

Box Sizing

  - RESOLVED: New WD of CSS 3 UI, accepting changes to box-sizing
  - RESOLVED: Then publish another WD

Motion Path

  - RESOLVED: Motion Path FPWD granted

WebVTT feedback

  - RESOLVED: Accept feedback coming from mailing-list as WG review

Media Queries

  - A decision on the text change will wait another week for
      Microsoft to continue reviewing.

Cursor Image Formats

  - Discussion will also wait until next week to give Microsoft
      another week to review.


  - RESOLVED: Add the ::marker { font-variant: tabular-nums; } rule
              to the default stylesheet

Intrinsic Sizes and Multicolumn Elements

  - Discussion will continue on the mailing list and wait until next
      week when someone from Chrome is on the telecon.

Baselines of Inline Blocks

  - RESOLVED: Accept Myles' proposal to make baseline of overflow
              non-visible inline blocks the higher of the actual
              baseline (at initial scroll position) and the margin-
              box bottom. Separately investigate whether to switch
              from margin-box bottom to padding-box bottom for
              sanity. (requries web-compat check)

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

  David Baron
  Sanja Bonic
  Bert Bos
  Tantek Çelik
  Dave Cramer
  Elika Etemad
  Daniel Glazman
  Brad Kemper
  Peter Linss
  Myles Maxfield
  Simon Pieters
  Florian Rivoal
  Simon Sapin
  Alan Stearns
  Greg Whitworth

  Rossen Atanassov
  Tab Atkins
  Adenilson Cavalcanti
  Simon Fraser
  Dael Jackson
  Michael Miller
  Edward O'Connor
  Mike Sherov
  Shane Stephens
  Steve Zilles

  Scribe: glazou


  plinss: First topic, TPAC? pick dates.
  plinss: Is the first part of week ok?
  <dauwhe> Monday-Tuesday is good
  tantek: I’ll be chairing a WG myself and will try to avoid overlap
  <Bert> (I'll be there the whole week anyway, so no pref.)
  glazou: Let’s stick to Monday-Wednesday.
  Florian: Agreed.

  tantek: Should we do Sunday too?
  plinss: Not for now.
  plinss: We’ll see.
  plinss: Doing Sunday involves W3C planning and spaces.

Box Sizing

  plinss: next topic, box sizing
  <glazou> https://lists.w3.org/Archives/Public/www-style/2015Feb/0445.html
  <tantek> latest message on:
  florian: There's no feedback.
  tantek: There is a thread with fantasai and TabAtkins.
  Florian: Right, but nothing else.
  tantek: I would like to move forward with this ASAP
  tantek: There's still some issues where you agree with TabAtkins
  Florian: Also a couple wording points I agree with fantasai.

  Florian: There's one difference between browsers I did not see
           when I spec’d that.
  tantek: The IE difference?
  Florian: Yes.
  Florian: IE returns the content width while others return the
  Florian: I think I agree with not-IE here.
  gregwhitworth: We just got some edits on that this week.
  Florian: OK, I will update the text then.
  <tantek> this example:
  <tantek> <div id="d" style="box-sizing:border-box;
           position:absolute; padding: 10px;"></div>
  <tantek> <script>console.log(getComputedStyle(document.
  <tantek> Firefox/Chrome/Safari/Presto --> 20px
  <tantek> IE --> 0px
  <gregwhitworth> yeah, we don't want that since custom layouts will
                  need interop

  Florian: My prose is probably correct although not elegant.
  tantek: I can help with that.
  Florian: 2.1 is ambiguous here.
  Florian: fantasai suggested dealing with input and output.
  Florian: Please help if you can.
  tantek: OK.
  * fantasai would also like to review the new wording
  * fantasai really doesn't want to monkey-patch 2.1
  * fantasai is pretty sure that'll create bugs in all of our specs

  Florian: I need reviews from implementors.
  tantek: We already gave 3 weeks.
  tantek: We heard from tab and fantasai.
  tantek: There's nothing from others, including Microsoft, excluded
          what gregwhitworth just said.
  tantek: gregwhitworth, did you review the rest of proposed text?
  gregwhitworth: Unfortunately, no.
  Florian: My proposal was posted end of February, ahem.
  tantek: I’d like to suggest you go ahead, make the changes,
  tantek: make the change explicit in the text,
  tantek: and ship.
  Florian: fantasai mentions not being happy about monkey-patching
  tantek: Unfortunately, we take the least worst approach at this
  * fantasai thinks you should check in the changes, and we can
             clean it up afterward
  * fantasai thinks we need to clean it up, but we should start from
             something more solid than ML discussions.
  tantek: fantasai just said she's OK with moving fwd the proposal
  Florian: Let’s do it, then.
  tantek: Sounds like a plan.

  Bert: what exactly needs to change in 2.1?
  Florian: The sizing section in 2.1 refers ambiguously to the value
           of the width property and the width of the content box
           because it was the same thing in 2.1.
  Florian: So it's not clear how 2.1 works.
  Florian: I made a clarification about that.
  Bert: Yeah, ok, thanks.
  Bert: Makes sense.
  Florian: Same thing for height and min-/max- properties

  tantek: Agreed that if can errata 2.1…
  tantek: but probably it's better to get a wider review in CSS 3 UI.
  tantek: I'm taking a wild guess TabAtkins would be ok with that.
  tantek: Any other objections?
  Florian: No objection obviously but I got rare feedback so does it
           mean nobody reviewed it?

  plinss: Wait.
  plinss: Update and ask for WD?
  plinss: I'm hearing no objection.
  <fantasai> +1
  tantek: Publish early, publish often.
  plinss: Objections?

  RESOLVED: New WD of CSS 3 UI, accepting changes to box-sizing
  RESOLVED: Then publish another WD

  tantek: the new publishing system was still crashing so we still
          use the older one.
  <tantek> Bert, http://dev.w3.org/csswg/css-ui-3/ is good to go for
           WD publication now.

Motion Path

  glazou: shane sent regrets
  <astearns> +1 to fpwd
  plinss: Any objections to FPWD?

  RESOLVED: Motion Path FPWD granted

WebVTT feedback

  <glazou> https://lists.w3.org/Archives/Member/w3c-css-wg/2015JanMar/0239.html
  plinss: Anyone have feedback?
  astearns: We need to collect what’s in the list and send it ASAP.
  plinss: That's fine by me.
  plinss: Anyone needing more time?
  Bert: Can you do it?

  RESOLVED: Accept feedback coming from mailing-list as WG review

  ACTION Bert to collect and send WebVTT feedback
  <trackbot> Created ACTION-677

Media Queries

  Florian: This is follow up of the should/must discussion.
  Florian: Microsoft, we were waiting for you.
  gregwhitworth: We have initial worries about pointer events and we
could not review.
  Florian: We can definitely improve the prose there.
  gregwhitworth: I don’t have a strong knowledge of that.
  Florian: With the statement I’m willing to work on your pointers
concern, we should be ok with the general feeling.
  plinss: Are you okay with that, gregwhitworth, or do you need another week?
  gregwhitworth: I’d prefer having time to get internal review but I
don’t disagree necessarily with you Florian but...
  plinss: OK let’s give them another week.
  DEFERRED to next week: MQ4

Cursor Image Formats

  Florian: We were waiting for 2 different answers from Microsoft.
  Florian: Are you OK with mandating image types, PNG and SVG, must
           be supported and everything supported as an image must
           also be as a cursor?
  plinss: Rossen sent regrets and mentioned discussions and asked
          for another week.
  gregwhitworth: I got in touch with the standards people,
  gregwhitworth: the ball is rolling now.
  gregwhitworth: I asked yesterday and they said stuff is in MSDN
                 and they’re investigating legal issues.
  gregwhitworth: Rossen was investigating technical issues and he
                 found nothing at this point.
  tantek: That’s good.
  tantek: One concrete proposal request: would it be possible to
          contribute the cursor formats as a member contribution?
  gregwhitworth: well ok
  tantek: Microsoft has done it before.
  <Florian> +1 to what Tantek said.
  glazou: I said it too in www-style.
  gregwhitworth: I will send the suggestion.
  gregwhitworth: Let’s put that on agenda every week
  all: :-)
  tantek: count on us :-)


  fantasai: xidorn’s message is about font variants.
  fantasai: We want to add that as a requirement on UAs.
  <fantasai> ::marker { font-variant: tabular-nums; }
  fantasai: Add it to default stylesheet for better results.
  Florian: OK
  Bert: You can still override it?
  fantasai: Yes.
  Bert: OK fine.

  RESOLVED: add the ::marker rule above to the default stylesheet

Intrinsic Sizes and Multicolumn Elements

  <fantasai> https://lists.w3.org/Archives/Public/www-style/2015Mar/0333.html
  fantasai: Rossen reported an error in one of the bullets.

  Scribe: sanja

  fantasai: So basically we're looking at the intrinsic sizes of
            multicolumn element.
  fantasai: column-count, column-width, try to set as many columns
            as you can, it will try to give you ... (talking about
            cases) ... column-width, specify height on the element,
            the columns will fill down and it will overflow on the
            next side.
  fantasai: ...so the minimum is the number of columns multiplied by
            the minimum or maximum size of the content.
  fantasai: Take the min content but max out at the width of the

  Scribe: fantasai

  fantasai: col-width + col-count case
  <dbaron> I strongly disagree with the height case.
  fantasai: The last case is controversial.
  fantasai: Don't think we can get resolution on it.
  <dbaron> It would take me half an hour to load this stuff into my
           head again; I don't know if this is the same as what the
           proposal was the last time fantasai and I discussed it.
  florian: I think Morten's position is probably right, since he's
           usually right.
  <Florian> (in general, and specifically about multicol)
  fantasai: He didn't have anything much to say except for the last
  fantasai: I would like to get a resolution on the first three. I'm
            happy to discuss on ML, but would like to know whose
            reviews to wait for.
  <zcorpan> i can ask morten for opinions about those
  <astearns> agree with getting Morten's opinion
  plinss: Anyone?

  Bert: I'm not sure I understand anything, but I suspect height
        shouldn't have an influence here.
  fantasai: The last case is what happens if you have col-width +
  fantasai: Some implementors use intrinsic size as col-width
  fantasai: resulting one column
  fantasai: for the width of the multicol element.
  fantasai: When you fill it with the content
  fantasai: more columns are generated
  fantasai: and the content overflows to the side.
  fantasai: The goal of the proposal was to have the intrinsic width
            be large enough to fit all of the content
  fantasai: because that's what an intrinsic width usually does,
            that is its goal.
  fantasai: The problem with this is it requires layout.
  fantasai: Except for multicol and orthogonal flows, we don't
            require layout for finding intrinsic inline-size
  fantasai: that would avoid overflow.
  fantasai: So layout engines are unhappy that they would have to do
  Bert: Don't think I can have an opinion in 5 minutes.
  Bert: But looks pretty straightforward.

  plinss: Maybe get a resolution on first 3?
  fantasai: Chrome is the only one that would need to change, since
            IE and Firefox agree on those.
  plinss: No one from Chrome is on the call, come back next week.
  [discussion of what to discuss]

  <glazou> next topic, selectors 4
  dbaron: That needs TabAtkins.
  <dbaron> (if it needs teleconference time at all)

Baselines of Inline Blocks

  <glazou> next topic, Baselines of inline blocks
  <fantasai> Myles, from Apple
  <Florian> welcome
  <dauwhe> hello!
  <tantek> Welcome Myles!

  myles: The proposal is regarding inline block elements.
  myles: Spec says if you have overflow: hidden;, you use the bottom
         of the block.
  myles: Would prefer the baseline of the last line or bottom of
         block, whichever is higher.
  myles: If you have without overflow: hidden, then use baseline of
  myles: If you add overflow: hidden, the baseline jumps up.
  myles: Putting overflow: hidden shouldn't cause it to jump around
         like this
  myles: So would like to change baseline of the inline-block to be
         whichever is higher, last baseline or bottom of block.

  <astearns> I like this change. fewer surprises.
  <dbaron> I'm fine with this change as long as it's based on the
           initial scroll position, and that overflow
           auto/hidden/scroll are consistent.
  Florian: I'm fine with the proposal, but is it Web-compatible?
  myles: Currently all browsers except WebKit implement the spec.
  myles: WebKit has shipped this behavior for many releases?
  dbaron: I'm fine with this. We get bugs about this at a decent
          frequency, so I think the current behavior does bug people.
  dbaron: I'm fine as long as we define it as initial scroll
  dbaron: And also if all of overflow: hidden / scroll are affected.
  <tantek> sounds like an improvement to me too. assuming web-compat.
  * fantasai agrees

  fantasai: By "bottom of box" do you mean the content-box,
            border-box, padding-box, margin-box?
  Florian: The content-box?
  fantasai: The scrollable area is the padding-box
  myles: The spec right now says bottom margin edge
  myles: That part I'm not proposing changing.
  fantasai: That's kind of weird then, because you might have a
            baseline that you can't see that it's aligning to.
  dbaron: I think the margin edge is used to make it behave like a
          replaced element, since those baseline-align to their
          bottom margin edge as well.
  myles: Boris and TabAtkins have said this is a reasonable thing to

  Florian: Since aligning to baseline, maybe should be based on
           whether baseline is visible.
  fantasai: Wouldn't that cause a jump? If I increase the font size
            by 3px and [...]
  Florian: No, I meant take higher of baseline or padding-box.
  fantasai: Okay. I think that definitely makes more sense, if the
            idea is to align to the content.
  fantasai: We should take Myles's proposal, and then maybe try to
            change margin-box to padding-box later depending on Web
  plinss: Do we have a resolution?

  RESOLVED: Accept Myles' proposal to make baseline of overflow non-
            visible inline blocks the higher of the actual baseline (
            at initial scroll position) and the margin-box bottom.
            Separately investigate whether to switch from margin-box
            bottom to padding-box bottom for sanity. (requries web-
            compat check)

  ACTION: TabAtkins and fantasai to update Box Alignment spec per
          resolution, propose wording for CSS2.1 errata
  <trackbot> Created ACTION-678
Received on Thursday, 9 April 2015 10:37:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:53 UTC