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

[CSSWG] Minutes Sydney F2F 2015-02-09 Part I: CSS 2.1 Issues, Font Loading API

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 11 Mar 2015 20:29:43 -0400
Message-ID: <CADhPm3vVaeDdwV1e0J7EszuKMNxfV4Ybf=w2qaaUDOE-DsdLnQ@mail.gmail.com>
To: www-style@w3.org
Agenda and Introductions
------------------------

  - This discussion to set the agenda held no technical details.

CSS 2.1 Issues
--------------

  - RESOLVED: Change the 3rd bullet point of margin collapsing
              (CSS 2.1 section 8.3.1): Bottom margin of last
              inflow child and the bottom margin of parent, no
              longer collapse if the parent has non-zero min-height
              and the bottom margin of the last inflow child
              collapses with the top margin of the parent.
              Exact changes pending more testing.

  - RESOLVED: Backport @charset parsing rules from CSS3 to CSS2.1.
              dbaron to propose errata; zcorpan to update tests

Font Loading API
----------------

  - There needs to be more use cases for font-face-set being
        constructible.
  - TabAtkins will re-order the process of observing the rejection
        and the queuing.

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

Present:
  Rossen Atanassov
  Tab Atkins
  David Baron
  Brian Birtles
  Rick Byers
  Tantek Çelik
  Dave Cramer
  Elika Etemad
  Daniel Glazman
  Koji Ishii (phone)
  Dean Jackson
  Toru Kawakubo
  Ian Kilpatrick
  Peter Linss
  Cameron McCormack
  Shinyu Murakami
  Robert O'Callahan
  Simon Pieters
  Xidorn Quan
  Florian Rivoal
  Andrey Rybka
  Dirk Schulze
  Alan Stearns
  Jet Villegas
  Greg Whitworth
  Johannes Wilm
  Steve Zilles

  Agenda Link: https://wiki.csswg.org/planning/sydney-2015#agenda

  Scribe: tantek

Agenda and Introductions
========================

  [This discussion to set the agenda held no technical details.]

CSS 2.1 Issues
==============

Margin Collapsing
-----------------

  glazou: First topic, 2.1 issues
  fantasai: The first issue, who will make the edits?
  TabAtkins: It's in github now so anyone can do it,
  fantasai: I nominate SimonSapin
  glazou: That's it?

  dbaron: I had an issue I meant to send email about.
  dbaron: It just was sent 30 seconds ago.
  dbaron: I don't know if anyone would have understood it anyway,
  dbaron: Since it is margin collapsing.
  <dbaron> https://lists.w3.org/Archives/Public/www-style/2015Feb/0189.html

  glazou: Do we need to call Anton?
  dbaron: Let's try to talk about this.
  dbaron: One of the discussions about margin collapsing:
  dbaron: We decided the prose in the spec was not very clear about
          transitivity.
  dbaron: e.g. if A collapse with B, and B collapse C, then A
          collapse with C.
  dbaron: If that's not true we need to define what it means.

  ???: What makes you think it is not true?
  dbaron: This guy writing reftest for margin collapsing, daniels,
  dbaron: does not believe this is true,
  dbaron: and a bunch of his tests match browser behavior.
  dbaron: I was trying to fix a bug,
  dbaron: that said min-height and max-height do not break
          margin-collapsing between the last child of a block and
          the bottom margin of the block.
  dbaron: min-height and max-height, even when they change the
          height, do not break margin-collapsing between the bottom
          margin of the last child of the block, and the bottom
          margin of the block.
  dbaron: I wrote a patch that fixed that.
  dbaron: It fixed those tests, but broke one other test,
  dbaron: that was interop in all engines.
  dbaron: However I could not figure out how the spec justifies that
          result.
  dbaron: What I'd like to know is, why does this test behave the
          way it does?
  dbaron: Either in engines or in the spec .
  <dbaron> https://lists.w3.org/Archives/Public/www-style/2015Feb/att-0189/block-no-content-8.html

  dbaron: Test:
https://lists.w3.org/Archives/Public/www-style/2015Feb/att-0189/block-no-content-8.html
  dbaron: Reference:
