W3C home > Mailing lists > Public > www-style@w3.org > February 2012

[CSSWG] Minutes and Resolutions Paris F2F 2012-02-07 Tue Afternoon II: CSS2.1 Errata, Spec Process Proposal

From: fantasai <fantasai.lists@inkedblade.net>
Date: Sun, 12 Feb 2012 01:11:41 +0100
Message-ID: <4F3703BD.40406@inkedblade.net>
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 ======

     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)

     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
   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:
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
   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
   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
   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
   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
   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
   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,
   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
   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
   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
   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
   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
   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
   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
   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.
     When any feature is implemented (as shown by publicly posted test
     case document), a public working draft is published.
     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.
     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.
     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*.
     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*
     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.
     Follow standard W3C process. Suggestions welcome.
Received on Sunday, 12 February 2012 00:12:12 UTC

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