- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Sun, 12 Feb 2012 01:11:41 +0100
- To: "www-style@w3.org" <www-style@w3.org>
CSS2.1 Errata
-------------
Discussed some difficult margin-collapsing issues in CSS2.1
Spec Process
------------
Tantek proposed a new spec process with triggers for transitions.
WG agrees the triggers are appropriate for triggering a discussion
about process transitions, but shouldn't be forcing anything.
====== Full minutes below ======
Present:
Rossen Atanassov (Microsoft)
Tab Atkins (Google)
David Baron (Mozilla)
Bert Bos (W3C)
Tantek Çelik (Mozilla)
John Daggett (Mozilla)
Elika Etemad (Mozilla)
Simon Fraser (Apple)
Sylvain Galineau (Microsoft)
Daniel Glazman (Disruptive Innovations)
Vincent Hardy (Adobe)
Koji Ishii (Invited Expert)
Håkon Wium Lie (Opera)
Chris Lilley (W3C)
Peter Linss (Hewlett-Packard)
Luke Macpherson (Google)
Alex Mogilevsky (Microsoft)
Anton Prowse (Invited Expert)
Florian Rivoal (Opera)
Alan Stearns (Adobe)
Steve Zilles (Adobe)
Observers:
Jet Villegas (Mozilla Corporation)
Tavmjong Bah (Inkscape)
<RRSAgent> logging to http://www.w3.org/2012/02/07-css-irc
Agenda: http://wiki.csswg.org/planning/paris-2012
2.1 errata
----------
antonp: We've got about 88 issues on the bug tracker, with about 20 more
I'm tracking and need to carry over.
antonp: The remaining will need a lot of work to decide what's even wrong.
antonp: The majority of the stuff on the list is not hard, and I think
just needs to be approved.
<smfr> https://www.w3.org/Bugs/Public/buglist.cgi?product=CSS&component=CSS%20Level%202&resolution=---
antonp: So, we're not going to do 88 bugs in the next hour. What's our
strategy, and our timeline?
antonp: There are a few that I think could benefit form a discussion now,
6 in particular.
antonp: Which we could do easiest first, or hardest first.
antonp: So, first, general strategy to get them fixed, then we can discuss
some specific ones.
fantasai: I think a good strategy would be to put a couple on each telcon,
so we burn them down eventually. And have a proposal ready to
discuss.
fantasai: So each week, we have one or two CSS 2.1 issues to look at that
the WG can discuss.
dbaron: I find it easier to think about a bunch at once, rather than
switching regularly.
antonp: Is that because of topic? The topics divide up well.
antonp: And then there are many easy editorial-like ones that can push
through fairly easily.
dbaron: Okay. And I think it's good to come up with a proposal.
fantasai: And if there isn't one, we should be discussing who's writing
a proposal.
antonp: Another question, what's our timeline for all of this?
antonp: What are the reqs for an errata document?
fantasai: It's continuously maintained. As soon as we resolve, it goes
on Bert's to-do list to update the errata.
fantasai: We'd like to publish an updated 2.1 Rec sometime this year.
fantasai: Ideally around June, but we can push it to August or whatever
if necessary, if we have a few more bugs to handle.
florian: I think most important is to resolve them faster than reported.
florian: I don't think it's quite necessary to have them all resolved at
the same time.
antonp: Sounds reasonable.
antonp: Most of these are small, editorial tweaks. Only a small number
require real thinking.
antonp: So, do we now want to actually look at some of these beasts?
antonp: We have two on margin-collapsing, one is kinda hard as it
contradicts an old resolution.
* sylvaing has a nagging suspicion Anton considered issue 60 as easy
<tantek> note: for ASCII art, here is a handy web-based visual editor:
http://www.asciiflow.com/
Scribe: fantasai
<dbaron> http://www.w3.org/TR/CSS21/box.html#collapsing-margins
Anton draws on the board
Anton: Partial margin collapsing could have been the perfect solution,
but also kindof hard.
Anton: This is the rewrite of the old margin collapsing stuff
(points to screen)
Anton: I'm using this wording b/c far better than the old wording, and
for purposes I'm discussing is exactly the same.
Anton: This is the situation we have. We have a box with a min-height.
And it has one child, and the child is self-collapsing.
Anton: The result of collapsing the child is this here (points at dotted
rectangle inside solid rectangle). It is about to collapse with
the parent's top margin.
Anton: Problem is it also wants to collapse with the bottom margin.
Anton: Not defined what happens there. Does this collapsed margin
collapse with the bottom or the top or what?
Anton: There was a discussion of min-height and max-height and their
effect on collapsing.
dbaron: There was at one point a distinction between whether min-height
prevented collapsing through or collapsing the last child's
bottom margin with the parent's margin when the margin was not
collapsed with the parent's top margin
Steve: Sounds like you said the case is already complete.
dbaron: It's a hard compromise we ended up with
Anton: There are one or two tiny things that need to be rethought, but
not relevant to this case.
dbaron: There was one issue I object to in the rewrite, because it made
a case where the spec was self-contradictory be defined here.
Anton: I believe it exists as a contradiction here.
Anton: This is the contradiction.
dbaron: I agree there's a contradiction in what to do here.
dbaron: Last time we discussed it, didn't think about that.
dbaorn: old spec contradicted itself with what collapsed with what.
Anton: Think that transferred across. No difference, except this spec
there's a slight.. it uses adjoining when it means collapsing
and vice versa.
<arron> do we have a test page that shows what anton drew on the board?
Anton: Adjoining is now a non-transitive issue. Collapsing is a
transitive issue.
Anton: Collapsing is transitive because a collapsed margin ... Oh,
hang on, maybe it's not an issue.
dbaron: I thought we wanted adjoining to be transitive?
fantasai: I tried. I couldn't do it.
dbaron: The old contradiction was that there awas a statement that
these 2 things collapse, and these two things don't.
fantasai: I think most of the old text is in that note.
Anton: To approach this problem, worth pointing out what discussions
were had in the past.
Anton: Was a very important case in the past where you've got your box
here, you've actually got a genuine child non-collapsing child
Anton: And the non-collapsing child has a margin which is really long...
*draws margin that flows out of the box*
Anton: and parent has a bottom margin.
Anton: This child with the bottom margin, the height of that margin is
bigger than the min-height of the box.
Anton: What happens here? Does this force the parent to become bigger?
Anton: Doing something different with min-height and max-height causes
discontinuities.
dbaron: They were dropped because something we really wanted to do and
couldn't get two implementations passing the test suite, but
what we decided to do didn't make sense.
Alex: We have resisted conditional margin collapsing that depends on
content actually hitting min-height or not. min-height has an
effect or doesn't have an effect.
Alex: All other aspects of margin collapsing can be calculated before
layout starts.
Alex: [...]
Anton: The reason then that we have ourselves in a weird situation
is because of that.
Anton: Now, because there's no instructions about min-height in the
spec anymore, we have a strange situation where this was a
self-collapsing element *points at first drawing*
Anton: Another interesting issue, now, *draws solid box inside bigger
solid box*
Anton: Spec says that the bottom margin of this small child collapses
with the margin on the parent, even though the box is plenty
big enough to contain the child and its margin
* arron appreciates fantasai's descriptions of what is drawn on the board.
<alexmog_> +---------------+
<alexmog_> | |
<alexmog_> +-|---------------|--+ +
<alexmog_> | | | | |
<alexmog_> | +---------------+ | |
<alexmog_> | margin 1 | |
<alexmog_> | | | min-height
<alexmog_> | | |
<alexmog_> | | |
<alexmog_> | | |
<alexmog_> | | |
<alexmog_> +--------------------+ v
<alexmog_> margin 2
Anton: From what I can tell from the minutes and resolutions, it was
recognized that the resolution didn't solve all the problems,
and it was recognized that it wasn't solved, would have to be solved
later
Anton: Seems to me fundamental problem, should this margin collapse
with the one down there?
Anton: Here you can do something sensible.
Anton: In the case where you've got a non-self-collapsing child, as
the last child
Anton: You can do something sensible to collapse its bottom margin
with the parent's bottom margin.
Anton: You have to choose, but you can spec something sensible.
Anton: But in the case where you have self-collapsing margin, you can't
Anton: How does this margin manifest itself? You have a positive-height
box, but it's supposed to be self-collapsing.
dbaron: I see 2 possible changes to spec to fix this.
dbaron: Minimal one is to change the third bullet under the third bullet
in definition of adjoining.
"bottom margin of a last in-flow child and bottom margin of its
parent if the parent has 'auto' computed height"
dbaron: To add the condition that either the parent has zero computed
min-height, or the bottom margin of the last in-flow child does
not collapse with the top margin of the parent.
dbaron: Thought we had a condition like that in the spec.
dbaron: And this condition with an either-or: either parent has zero
computed-min-height, or, bottom margin of the last child doesn't
collapse with the top margin of the parent.
dbaron: What I'd really prefer is to reduce the condition by saying
it's just "and the parent has a computed zero min-height"
<dbaron> change from: "bottom margin of a last in-flow child and bottom
margin of its parent if the parent has 'auto' computed height"
<dbaron> change to option 1 (minimal):
"bottom margin of a last in-flow child and bottom margin of its
parent if the parent has 'auto' computed height and (the parent
has a zero computed min-height or the bottom margin of the last
in-flow child does not collapse with the top margin of the parent)"
<dbaron> change to option 1 (preferred, but I don't remember why we didn't
do it before): "bottom margin of a last in-flow child and bottom
margin of its parent if the parent has 'auto' computed height and
the parent has a zero computed min-height"
Alex: I think reason min-height is not mentioned there is that we don't
want to prevent margin collapsing when min-height didn't take effect.
Alex: If you have min-height of 1px, min-height will not make a difference,
but will prevent margin collapsing.
Anton: exactly
Anton: Seem to be definitely in past resolutions to not distinguish cases
of whether min-height takes effect or not.
Anton: But I think you can't have continuity if you think to that.
dbaron: ...
Alex: min-height has an effect, and bottom margin doesn't collapse with
top margin, your position will change ....
Anton: resolution in the past ...
Anton: we have to say that those can collapse
Anton: Brings us back to this case (points at solid solid boxes)
Alex: ... is pretty rare, and making that work, with all of the complications
that we have
Alex: If we make it work, will be pretty complicated, but we're not sure
how much we really need it.
Anton: Confirming that we don't exclude min-height in general that would
be collapsing here.
Alex: One case you've shown doesn't make any sense, but keeps everything
predictable
Anton: Important to decide what we want in this case, b/c will help us
understand the contradictory case.
Anton: David your solution is then appropriate for this
(points to middle picture of collapsed margin inside min-height box)
Anton: Self-collapsing box sits at the top, doesn't make sense to collapse
to the bottom.
Anton: In this case you need to break collapsing with the bottom.
fantasai: I think we discussed this situation wrt defining the position
of the self-collapsed element, not here for how to collapse it.
Anton: Yeah, the border position is well-defined. Just not defined how it
collapses.
Anton: The border position sets up a hypothetical situation where you
don't have these collapsing.
Anton: There is an issue where if you've got a min-height, you begin by
doing the calculation based on the normal height, and you do the
Chapter 10 calculations to determine your height.
Anton: If that's less than the min-height, then you do your calculations
again.
Anton: assuming that the height is then set to the specified min-height.
Anton: In all of these cases, incidentally, height is assumed to be 'auto'.
Anton: There's a note in Ch 10.7, that tries to explain something about
margin collapsing. But I can't understand what that note is saying
in relation to this.
Anton: If you're recalculating b/c you're assuming auto height, then
assuming height = min-height, you run into different rules in margin
collapsing.
Anton: Confusing note in 10.7, don't know whether it's trying to address
this situation or not.
<dbaron> These steps do not affect the real computed values of the above
properties. The change of used 'height' has no effect on margin
collapsing except as specifically required by rules for 'min-height'
or 'max-height' in "Collapsing margins" (8.3.1).
<dbaron> (note in 10.7)
dbaron: I think what the second sentence means is that the change of used
height has no effect on margin collapsing. (period.) However
min-height or max-height might have an effect as defined in 8.3.1
Anton: So, you do all your calculations with height, but not big enough
b/c have min-height, and have to redo the calculations
dbaron: Note says that you don't recompute anything wrt margin collapsing.
It stays the way it was.
Anton: As in, all relationships of what collapses with what stays the same
dbaron: yes
Bert: Your rewrite of that sentence into the two parts is what I understand,
yes.
fantasai also agrees with this interpretation.
<dbaron> Possible rewrite of note: These steps do not affect the real
computed values of the above properties. The change of used
'height' has no effect on margin collapsing. 'min-height' and
'max-height' only affect margin collapsing as specified by the
rules in in "Collapsing margins" (8.3.1).
Anton: Ok, with that interpretation of the note... I think that doesn't
add anything new to this.
Anton: Think suggestion of preventing margin-collapsing in this case is
enough to solve the problem, and doesn't contradict what's intended
by the other rules
Anton points at child inside larger box case
Anton: I don't think there's anything that says if this margin collapses
with the other margin, which border it sticks to.
Anton: You'll get strange behavior either way, but it's not defined where
the collapsed margin resides
Florian: If you say they dont collapse... but that brings up other problems.
dbaron: Where do we define where the position of the next block is?
Anton: There is a whole issue on where is actually the top content edge
dbaron: We do actually define ... in [really convoluted case]
Anton: You might be right, there might be a loophole in a special case.
But in the general case not defined.
...
Anton: If we're going to collapse these two things, then it should go to
the parent. Otherwise it's really odd.
dbaron: 9.4.1 says the vertical distance between 2 sibling blocks is
determined by the margin properties
Anton: With a big leap of faith you can make that work.
Bert: I know I tried to rewrite that in the Box Module...
fantasai: I think for things that are a bit handwavy and need a leap of
faith... well, it's an old spec. We need to rewrite all this,
and shouldn't do that rewrite as 2.1
fantasai: Should just fix errors in it.
fantasai: So I believe there are two issues here.
fantasai: One is that if you have a self-collapsing only child and a
min-height, don't collapse the child with the bottom parent
margin
fantasai: Other one is, if a parent and child margins collapse, the
collapsed margin is attached to the border edge of the parent.
dbaron: I think we should say where the top of a block goes. Which
right now we don't
Anton: So we note this down as something that needs to be turned into
proposed text, discuss that text on the telecon.
ACTION Anton: Record these two issues and the conclusion, point to
these minutes, write a next-action to propose text.
<trackbot> Created ACTION-435
Anton: Absolute positioning is defined in terms of the top margin edge
of something.
Anton points us to definition of static position
dbaron: static position doesn't really matter, because UAs may approximate.
dbaron: I'd try 10.1 or 10.6.4 (?)
<Rossen> http://www.w3.org/TR/CSS21/visudet.html#static-position
dbaron quotes from the spec the part about "... would have been the first
box of the element ... specified clear had been none ..."
<dbaron> More precisely, the static position for 'top' is the distance
from the top edge of the containing block to the top margin edge
of a hypothetical box that would have been the first box of the
element if its specified 'position' value had been 'static' and
its specified 'float' had been 'none' and its specified 'clear'
had been 'none'. (Note that due to the rules in section 9.7 this
might require also assuming a different computed value for 'display'.)
<dbaron> (from 10.6.4)
Anton: Issue is that it says that the static position for top is from the
top edge of the containing block.. to the top margin edge of the
hypothetical position
Anton: So you need to know the top margin edge, which is not well-defined
in most cases.
Anton: If margins don't collapse, it's obvious where it is.
Anton: But when you have margin collapsing in general... you have this
blob in the middle. can you really say where the top margin edge is?
Alex: Top of the collapsed margin
dbaron: Does anyone know why we say top margin edge of the first child
box rather than top content edge of the box itself?
dbaron: That might solve the problem. Or may be different and not what we mean.
Bert: ...
dbaron: nevermind that question
Anton: Top margin edge is not a well-defined concept, except in exceptional
cases
dbaron: I'm going to suggest this issue lead to someone writing test cases
to find out what implementations actually do
Anton: I think this was discussed by Øyvind from Opera, who wrote testcases,
found there isn't an issue in practice, but spec doesn't reflect the
practice.
Anton: Don't think we should define a top margin edge.
Anton: Example is in the bug tracker somewhere.
Anton: There's very weird kind of things when you've got self-collapsing
elements trapped in the middle of a collapsed margin
anton: Where the self-collapsing element has a 20px top margin, but when
you calculate it's border position doesn't allow for a top margin
of 20px
anton: There aren't enough pixels above the top border edge
Anton: B/c of this don't think we should define where the top margin edge is.
Anton: Instead I think where it relies on the top margin edge, seems to be
a consensus that we should define it relation to the border edge,
which is well-defined
Anton: We define static position in terms of the border edge, and then add
the top margin edge onto it as a correction.
Steve: That seems to have the effect that in the collapsed margin case, ...
Anton: It would be this height above its border edge...
Anton: defining the top margin edge to be up here *points above the collapsed
margin* doesn't make sense to me, so would rather not do that
Anton: [my suggestion] seems to match implementations
Alex: Example of what's defined as margin edge?
Anton: It's not defined. The text defines static position (10.6.4) in terms
of the top margin edge, which is not defined.
<smfr> http://www.w3.org/TR/CSS21/visudet.html#abs-non-replaced-height
dbaron: So, I'm ok with whatever bzbarsky is ok with, because I defer
everything about static position to him.
dbaron: I also don't especially care. I think it's a horrible concept.
<Bert> (Something like: "More precisely, the static position for 'top' is
a length A - B, where A is the distance from the top edge of the
containing block to the top border edge of a hypothetical box that
would have been the first box of the element if its specified
'position' value had been 'static' and its specified 'float' had
been 'none' and its specified 'clear' had been 'none'; and B is
the top margin of the element.")
Anton: b/c spec doesn't make sense as it is, important to make testcases,
and check that proposed wording doesn't change the behavior of those
test cases.
[Alex and Anton discuss the issue]
Alex: top: auto means it won't move in reasonable cases
Anton: ...
Alex: I'm not proposing recollapsing. Saying that for purposes of that
position, margin is used [...]
Anton: The way i understand there's inline and block. Inline, no margins.
If you make inline abspos, it will be shifted down by its margin.
fantasai disagrees
fantasai: Inline has a margin, it just doesn't affect line height
Alex: for block, we know very well ...
Alex: It's top margin, which we don't have to collapse with anything b/c
it's positioned.
Alex: It's inline, it's out of flow.
Alex: To determine the static, all you do is look at the bottom of this
line, and it's ... in the current flow and that's it
Alex: The top margin used for static calculation has now been collapsed
Alex: It's not even a block for purposes of static layout
Alex: it's a hypothetical situation
Alex: For hypothetical situation, nothing to collapse
Anton: Doesn't explain final result
Alex: Does. because abpsos elements are out-of-flow that have in-flow
static position, determined by anonymous line
Anton: You're saying that abspos elements leave an inline-level placeholder
Anton: Even if they're blocks.
Anton: The spec definitely doesn't say that at the moment.
Anton: In tables it does.
Alex: Having something absolutely positioned... a line.
Alex: element has no right to collapse with anything else because it has
never been a block.
Alex: only hypothetically
Alex: it's happening relative to that imaginary line, as if that was a
line with some kind of content
Alex: With that no collapsing would happen
Anton: Where is the position of that line?
Anton: I see, would be anonymous self-collapsing block.
Anton: I'm fairly certain it doesn't leave behind a placeholder currently
in the spec
Alex: ...
Alex: Abspos element is inline content
Alex: That for all other purposes is empty, but it has very well defined
position
Anton: I understand the argument you're making, but I don't think the spec
is there.
Anton: Spec says to treat it as non-abspos to find its position, and if
it's a physical inline-level box. You're redoing layout with a
different assumption.
Anton: But you're saying when it's abpsos, it leaves behind a placeholder
that affects layout.
Alex: ...
Alex: That defines inline position of abspos
Alex: our implementation also has a line which might be empty which has
a... ok Rossen disagrees.
Anton: I honestly don't think that's what the spec says.
Alex: I think it's good idea to define hypothetical position precisely.
Alex: Rossen do you disagree with anything I said?
Rossen: abspos elements that are blocks, ... we do not collapse margins
Rossen: So, we will not use the collapsed position for abspos elements.
Rossen: This is what everyone currently does
Rossen: I agree with Alex on something he said in the beginning.
Rossen: which is, if we insist to keep this top margin position, then we
also need to specify it if the margin didn't collapse
Anton: So when it said you must treat it as if it's position static, and
float is what it was, etc. etc. You'd add another one that says
"And margins of this element did not collapse"
Rossen: But that to me seems to open a can of worms.
Anton: You're saying if it was a static block, imagine you had a static
block, and its float was not reset to none, and clear really have
an effect, and imagine that it didn't collapse any margins...
Anton: But you have to be more specific: not collapse which margins?
Alex: ...
Anton: Part of calculating static position is you ignore margins..?
Anton: b/c what happens with its children and their margins, which used
to collapse/not collapse
Anton: i think testcases are the way to go here.
Anton: Don't think it's as simple as saying "don't collapse margins"
Anton: Of course won't collapse it's margins when its positioned anyway
Anton: b/c won't collapse once it's been abspos
Alex: ... a lot of simplifications to not overcomplicate the positioning
Alex: A lot of ... are not going to happen the same way as in normal layout
Anton: I don't have an opinion on this, just as the moment it's not
currently well-defined.
Anton: Need a way to define it. Which *might* be placeholders, or [...]
Rossen: Asked for action item to have a section on that in css3-positioning
Anton: We still need to do something for CSS2.1, because the text doesn't
make sense atm because it relies on an undefined concept.
Anton: The proposal on the list was to do it in terms of border position,
then tweak it to account for the margin.
Alex: UAs are free to make a guess, so that makes it completely free.
fantasai: So, we've been discussing this for awhile. How about you write
proposed text in terms of the border edge, since it seems that's
a good way to go. And if Alex wants to implement that in terms
of a placeholder in a line box in a self-collapsing anonymous
block, that's fine.
fantasai: Just make sure there's testcases and the spec *results* match
implementation *results*
ACTION Anton: write proposed text and testcases
<trackbot> Created ACTION-436
Anton: Does the root element establish a BFC root?
dbaron: I think it's established by the ICB, not the root element
Rossen: If you want to model the browser window, how would you do it? You
would create a <div> with fixed size, and make it overflow: auto
so you get scrollbars. That's your viewport
Rossen: This is what we do in IE.
Rossen: ICB is not exception to anything
Rossen: It's just an element, just not accessible to OM
Rossen: If this is what you mean, then I agree it should be a BFC.
Rossen: If you mean the root element, then should be driven by properties.
Florian: I believe in Opera we treat the root element as an abspos.
Rossen: Up to implementer, but if you model this as an element, but needs
to have auto scrollbars, so needs to be a BFC.
fantasai: Root element is not the ICB
Anton: I'm talking about the document root element
<dbaron> https://www.w3.org/Bugs/Public/
<dbaron> https://www.w3.org/Bugs/Public/show_bug.cgi?id=15702
<dbaron> https://bug590491.bugzilla.mozilla.org/attachment.cgi?id=469029
dbaron suggests people to run this testcase
dbaron: Question is, where is the orange bar?
dbaron: chrome has changed to match Gecko since this was written
topic deferred to tomorrow
<dbaron> I've sent the whiteboard photos from the 2.1 discussion to
www-archive, but they haven't gotten through yet.
<dbaron> http://lists.w3.org/Archives/Public/www-archive/2012Feb/0011.html
<dbaron> http://lists.w3.org/Archives/Public/www-archive/2012Feb/0010.html
<arron> dbaron, thanks for doing that I will hopefully be able to understand
the 2.1 conversation better now.
<dbaron> timestamps in CET
<dbaron> and metadata in UTC
Spec Process
------------
[See Tantek's proposal in the appendix below]
Tantek: Started to try document our spec development process, and how we
try to move faster within W3C process
Tantek: Top is complaints we have
Tantek: Trying to look at positive side here, how to improve in the future
tantek: Have some principles:
Tantek: Publish early and often to show interest/activity
Tantek: Transparently note objections/issues
Tantek: Advance as rapidly impelmentations and tests show interop
Tantek: Drop/postpone features lacking implementations rather than trying
to keep things together.
Tantek: In short, I think any editor, anyone in CSSWG shoudl be able to
check in editor's draft that agrees with the charter.
Tantek: When objections are noted, editor's responsiblity to include in
the draft.
glazou: ... No, not possible. Would break discusison of [...]
glazou: Any idea must be proposable to the WG, and our role afterwards to
decide whether to include charter
plinss: Stike requirement that it be in the Chater
ChrisL: That first point is about transition *to* editor's draft
plinss: For example Tab's hierarchies thing. He's not creating an editor's
draft, he's creating a proposal.
plinss: From idea to proposal document, anyone can check anything in,
doesn't have to match our charter
plinss: To move from proposal to ED, need to have a charter discussion
Tantek: Next one is important. Sometimes takes way too long for EDs to
pushed as FPWD. We need to be much be more active about this.
Tantek: Suggest that as soon as something is implemented, we push it to FPWD.
ChrisL: Why wait that long? Does that mean without implementation, you
can't publish FPWD?
Tantek: No, this is saying to treat it as a forcing function.
glazou: I have one big concern with this step. if the implementation
implements something that is not stabilized, and even under
strong scrutiny and criticism, the implementation won't reflect
the discussion and the fact that it's not stabilized
glazou: This is WHATWG approach that specs do not matter, only implementers do
ChrisL: earlier is better b/c of IP timer
ChrisL: As soon as there's a list of features, even not clear what they
are, that's when you want to push for FPWD
<ChrisL> because there is a 150 day exclusion period. and any feature not
in that fpwd can still be excluded following last call
dbaron: So, what it looks to me,
dbaron: If someone believes there is something in a draft they believe
should not be in CSS, the first point to object is the PR boat.
Tantek: No, editor's draft. Has to be documented in the editor's draft.
dbaron: But what does that note lead to? Does the note end up in a PR?
Tantek: Point of note is to list it as there being contention.
glazou: Note that editor's draft can be modified without WG approval.
fantasai: I think one of dbaron's points -- that the current policy of the
WG that we go to FPWD when there's agreement that we want to work
on it.
fantasai: And if we don't get to that agreement we don't publish as FPWD.
fantasai: We have to get consensus in the WG that we want to work on it
before we go to FPWD, and that's not reflected here.
Tantek: That's part of the goal is to prevent somebody to stop something
from being published just by objecting.
plinss: She's talking about whether there's even consensus to work on the
draft.
fantasai: If we go with your proposal, then a single vendor can, just by
implementing a feature and writing a spec for it, publish a
WD on /TR/ as if it represented WG consensus
sylvain: Take the hierarchies example earlier today.
plinss: I don't think it makes sense to publish FPWD of something where
there's no consensus to work on it.
Steve: But you don't get ED without a consensus
fantasai: Why are we distinguishing Proposal vs. Editor's Draft Without
FPWD? If we have agreement to work on something, it should go
to PFWD. Why not have it on /TR?
Tantek: if you have a shipping implementation, you should get FPWD
glazou: I strongly object to that.
plinss: We have things we've published and then lost interest in.
plinss: Don't think we need a forcing function here.
<dbaron> So I think a problem with this model is that these transitions
lead to implementations as well.
dbaron: I think the underlying issue that this idea doesn't consider is
that all of these transitions themselves cause implementations.
dbaron: The act of putting something on dev.w3.org increases the possibility
of implementation.
dbaron: Pushing to FPWD maybe makes it more likely.
dbaron: We have the power to influence what gets implemented. And we should
consider how we use it.
Tantek: Problem is we are being behind. Editor's drafts are being published
and implemented. W3C Process is being circumvented, and nobody's
talking about it.
Tantek: Stuff is happening, let's move forward.
glazou: An editor's draft can be modified without WG approval.
glazou: Which means a member of this WG can edit a draft, and the draft
goes to FPWD without approval of the WG. I don't want that.
Florian: Your model assumes any proposal is a positive one. Which is not
necessarily true.
Florian: I think if something ships and we don't have a WD, we should be
considering it. But we shouldn't automatically go to draft. It
should be a trigger to consider it.
glazou: It should go on the radar of WG. But that's already the case.
plinss: If these are phrased as these force us to discuss it, that's fine.
glazou: A WD is published automatically? *shakes head*
plinss: We can't publish a transition without a group resolution anyway.
Steve: I was just going to say, W3C took action to move submissions from
TRs to put them in a different place b/c they found the system was
being gamed by ppl writing things and submitting them and saying
they're now a W3C spec, 'cuz now on the W3C site.
Steve: So there is reason for what Florian and Daniel said. Need
consideration to keep people gaming the system.
Tantek: It's worse now. /TR doesn't matter anymore. Editor's drafts are
being implemented.
Steve: Saying that you're shipping a W3C standard...
Tantek: They say they're implementing a W3C standard and link to editor's
draft
jdaggett: That's a little bit of a separate issue.
Steve: I don't believe we're contributing to that piece of it.
jdaggett: I think you're trying to accelerate things based on implementations
being available.
jdaggett: Problem is you start spitting out specs in chunks. Definitely be
more confusing.
smfr: We just did that with css3-images
Steve: We're collecting implementation reality. That's a good thing.
plinss: As long as you have interoperable implementations, then ..
jdaggett: You realize this means this is beginning of every spec is one
property. Every property has one spec.
Florian: Not necessarily. Did for gradients because there is urgency on
gradients themselves.
glazou: Don't make it one implementation. Make it two. Then you don't
have a working draft, you have a CR. You can even have implementation
reports and move fast.
glazou: Have browser vendors propose things that are more stable.
Tantek: Let me finish summarizing.
Tantek: From WD to LC, as soon as any feature has two itneroperable
implementations, according to test suites etc,
Tantek: The draft goes to Last Call. Any features that are not implemented
at all get listed as at-risk.
Tantke: Next step is CR.
glazou: For step 2 have a problem.
glazou: In history of WG, we have never made test suites before CR. Not
sure that members have showed enough commitment to require test
suites before CR.
glazou: We've tried.
glazou: Unless we move to CR, no point.
ChrisL: But we can encourage that. And often people post samples.
ChrisL: Just collect examples in your spec and you have some tests.
glazou: I can live with it, we can try.
plinss: Reality is as soon as someone writes an implementation, they are
writing their own tests. They just need to write them in W3C format.
Tantek: Anyone can show a test that disproves your interop.
Tantek: During LC period.
Tantek: That resets 6-week LC period.
Tantek: At the end of that LC period, it goes to CR. Then everything with
no implementations get dropped. Everything with only one
implementation gets at-risk.
Tantek: During CR period, editor can iterate based on implementation
experience.
glazou: I think this part of automatic process I agree more.
glazou: At the end of LC review period, shift to CR *unless* LC period
has shown blockers.
glazou: Can have interoperably implemented with design issues that may
harm the Web in the future
Steve: non-internationalizable, etc.
Florian: We can set these as expectations, but not automatic. Look at
them one by one.
Tantek: At the end of 6mo CR period
Tantek: Then it "automatically" goes to PR, and any feature not interop
by test suite gets dropped.
Tantek: When I say dropped, I mean postponed.
Tantek: You just missed the train.
fantasai: Maintaining multiple versions of the same draft is annoying;
don't want to do that just so we can do CR->REC every 6 months.
Tantek: Trying to provide path for editor's accelerating their work.
Florian: As long as these are expectations, not automatic triggers,
it's okay.
Meeting closed.
====== Spec Process Appendix ======
By default the CSSWG follows the W3C Process: http://www.w3.org/Consortium/Process/
Here are some thoughts on improvements.
===== test and implementation driven agile spec advancement =====
One of the most common criticisms of the CSSWG is that specs/features
take too long. In particular many features have been implemented with
vendor prefixes, inconveniencing authors and implementers alike for
*years* and resulting in a need to maintain support for prefixed
properties or worse [1].
[1] https://wiki.mozilla.org/Platform/Layout/CSS_Compatibility#CSS_vendor-prefix_compatibility
This proposal provides improvements that encourage rapid draft
advancement based on implementations and tests. - Tantek 2012-038
==== principles ====
Drafts should:
* be published early and often to show interest/activity
* transparently note objections/issues
* advance as rapidly as implementations and tests show interest/interop
* drop/postpone features lacking implementation(s) to not hold up
interoperable features
==== process for advancement ====
Here are proposed improvements to accelerate the advancement of specs.
These improvements can be adopted by the group as a whole, but they're
also designed for individual editors to follow as a way to more rapidly
advance their drafts.
✍ ->ED.
Any member of the CSSWG may check-in an editor's draft to present
ideas/content for consideration. Contents of the draft must be
within the WG charter. Any objections raised by CSSWG members must
be noted in the ED.
ED->WD.
When any feature is implemented (as shown by publicly posted test
case document), a public working draft is published.
WD->LC.
When any feature is interoperably implemented by more than one
implementation, the WD is automatically published as a LC with a
6 week review period. Any unimplemented feature is marked *at-risk*.
* This assessment is made at the CSSWG telcon/f2f.
* Since the CSSWG telcon is on Wednesday and the draft publication
occurs the next Tuesday, if anyone posts a public test case
document that disproves the interoperability before that Monday,
the LC is merely published as another WD.
* When anyone posts public test case document(s) that disproves
interoperability of all previously shown interoperable features,
the LC review period clock is stopped.
* When implementations are updated to once again demonstrate
interoperability of at least one feature, the 6 week LC review
period is restarted as of that date.
LC->LC
updates may be published per editor discretion, e.g. when more
features are implemented, which may result in fewer being *at-risk*.
This restarts a new 6 week LC review period.
LC->CR
At the end of the LC review period, the LC is automatically published
as a CR with a 6 month implementation period. Any unimplemented
features are dropped and postponed to the next version. Any features
with only one implementation, or not interoperably implemented are
marked *at-risk*.
CR->CR
Updates may be published per editor discretion, e.g. when more
features are interoperably implemented, which may result in fewer
being marked *at-risk*. The 6 month implementation period is *not*
restarted.
CR->PR
At the end of the CR implementation period, the CR is automatically
published as a PR. Any features that are not interoperably implemented
are dropped and postponed to the next version.
PR->REC
Follow standard W3C process. Suggestions welcome.
Received on Sunday, 12 February 2012 00:12:12 UTC