https://lists.w3.org/Archives/Public/www-style/2015Feb/att-0189/block-no-content-8-ref.html
  dbaron: The key question is gap between 2nd and 3rd block.
  dbaron: 60 px between blocks 1, 2
  dbaron: 40 px between blocks 2, 3
  dbaron: My patch makes it 60 px between blocks 2, 3
  dbaron: but spec appears to say it should be -20px between blocks
          2, 3.
  dbaron: Every margin in the test should collapse.
  dbaron: The interesting question is what happens between the green
          blocks.
  dbaron: Blue has a min-height and a child.
  dbaron: Spec says if it did not have a child, its top / bottom
          margins would not collapse.
  dbaron: If you have a non-zero min-height and no children then
          margins do not collapse.
  dbaron: But in this case we have a block with min-height with a
          child,
  dbaron: all have top/bottom margins.
  dbaron: Spec says they should all collapse.

  TabAtkins: Is the confusing line why min-height has an effect with
             no children?
  dbaron: The spec's wording is weird, but I think I understand why.
  fantasai: (reads from 2.1 spec re: margin-collapsing)
            http://www.w3.org/TR/CSS21/box.html#collapsing-margins
  dbaron: The thing with the min-height only applies when there's no
          children.

  florian: I'm actually confused, what can it mean for the
           top/bottom margin of the parent to collapse?
  dbaron: There's a rule elsewhere that says where the block is when
          its top & bottom margins collapse.
  florian: Is this useful for a block of non-zero height?
  florian: That seems just weird.
  dbaron: Yes. I would go further, not clear any use of top/bottom
          margins of the same block ever collapsing. but we're stuck
          with that.
  florian: To do so when the block has non-zero height is even worse.

  dbaron: (reads from 2.1 spec re: margin-collapsing)
  dbaron: (bullet 1, bullet 2)
  fantasai: The problem is we did not want to do partial collapsing
            (re: min-height), and decided to just do this stupid
            thing instead.
  dbaron: I should do more playing around with this test case to see
          what happens in other browsers.

  fantasai: What is the interop on?
  dbaron: This test case. 60 px above, 40px below,
  dbaron: margins 3 & 4 are not collapsing.
  fantasai: The spec should say non-zero min-height means top/bottom
            margins do not collapse.

  florian: Partial collapsing?
  dbaron: I would fine if we modified the rule that ...
  dbaron: It would be consistent to modify the 3rd bullet point in
          the nested list,
  dbaron: to say what it says already,
  dbaron: but then add and "and the parent has zero computed
          min-height, or the bottom margin of the last inflow child
          does (not) collapse with the bottom margin of the element".

  dbaron: 3rd bullet point:
  dbaron: Bottom margin of last inflow child and the
  dbaron: bottom margin of parent,
  dbaron: no longer collapse,
  dbaron: if the parent has non-zero min-height,
  dbaron: and the bottom margin of the last inflow child collapses
          with the top margin of the parent.

  fantasai: [explores another possibility]
  fantasai: There's two definitions:
  fantasai: There's a definition for collapsing
  fantasai: and a definition for adjoining.
  dbaron: No, that sentence below makes adjoining transitive.

  fantasai: We know what we want to say now.
  fantasai: We just need to work on phrasing it.
  dbaron: I think agreeing on what we want to say should involve
          more testing of what browsers do.
  fantasai: Whatever it is it is an improvement over what's there
  fantasai: (in the spec).

  glazou: What is the resolution?
  fantasai: What dbaron said.
  dbaron: We should tentatively agree to do that, but do more
          testing.
  glazou: What do people think? there were only 3 people discussing.
  glazou: Any objection?

  RESOLVED: tentatively do what we agreed, pending more testing

  dbaron: I think the edit you fantasai proposed to make is already
          in the spec, the 3rd bullet.
  dbaron: The way this is written is unclear.

  ACTION fantasai: propose errata for margin collapsing issue
  <trackbot> Created ACTION-666

  glazou: We have to move on
  glazou: and continue working on the issues,
  glazou: or the next topic.
  glazou: In terms of 2.1 issues, what else?

