- From: Dael Jackson <daelcss@gmail.com>
- Date: Mon, 30 Sep 2013 19:19:09 -0400
- To: www-style@w3.org
- Message-ID: <CADhPm3sta0j6L3QWxkTN3mRfs+78CtohNx0Va0LPu-Vb=2U9pg@mail.gmail.com>
GCPM
----
- 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===========
GCPM
----
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.
<projector>
http://people.opera.com/howcome/2013/tests/css-gcpm/coverage.html
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
way.
howcome: The differences between them has been the main focus of GCPM
edits.
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
archived.
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
followed.
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
doing.
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:
http://antennahouse.com/CSSInfo/property.html
liam: Second, we have now at W3C a publishing interest group, where a
number of major publishers have come to discuss their
requirements.
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
engines.
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
production.
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
browser".
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
implementors.
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
functionality.
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
example.
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
implementations.
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
publish
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
publish?
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
webapps.
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
elsewhere.
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
yourself.
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
point.
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
*done*.
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
specifying.
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
Draft.
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
implementing.
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
reading.
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
decomposition.
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
docs.
howcome: I don't want to spend time splitting without consensus to
publish.
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
mark-and-sweep.
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 ...?"
Proposal:
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.
[break]
Received on Monday, 30 September 2013 23:19:39 UTC