W3C home > Mailing lists > Public > www-style@w3.org > September 2013

[CSSWG] Minutes Paris F2F 2013-09-12 III: GCPM

From: Dael Jackson <daelcss@gmail.com>
Date: Mon, 30 Sep 2013 19:19:09 -0400
Message-ID: <CADhPm3sta0j6L3QWxkTN3mRfs+78CtohNx0Va0LPu-Vb=2U9pg@mail.gmail.com>
To: www-style@w3.org

   - RESOLVED: Publish sections 1-5, 7, and 13 of GCPM ED as a new WD.
   - RESOLVED: Move section 6 to CSS3 page; section 8 to CSS color;
       section 9 to Page; sections 10, 11, 14 to Overflow; section 12 to
       Page Floats (new spec); section 14 to Overflow (for now,
       Pseudo-Elements when we write it); section 15 removed; sections 16
       and 17 to Page Floats

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

   Scribe: TabAtkins

   howcome: Yesterday's Napoleon rule still applies today.

   howcome: We have a WD from 2011.
   howcome: It should probably be updated.
   howcome: Lots of things have happend to the ED.
   howcome: Main focus was to document and track implementers.
   howcome: This is a chart that lists the features/main sections in the
            draft, then the implementations, tests, and example rendering.
   howcome: Two main implementors are Antenna House and Prince.
   howcome: They're in the process of changing the way books are published.
   howcome: 2 of the 4 top New York Times bestsellers are published with
            Prince, and Lea is writing a book now in Antenna House.

   howcome: It's possible to write a book in those formatters today, but
            it's hard.
   howcome: A lot of work went in to make sure the two do things the same
   howcome: The differences between them has been the main focus of GCPM
   howcome: So this spec is a little different from other specs.
   howcome: Applying the normal rules to this spec could lead it to being
            kicked out of the group, which I hope doesn't happen.

   ChrisLilley: Do you expect the unarchived discussion to continue, or
                transition to a more public forum?
   howcome: There's some healthy discussion on www-style now.
   howcome: But my communication with the vendors is private email.
   howcome: I have no problem publishing that, but it seems like I get
            better responses when I talk to them privately.
   howcome: Documentation is usually sparse, but asking them tends to work.
   ChrisLilley: Do they consider the info private?
   howcome: Not to my understanding.
   ChrisLilley: Proper WG discussion happens in an archived forum. How can
                we encourage this, so people other than those implementors
                can contribute their point of view?

   plinss: I'm concerned about patent policy when technical info is coming
           from outside the consortium.
   <dbaron> plinss: They're also not members of the WG and thus not under
            the patent policy.
   <ChrisLilley> Where do these external patent grants go?
   howcome: I believe Prince has signed *something*, which might be a
            patent policy thing.

   glazou: The fact that Hakon serves as a proxy for Antenna House and
           Prince slows down the communication process. We don't have
           direct access to the implementors, and can't discuss given
           technical points.
   liam: We had Antenna House in the xsl-fo group, but their implementors
         were Japanese and didn't speak or write English (or at least not
         well), so we rarely ever got feedback from them.
   liam: When we closed the group, we found out they'd implemented most of
         the draft.
   liam: So while I'd like to have a venue for them to participate, I
         recognize that in the past this has been a practical difficulty
         for them.
   howcome: And they have a fantastic implementation. I think documenting
            and getting it out will make the world a better place.

   howcome: If you go back to the table, the most complex part of the spec
            is page floats.
   howcome: And the bottom of the table is page floats.
   howcome: I'd say the focus in this should be to make these
            implementations converge.
   howcome: I'd like to have a good forum for that.
   howcome: So my goal is to get another WD out.
   TabAtkins: Never say no to a WD.

   fantasai: I think one of the problems is that the discussion isn't
   fantasai: So somebody else coming up with the same discussion can't
             see it.
   fantasai: Maybe www-style is intimidating, too high traffic. Would it
             help to have a separate list just for this?
   howcome: Maybe.
   krit: If Antenna House and Prince could give public feedback for this
         implementation table, that would be great.
   glazou: We've always had trouble with communication based on language.
   glazou: It's not going to change easily.

   glazou: Problem is documenting features that you have little input on.
   glazou: If I take some sections of GCPM, like page floats, it misses a
           lot of layout details. Some examples, but not enough detail.
   glazou: How does it interact with other layout features, etc. It's too
           light as a spec.
   howcome: I don't disagree. Part of the reason is that we don't know what
            those rules should be.
   howcome: And I've had experience that the rules aren't actually

   howcome: Antenna House/Prince implement based on customer requests, and
            then try to align it with the spec, but it's not really their
            first concern.

   plinss: But the spec isn't really describing what implementors are
   plinss: "Put it at the top of a column", for example, still doesn't let
            me know what it's doing.

   liam: AH had a poster at the balisage conference, listing approx. 200
         custom CSS properties they've added.
   liam: That's like 50% more, quite a bit.
   liam: Some are rather ad-hoc, because they came direct from a customer
         request. Proper design would probably end up with fewer.
   <Bert> Antenna House Property List:

   liam: Second, we have now at W3C a publishing interest group, where a
          number of major publishers have come to discuss their
   liam: Their problem is that the CSSWG is too technical for most of them,
         but it might be that that's a good place to take some of this
         work, and discuss with them how it meets their requirements.
   liam: I wonder if that might be a more productive way forward.
   liam: Work with those people, and then come back to CSS having
         established something with both publishers and implementors.
   howcome: I can't say there's anything wrong with your proposal.

   howcome: I'm just worried about giving people false expectations here.
            Listen to them, put it in the spec, and then nothing happens.
   ChrisLilley: Precedent - the JLTF reviewed stuff, produced a document,
                but then the relevant groups decided how to implement those
                requirements based on that document.

   glazou: O'Reilly isn't going to just change their engine if we come up
           with a compromise that is different form their implementation.
   glazou: This is a big issue - you're forced to spec what they've done
           even if it's suboptimal.
   glazou: Even if we have a much better idea how to integrate it with CSS.
   glazou: So standardizing what the implementors do is okay when what they
            do is good.
   glazou: I've carefully looked at Prince/Antenna House additions, and
           some are really hacky.

   Rossen: So is the point of documenting this just to validate their
           properties, or is it to try and work with us to come up with a
           solution, even if things change?
   howcome: I think it's something between there.
   howcome: But they're going outside of where CSS has gone before, and
            coming up with solutions that I think fit within the CSS space.
   howcome: Antenna House and Prince are different, but not *that*
             different. We can gently move to a common foundation.

   plinss: I think the win comes when we get these features in CSS that
            everyone implements in browsers, etc.
   plinss: If all we're doing is documenting how they've shoehorned
           something into their implementation, that won't help the web
           at large.
   howcome: Absolutely. And speaking as a browser vendor, I'm interested in
            this too.
   howcome: The things that haven't been implemented with Antenna House/
            Prince (blank spaces in the table) came out of discussion with
            Opera and Blink.

   plinss: I'm not sure there should be an exercise in tracking
           implementors, but rather in designing these features.
   plinss: These features aren't being designed as part of the platform.
           The fact that you have two implementations in Opera isn't
           enough, because I think you said it's the same person.
   plinss: What we're missing here is specification prose that allows
           different people to read the spec and come up with
           implementations that are compatible.
   plinss: If we can't get that, these shouldn't be in the spec as
           features, but just as ideas of things that we might like.
   <liam> +1

   astearns: And the point of doing this in the group is to get other
             implementors interested, so one day O'Reilly doesn't have to
             be stuck with Antenna House, they can get their books
             rendering in browsers, or any other place.
   ChrisLilley: That was one of the failures of XSL-FO - every feature was
                optional, so it was very hard to get interoperable.
   <liam> [not every feature, of course]
   howcome: But until browsers do real paged projections, there's no reason
            for browsers to read this.
   <ChrisLilley> my point was that many stylesheets were aimed at, and only
                 usable on, a single processor
   glazou: Not true. Some things, like string-set, are useful regardless of
           printing, and can happen at any time.

   plinss: In Hamburg a year ago, we had every browser around the table to
           agree to make printing a priority.
   <liam> [agree with the point, yes]
   plinss: I think having some of this discussion not taking place in this
           group is part of the problem.

   howcome: The resource constraint is implementors.
   plinss: And you have companies like Adobe here, which work in multiple
   astearns: We haven't seen the right solutions yet.
   howcome: I disagree - this spec has enough detail.
   glazou: I disagree.
   glazou: I read the spec in deep details. A name of a value and a
           one-line description doesn't give you info about the feature.
   krit: You were concerned about the platform in general.
   krit: Our WG in particular is about the web platform.
   krit: The book people may be interested in some of the web platform, but
          extending to fill all of their needs may not be necessary for
          the web.
   krit: Our WG is quite sensitive about defining properties not defined in
         the CSSWG.

   krit: So what do we do?
   glazou: So, two options. These people are extending CSS. These people
           can use vendor prefixes, and claim you are "CSS-like" forever.
           We can't do anything. Or two, do what Hakon does, and try to
           build something standardized and get everyone to implement.
   glazou: And if it's in this WG, it has to obey the rules of spec
   glazou: And that's an issue - we can't discuss with them. Thus, the
           feature descriptions are extremely light.
   glazou: I agree that some of these features *work*. I think I would have
           designed things different myself, but this is the start of a
           compromise that never happened.

   glenn: I think Dirk's point was a good one - where does work occur on
          future specs that this group doesn't focus on?
   glenn: Maybe for a long time this group has been focused on the web
          platform, but there are other applications where the web is not
          where they live.
   glenn: I don't think we should make a decision today that this isn't
          appropriate to work on.

   glazou: It's not just about the web. E-pub has been interacting for a
           long time.
   glazou: And ebooks are not the web platform. Still very static.
   glazou: Very specific requirements that differ from the browser world.
   glazou: HTML is used on TV, will be used on cameras, etc. everywhere.
   plinss: "Web platform" doesn't necessary mean "what you see in the
   ChrisLilley: You could shrink down the "web platform", or you could
                extend it out.
   ChrisLilley: Advantages to both.

   szilles: It seems the problem is not the size or the scope, but getting
            eyes on the doc that are interested.
   szilles: Part of what I'm hearing is that Hakon putting it in the spec
            doesn't generate views and doesn't generate implementors.
   szilles: This is the hardest part. It's easy to get a proposal, it's
             hard to get people to look at it.
   szilles: In part, the lack of participation by Antenna House/Prince is
             making that process more difficult in this case.
   szilles: That's not a comment on the validity of it, just that you need
            to market and sell something to get the uptake.
   howcome: I've been trying - I've been putting substantial efforts
            into this.

   howcome: The participation problem is that in a couple cases, the WG has
            decided to remove functionality that is essential for those
   glazou: This WG works on consensus - we agreed to remove two things, and
           you didn't comply.
   glazou: For example, Regions and Exclusions we're chartered to work on
           in two docs. Anything about those should be in those documents,
           not in GCPM.
   howcome: They're there because I think the current specs lack some
   plinss: You're saying this is a scratch space, but you're also asking to
            publish as a WD.
   plinss: Scratch space is one thing, publishing a WD is saying it's the
            work of the CSSWG.
   howcome: I'm happy to move those sections somewhere else - a note, for

   ChrisLilley: I noticed that those sections don't figure in the
                implementation table.
   ChrisLilley: I assumed that meant you wanted to publish only the things
                in the table.
   ChrisLilley: And meant to remove the other things.
   howcome: No, they're lacking just because they don't have

   dbaron: I disagree strongly with what Daniel said.
   dbaron: About Regions/Exclusions being chartered, and so all related
            work is in those documents.
   dbaron: Particularly since there have been many objections, and the
           actions of the editors has been to repeatedly ask to remove the
           issues without addressing the underlying issue.
   dbaron: And second, I want to *agree* with what Daniel said.
   dbaron: We should be able to have multiple proposals for a tech.
   dbaron: To respond to Hakon, the comment of "oh, this is just an ED" is
           part of what prevents this spec from advancing.
   dbaron: You keep adding to it and changing what is in it, such that we
           don't really know what it is, or what any plan for it in the
           future would mean.
   glazou: I said both that we were chartered, and decided to remove the
           two sections from GCPM.
   dbaron: I don't remember this, and probably would have objected.

   glazou: You've made a lot of edits in the last year to the draft, Hakon,
           that we haven't seen.
   glazou: You've posted only a few small details, almost too late to
           comment on.
   glazou: I think the ED is a living spec for whatever Antenna House and
           Prince are doing, and that's not the standardization process
           is for.
   <ChrisLilley> that would be helpful, to see exactly what you plan to
   howcome: If you don't care, you should kick it out.
   plinss: It's not that we don't care. It's that they're not trying to
           make this technically part of the open web platform.

   ChrisLilley: You said you had a presentation about what you want to
   ChrisLilley: I think that might help.

   dbaron: In response to Peter, I think the level of precision and detail
           needed to move forward with features like this in browsers, is
           much higher than what's in the spec.
   dbaron: I think there's a relation to that and the lack of
           interoperability between Prince and Antenna House.
   dbaron: I think that one of the steps to actually getting this
           implemented is (1) there's a bunch of existing paged media stuff
           we haven't implemented yet, and some of it's actually pretty
           hard and not well-specified.
   dbaron: To build more features on top of that... the bigger the pile of
           features is, the scarier it looks, especially when those
           features aren't very clearly defined and explained in terms of
           how they work and interact with other features.
   dbaron: One of the things that's often lacking in this spec is a
           description of an underlying model that makes it clear, not just
           how the feature works in simple cases, but how it works in
           interaction with everything else.

   ChrisLilley: Relevant to the web platform, I think Paged Media has been
                more about things that aren't document-like, such as
   ChrisLilley: So naturally, Paged Media seems more appropriate - it if
                was sold properly, about there being lots of useful things
                where "paged" presentation was an ideal fit, I think it
                would be better.
   howcome: I wish I could agree, but even simple things like page
            numbering haven't been taken up.

   glazou: What david said about models, though - for example, the 16
           margin boxes are complicated, and go against the print options
           espoused by browsers. So we have a lot of things to talk about.
   howcome: The problem is getting layout people to actually work on it. Of
            course the spec should always be better, but I don't think
            that's the stopping point.

   howcome: Simon, what's your understanding? Is the lack of specificity
            the problem?
   SimonSapin: I think in the last few years, there were a lot of problems
               that were basically impossible to implement, like the layout
               of margin boxes. fantasai and I worked to fix that, so I
               think css-page is better now.

   glazou: Even though the model requires some deep changes, it's not
           really just the single feature, but how it works with everything
           else in CSS.
   glazou: page-float: bottom? What if I put something else inside -
            another flow, or a grid?
   howcome: You could argue that since float:bottom has been there for 10
            years, it's Grid that should have specified things.

   howcome: I don't think it's the quality of the spec that's stopping
            this, it was the implementor interest, or else they'd have done
            simple things like page numbers.
   howcome: A lot of the spec has been pruned.
   howcome: Useful things we liked, like aligning leaders, have been
            removed for lack of implementors.
   howcome: The regions and exclusions stuff has been put at the end. I
            want to move them, but not remove them - I think they're useful
            to provide alternate ideas for how to implement them.

   glazou: To move the document along the rec track...
   glazou: This document has been on the table so long, everyone who would
           like to see it published ASAP is gone.
   glazou: You'll have to do some major cleanup - put things into another
           level if you want.
   glazou: I listed a few actions.
   glazou: 1) If a property isn't already interoperable for two
              implementors: remove from this version.
   glazou: 2) A property that is implemented by two, but not
              interoperablely: retain but mark at-risk.
   glazou: 3) Sections that conflict with other specs: remove and put
   glazou: Like color module for device-cmyk().
   glazou: 4) Test suite has to be started.
   glazou: If you want this to progress, it needs to progress with Rec in
           mind in the next 6 months.

   plinss: With regards to the testsuite, this isn't something yet that I
           can bring up in a transition request.
   plinss: You're only asking for WD now, but you have to keep in mind what
            will be needed in the future.
   plinss: Are the tests in our format, in our repo?
   howcome: No. But these tests are useful for me.
   plinss: Right there, you're describing the disconnect. You have tests
           useful to you, we need tests useful for the WG.
   plinss: If this is going to continue being published by the WG, it needs
           to be a product of the WG, working together with the WG.
   plinss: Is it a fair requirement to make this document in accordance
           with the WG's policies?
   plinss: You're currently producing this document in isolation by
   howcome: No, I'm doing it in greater concert with implementors than
            ever before.
   plinss: You're not doing it with concert with anyone in this WG.
   howcome: And if Daniel says that anything needs two implementors to get
            in a WD...
   glazou: Not for general specs. This is a special case. This spec has
           been around for *so long*.
   glazou: I want these features in a Rec as soon as possible. I'm not the
           only one.
   glazou: To reach Rec ASAP, we have to take what can be a Rec now, and
           the rest can wait.

   Bert: I think we've heard a number fo speculations about why this hasn't
         been discussed, but I don't think we need to talk about that.
   Bert: How *can* we get this discussed?
   glazou: Have Hakon more on our calls. Last time was like a year ago.
   glazou: When you're on the conference call, you can request things.
   Bert: It's not on the agenda.
   plinss: First thing Daniel has always said, after getting a scribe, is
           to ask for additional agenda items.
   plinss: Hamburg you definitely got time. I remember a previous meeting
           where you asked for time and didn't get it.

   ChrisLilley: I heard comments about the test format. Hakon said he has
                tests, and is willing to put them in whatever format we
                want. I don't think that got minuted. I think that's a good
   howcome: Absolutely.
   [let's do the timewarp again]

   fantasai: So what's the plan here?
   howcome: I plan to try and publish a WD, and continue to get interest.
   fantasai: Can we get those plans minuted?

   szilles: Exclusions offers an example of how to go faster and further -
            it was thought to be too broad at first. In several successive
            revisions, it's been cut down to the point where people *do*
            agree on the scope, and people are now working on
            implementations now that it's at a reasonable size.
   szilles: So I suggest that the fastest way to get this implemented is to
            cut it down, get it implemented, and then move on from there.
   szilles: Paper-pile phenomenon.
   szilles: So I suggest cutting out everything you don't need
            *immediately*. And probably rename what's left to get out of
            the GCPM hole.

   SimonSapin: You said you wanted Prince and Antenna House to converge.
               Have you heard interest from them in converging?
   howcome: mumble mumble
   SimonSapin: I implemented CSS 2.1 floats in weazyprint. It was *hard*.
               But because the spec has enough detail, I could do it based
               on the spec.
   SimonSapin: Based on what I read in GCPM, the examples show what it
               does, but I have no idea how to implement it.
   howcome: You're probably right. The two implementors didn't go to the
            spec first.
   howcome: Now I have to reverse-engineer.
   glazou: If you agree, I can come up with a list of sections in your
           document that could go to rec in 6 months time.
   glazou: So that tomorrow it can be a WD, a CR in 3 month, a Rec in 6.

   SimonSapin: In my opinion the whole purpose of a spec is to allow new
               implementations based on it
   glazou: And I think that's much better than arguing about process
           or whatever.
   glazou: That way you'll have a minimal set of features standardized by
           this WG, under our process, that you can show to your vendors
           that can make them converge.
   glazou: If you don't do that, I'm afraid we'll enter a WD/ED loop for
           5 years.

   Bert: How to get it discussed?
   glazou: Be on the conference call.
   howcome: I can't do that - the time is always bad.
   plinss: Just request it. We're always willing to discuss, especially if
           someone else is willing to champion.

   howcome: [discusses some sections that can be removed]
   glazou: From my perspective, the only sections that are reasonable
           specified is 1,2,3, and maybe 4. Starting with 5, you have a
           one-liner of prose, and the rest is examples.
   fantasai: I think 6 is straightforward too.

   plinss: [Pause] I think you're seeing this as a confrontation between
           you and the WG.
   plinss: Please understand everyone at this table wants these features to
           advance. We're not trying to block. We're trying to get it
   plinss: We're asking you to work with us to do it.
   astearns: In particular, speaking as the editor of Regions, I'd like to
             see your version advance as well as mine.
   fantasai: The sections that Daniel calls out are the only ones that are
             actually generated content.
   howcome: I think the overhead of going to Rec is significant. Splitting
             things up would make it too annoying to work with.

   <glazou> jdaggett: sorry, important discussion that needed to happen
   <jdaggett> no worries

   plinss: I'm sure that if this got broken up into smaller pieces, each
           piece could go to Rec in a year each.
   howcome: I don't think I agree, or have the motivation to do that.
   glazou: Vendors for the last 10 years have gone off and done things on
           their own, and not asked us.
   <dbaron> glazou: We never had a say in what these vendors implemented.
   Bert: I don't agree. They've asked. They may not like working in our
         mode, but they still asked.
  TabAtkins: The overhead for publishing rec's isn't great, but it's not
             that bad.
  TabAtkins: It's mainly ...
   <dbaron> I actually disagree with TabAtkins, I think the delays in the
            publication process are *major* overhead because they require
            splitting tasks up by months when they're best done together.

   glazou: Please list the sections you want to include.
   howcome: Everything from section 1 to 13.
   howcome: I feel it would be a betrayal of the implementors to do
            anything less.
   ChrisL: I think 14 could go in selectors4.
   liam: I think section 15 is just an idea, not a spec, even though I
         included it.
   howcome: So now 1-15.

   jet: Abstain
   howcome: yes
   Bert: yes
   koji: abstain

   leaverou: I want many of these features, but I also see how many of them
             are underspecified.
   leaverou: I want more time.
   glazou: No more time.
   leaverou: Abstain

   jdaggett: Abstain
   dbaron: I think no, but not sure.
   Rossen_: No
   krijnh: No
   michou: Abstain
   israelh: Abstain
   leif: No, but a smaller set I could say yes to
   shane: No
   TabAtkins: All options at once.
   liam: Yes
   TabAtkins: Can't make a decision now because I'm minuting and can't look
              at the document.
   kawabata: Abstain
   yamamoto: Abstain
   glenn: Yes
   fantasai: Defer to dbaron
   SimonSapin: With 15, no.
   ChrisLilley: Yes, if 8, 14, and 15 are marked as "this will move to
                another document".
   glazou: That's a no.
   zcorpan: Yes
   astearns: Yes
   plinss: Abstain
   glazou: No
   szilles: Abstain

   howcome: I think what we're voting about is whether this work will
            continue in W3C or not.
   fantasai: I think that 1,2,3 seem to be straightforward. Probably need a
             bit of tightening.
   fantasai: 4 is a bit underspecified.
   fantasai: 5 is *vastly* unspecified. And these two interact with layout.
   fantasai: 6 should move to paged media.
   fantasai: 7 seems okay
   fantasai: 8 should move to color
   fantasai: 9 is already in paged media (so removed from this spec)
   fantasai: 10 is cool, but not generated content, and needs more
   fantasai: 11, likewise.
   <astearns> q+
   fantasai: Those two I think are good to explore, but not fleshed out.
   fantasai: 12 needs more detail, but I really think it should be its own
             independent module. Floats level 5 or something.
   fantasai: 13, I'm not sure where they should go, but probably part in
             multicolumn. Needs to be worked out a bit more.
   fantasai: 14 makes sense. I don't know where it should go. Interacts
             well with overflow module. We don't currently have a
             pseudo-elements module to put it into.
   fantasai: 15 is not a spec.
   howcome: I agree with all of this. But I'm just looking for a Working
   fantasai: What I'd like to say is that for the things that need to move
             to another spec, we can take actions to move them.

   Action tab to move device-cmyk() to colors 4.
   * trackbot is creating a new ACTION.
   <trackbot> Created ACTION-580 - Move device-cmyk() to colors 4. [on Tab
              Atkins Jr. - due 2013-09-1 .
   Action fantasai to move page marks and bleed area to css3 page
   * trackbot is creating a new ACTION.
   <trackbot> Created ACTION-581 - Move page marks and bleed area to css3
              page [on Elika Etemad - due 2013-09-1 .

   <dbaron> q+ SteveZ
   * Zakim sees astearns, SteveZ on the speaker queue

   fantasai: Can you split page floats into a separate module?
   <liam> [note, the heartbeat requirement howcome mentioned is per WG, not
          per spec]
   howcome: No, I don't think so right now.

   astearns: I voted to have a WD because I think this is the right
             direction to go - paring it down to have a better chance of
   astearns: To get the feedback that fantasai just gave.
   astearns: I've had experience dealing with multiple documents over a
             monolithic one, and I find it *much* easier to deal with, and
             to get comments on.
   astearns: Rather than having people walk away because it's too much
   SteveZ: In some sense, Alan said what I wanted.

   Glazou: 9 no, 7 yes

   SteveZ: I voted to give you a guiding function to actually do the
   SteveZ: My perception is that the WG has given you a lot of input to
           move more effectively, and you've said no.
   <ChrisLilley> My no was only because my yes with 3 sections marked with
                 editorial notes was not accepted
   Glazou: 10 no, 7 yes
   howcome: If it's so important to move page floats to a separate spec,
            I'll do it.
   TabAtkins: With page floats moved, and the other moves that fantasai
              suggested, I'll do a yes.
   * Bert would actually prefer to merge several modules...

   SteveZ: Normally we operate by getting the docs first, then agreeing to
           publish, rather than publishing based on promise to produce
   howcome: I don't want to spend time splitting without consensus to
   SteveZ: I think you've heard consensus on the first six sections.
   glenn: The negative consequence of not publishing is not getting the
          early chance to get a call for exclusions.
   fantasai: This has already been WD, so we've gotten that.
   glenn: I think WDs have a low bar, and don't think we should hold things
          up to much.
   ChrisLilley: I heard several nos turning to yes with minor changes, so
                I'd like to see if we can find a straw poll that we can
                agree on.
   howcome: So let's move out section 6 and 8, move 12 to a separate draft,
            and delete 15.
   <dbaron> I think 11 belongs with 10, actually.
   TabAtkins: I strongly agree with dbaron

   tantek: If your goal is to advance as fast as possible, you need to ship
           as little as possible.

   <astearns> proposal: publish sections 1-5, 7, 13 in a new working draft

   [non-minuted discussion about what to publish]

   * hober thinks dropping presto and continuing to cite it as an
           implementor for the purposes of advancing features in the WG is
           the equivalent of having your cake and eating it too.
   TabAtkins: Given the joking expansion of GCPM to "Garbage Collection
              Placeholder Module", it seems this is the working group's own
   TabAtkins: we need to implement an incremental collector; this stop-the-
              world-and-run-a-full-gc stuff is too inefficient
   * astearns perhaps we should have a GCPM task force
   TabAtkins: We just need to increase memory sufficiently that we never
              run a GC. I propose brain farms.

   * Bert has many references to gcpm and other modules that get and got
          split and the pointers don't or won't work anymore. :-(
   <SimonSapin> Bert, we can keep the anchors in GCPM with "This has moved
               to ...?"

   1-5, 7, and 13 publish as GCPM WD.

   RESOLVED: Publish sections 1-5, 7, and 13 of GCPM ED as a new WD.

   Proposal: 6 to CSS3 page; 8 to CSS color; 9 to Page; 10, 11, 14
             to Overflow; 12 to Page Floats (new spec); 14 to Overflow
             (for now, Pseudo-Elements when we write it); 15 removed;
             16 and 17 to Page Floats

   <dbaron> I think 14 should be in the pseudo-elements module instead.

   RESOLVED: Accept the above publishing plan for distributing the rest of
             GCPM ED.

Received on Monday, 30 September 2013 23:19:39 UTC

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