@charset tests
--------------

  glazou: dbaron, @charset tests?
  <glazou> https://lists.w3.org/Archives/Public/public-css-testsuite/2015Jan/0016.html
  dbaron: This was a message from hsivonen,
  dbaron: regarding syntax level 3 changes rules for @charset.
  dbaron: There are tests in the 2.1 repository
  dbaron: that now test incorrect behavior.
  dbaron: We should fix the tests to match level 3
  dbaron: and errata 2.1 as well.
  dbaron: It seems bad to have tests in the repo that are telling
          people to behave in a way not compat with level 3, the
          latest spec.
  glazou: I agree let's fix both.
  fantasai: Yes, fix both.

  RESOLVED: Backport @charset behavior from CSS3 Syntax to CSS2.1.

  ACTION dbaron: propose errata for @charset in 2.1 that brings it
         into alignment with CSS3 Syntax
  <trackbot> Created ACTION-665

  glazou: Will hsivonen fix the tests?
  dbaron: Probably?
  jet: He has an open question at the bottom.

  fantasai: Basically what we should be doing is errata'ing 2.1
  fantasai: and fixing the tests
  fantasai: then backporting from 3 to 2.
  fantasai: Fixing the ones in 2
  fantasai: or getting rid of them.
  glazou: We have versions.
  fantasai: No, we have levels.

  glazou: Anything else on the 2.1 radar?
  fantasai: dbaron?
  dbaron: Just a possible tornado and a few thunderstorms.

  SimonSapin: In CSS 2.x sections, add links to newer specs that
              replace them.
  florian: So we should switch to snapshot topic.

  zcorpan: Did anyone volunteer to edit the tests?
  florian: You just did.
  zcorpan: I did? Okay. I can do that.

  ACTION zcorpan edit CSS 2.1 @charset tests to make them compliant
         with CSS3 syntax
  Created ACTION-667

Font Loading API
================

  <astearns> http://dev.w3.org/csswg/css-font-loading/
  heycam: test and tasks?
  heycam: [missed part of question]
  TabAtkins: That's a good question.
  heycam: There are many places in the spec where it says to queue a
          task, and does not say why it is necessary, or what the
          rules are for why this operation should be done.
  TabAtkins: Every time I do something it is observable, so it
             doesn't happen in the middle of some script.
  TabAtkins: You can't edit the fontfaces attribute at some times
             because JS might be looking at that.
  heycam: For operations that are definitely going to wait for the
          network that makes sense.
  heycam: But there are uses of that beyond 'wait for the network'.
  TabAtkins: In the font-face loading algorithm
  TabAtkins: we have two uses of delay task until parsing the
             font-data is done
  TabAtkins: or parsing of strings too.
  heycam: Parsing strings is pretty quick.
  TabAtkins: I purposely moved those into the async section of the
             algorithm, and from the async section I cannot sync
             update something that is script visible.
  TabAtkins: I have to queue a task.

  heycam: Can we discuss the open issues in the spec?
  heycam: Issue 1: It's about promise objects and internal set
          objects;
  heycam: pristine copies of things.
  <astearns> issue 1: http://dev.w3.org/csswg/css-font-loading/#issue-531209c4
  heycam: That is not something the webIDL spec says ...
  heycam: It should happen automatically(?)
  heycam: The other three issues I don't have an opinion on so we
          don't have to discuss them.

  heycam: Another thing - I question the usefulness of FontFaceSet
          being constructible, why you would want to do it?
  TabAtkins: I know I had reasons for it, I think it was related to
             workers.
  TabAtkins: Someone internally gave me a use case recently:
  TabAtkins: Stash a bunch of fonts into a FontFaceSet, tell when
             they're ready,
  TabAtkins: then all the fonts loaded at the same time,
  heycam: Could you not do that by creating separate font face
          objects?
  heycam: Do a promise.all?
  TabAtkins: Maybe?
  TabAtkins: If there's no reason not to make something
             constructible, there's no reason to make it
             non-constructible.
  heycam: It would complicate my implementation.
  TabAtkins: So basically I should look for more use-cases for it.
  ACTION TabAtkins document more use cases for FontFaceSet
         construction

  zcorpan: The queue and task discussion.
  zcorpan: If you select one, if it fails to parse, spec says to
           reject and set status to error.
  zcorpan: Then step 2, if it fails to parse, it says to queue a
           task.
  TabAtkins: That's because step 2 is async.
  zcorpan: Should step 2 queue a task to reject?
  TabAtkins: Rejection isn't observable to script until safe times
             anyway.
  zcorpan: What is the ordering between observing the rejection and
           the queuing...?
  zcorpan: Otherwise you can't read the status...
  TabAtkins: This is true, I should re-order those.
  zcorpan: There might be similar ordering issues elsewhere.
  TabAtkins: No, the rest are fine.
  ACTION TabAtkins to re-order those

  heycam: Are any other implementers interested in this API?
  TabAtkins: Beyond google and mozilla?
  heycam: This is based on an old draft right?
  TabAtkins: No, I don't think so.
  TabAtkins: someone recently changed ... (?)
  TabAtkins: If you know of anything not matching the spec or not
             matching your implementation, let us know.
  heycam: That's all I had.
  TabAtkins: OK

  glazou: Let's break. 15 min; no more.
  glazou: We'll start again with selectors.
Received on Thursday, 12 March 2015 00:30:20 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:30 UTC