- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 11 Mar 2015 20:29:43 -0400
- 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