- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 21 Nov 2013 18:33:49 -0500
- To: www-style@w3.org
Text Module
-----------
- Discussion was deferred.
Charter
-------
- Bert will update the list of deliverables on the charter.
- Later the possibility of asynchronous decision making was discussed.
The group briefly considered the benefits and problems of
asynchronous decisions, but decided that it would be worth
discussing further.
- Dbaron will write up a proposal for asynchronous decision making.
Styling Left vs. Right Pages
----------------------------
- Leaverou brought up the difficulties with writing/designing books in
CSS and that no adequate solution had come from the mailing
list.
- A potential solution was to adapt Regions to address the problems,
but it was decided that implementor experience was needed to
decide how to handle the adaptation.
- The group did decide that the fix did belong in Regions or Pages,
depending on which was receiving priority.
=====FULL MINUTES BELOW======
Text Module
-----------
ScribeNick: SimonSapin
fantasai: Are we to prepared to discuss this?
plinss: Let's defer.
Charter
-------
<plinss> http://www.w3.org/Style/2013/css-charter
Bert: Last time we had milestones and a wiki page for dates.
Bert: Most people said that they can't put dates.
Bert: There's now a list specs in scope, and it says we don't have
dates.
Bert: It's mostly same as previous charter,
Bert: Same participation reqs, chairs, mailing list.
Bert: The list of modules longer
Bert: There's a different list of liaisons.
Bert: Look; if it's complete and not too long,
Bert: It's about not having milestones, only a list of things we work
on, without dates.
Bert: Do you agree with that? Can it get past AC review?
Bert: Glazou said we have a few drafts that are requirements for other
groups, and we should give that higher priority.
Bert: I didn't list those, glazou sent an email with the list.
Bert: We could mark those explicitly.
astearns: Is there a logic to the order?
Bert: No, an automatic tool takes the order from the /TR page.
Bert: The date is to be updated when we have review, roughly 2 years.
dbaron_: My guess the order is by age of WD.
dbaron_: There is a bunch that appear twice.
Bert: That's a bug.
fantasai: I suggest taking the Current Work page.
dbaron_: It looks like a list of all shortnames ever used
<dbaron_> duplication: UI, borders, CSS1 ,CSS2
Bert: Does someone wants to get through the list to fix?
fantasai: Can you take it from Current Page?
<fantasai> http://www.w3.org/Style/CSS/current-work
Bert: Some are missing from there.
ChrisL: That's a feature
<dbaron> We're also probably not going to work on becss.
* fantasai notes she needs to update Ruby and Syntax in that list
<fantasai> Yeah, don't want to include the Abandoned drafts
<dauwhe_> Page templates isn't on the list.
plinss: Any feedback on the charter? Are folks generally happy with
it?
ChrisL: We're looking at the suggested extensions from 1998 and
slitting our wrists.
plinss: Should we update the module list before we submit?
dauwhe_: Page templates is only an editor's draft.
dauwhe_: I believe we resolved to get simple pagination done first,
before making page templates a working draft.
ChrisL: It looks fine, I suspect AC won't object.
ChrisL: We say we don't have milestones because ...
ChirsL: and say that things needed by HTML5 are...
plinss: Send an email to internal list when ready.
ACTION: Bert to update the list of deliverables in the charter
<trackbot> Created ACTION-595 - Update the list of deliverables in the
charter [on Bert Bos - due 2013-11-19].
plinss: anything else on charter?
<dbaron> I wouldn't mind seeing us doing asynchronous decision making,
but I'm not in the mood to have that discussion right now...
<SimonSapin> dbaron +1
<astearns> dbaron +1
<sgalineau> asynch decision discussion better done asynchronously.
<TabAtkins> dbaron, belated +1
Styling left vs. right pages
----------------------------
leaverou: We've discussed this in private and on mailing list.
leaverou: Long conversation, but no conclusion has been reached.
leaverou: People write books in CSS, including design of the book,
leaverou: I first designed mine in Illustrator, then many things were
not possible in CSS.
leaverou: There was no way to style elements depending on right or
left pages.
leaverou: We have @page, for the page itself or headers/footers, but
not elements on the page.
leaverou: To do sidebars in print formatters, you use "float:
outside",
leaverou: To push it you use "float-offset" but that's limited
leaverou: It's not just the sidebar, [projecting]
leaverou: These things have different border-radius, rotate transform,
margin, etc. depending on left/right page.
leaverou: float: inside/outside and margin-inside/outside are not
enough
leaverou: We can't just keep adding properties, we need a more generic
solution.
<leaverou> http://lists.w3.org/Archives/Public/www-style/2013Jul/0607.html
leaverou: That's the proposal on the list...
leaverou: @page :left, nest style rules,
leaverou: The syntax not doable, ambiguous with declarations.
leaverou: This needs infinite look-ahead, same as in Hierarchies
<TabAtkins> Note, Hierarchies has been fixed.
leaverou: The proposal is to use braces, at-rules, or pseudo-elements
leaverou: div::page(left)
leaverou: That's still limited, you want to style based on type of
page (chapter, ...),
leaverou: And other page selectors.
leaverou: The other proposal from AntennaHouse: extending Variables to
inherit from @page,
leaverou: But then you have different property values on different
pages for the same element.
TabAtkins: How?
fantasai: Whatever syntax we use here should be the same as for
Regions.
<TabAtkins> SimonSapin:
http://tabatkins.github.io/specs/css-nesting/Overview.html#the-nested-block
<TabAtkins> SimonSapin: Wrap the selectors in an anonymous {} block.
<TabAtkins> Rather, the whole thing.
dbaron: Styling things between pages has a lot in common with between
regions.
dbaron: We don't want to allow completely arbitrary style,
dbaron: We don't want something that starts as a table, continues as a
float, etc.
dbaron: There is no concept to continue the inside of a table onto the
next page as something else.
dbaron: So far we don't have the ability to fragment things into
completely different types.
dbaron: If we have a display-inside / display-inside split, we can't
change display-inside between fragments.
dbaron: We're gonna need implementor experience.
leaverou: It could be limited to not allow some properties like
display,
leaverou: Or just no style fragments, only based on the first page.
dbaron: There may still be some hard cases.
dbaron: It's hard to spec and get interoperability, even if easy to
implement, with edge cases,
dbaron: With this style it fits on this page but doesn't with this
other style.
dbaron: I'm also not convinced that styling based on the first page is
that useful.
leaverou: I realize there are use cases of spawning pages, but most of
what I've seen are within one page.
astearns: When you're printing, you control pagination,
astearns: On screen, things intended to be on one page may be split.
leaverou: Print formatter vendors have clients that demand features,
and they will implement even without a spec.
dino: I agree these are all great use-cases, but who is gonna do the
work?
fantasai: Once we hack the syntax and model stabilizers for Regions,
the only thing that would different in syntax is changing
the word Region to Page.
fantasai: The hard part of the work, Alan is already working on.
astearns: I agree with dbaron that we're gonna need implementor
experience to decide what can be styled. We don't have it
yet for Region.
leaverou: By the way, there is already a pseudo-class for styling...
In paged media or GCPM, styling fragments of an element are
based on what page they appear.
leaverou: The fragmentation problems still exist.
dauwhe_: I want to mention that left/right and named pages also need
to identify arbitrary pages in a sequence,
dauwhe_: Like 6th page in a sequence.
leaverou: Another thing needed is syntax like :nth-page,
leaverou: For targeting pages between the 10th and the 100th.
leaverou: That would be useful for page number.
leaverou: There is no such thing as inline-block for margin boxes...
dino: You would need nested regions of pages that themselves can be
styled.
* krit :nth-all-the-things
dauwhe_: PrinceXML has :nth-page
dauwhe_: There's discussion on www-style, but it's complicated to
define what is a page, first of chapter vs. first of
document.
dauwhe_: There's a whole class of issues around identifying pages.
SteveZ: XSL did come up with rules to select which of the next
template is used for a given page.
SteveZ: You want a number of sources that are active, choose the
template based on what kind of things are available.
SteveZ: Which template you pick depends on which are associated with
the content of that page.
SteveZ: This divorces the design of the template with their selection,
it's rule-based.
SteveZ: :nth-page assumes that you know what content goes there,
SteveZ: As astearns says you may not know.
SteveZ: XSL tried to define it but never succeeded in sync points.
SteveZ: The notion of identifying sync content, stream of figures /
stream of text,
SteveZ: This thing/figure goes with this piece of text,
SteveZ: As close as possible, which may not be very close, but at
least being able to declare that would be useful.
<TabAtkins> Note my previous discussion with Hakon, that
"foo:nth-page(5)" does *not* select the 5th "foo" page,
but rather the 5th page if it is also a "foo" page.
<TabAtkins> In other words, selectors don't modify each other.
<SimonSapin> TabAtkins, so how do we select the 5th foo page?
<TabAtkins> :nth-match(5 of foo)
<TabAtkins> We've already solved this problem in Selectors.
<SimonSapin> TabAtkins, cool
plinss: I agree this should be aligned with Regions
fantasai: It doesn't belong in Fragmentation.
plinss: Is it useful for multicol?
fantasai: I think less so.
fantasai: We should track it as something we need to address, note
that we need this for Pages, but not much to do right now.
astearns: If Antenna House or Prince wants to run with it...
astearns: I'd be happy to put a note "this mechanism should be applied
to Pages."
astearns: If there is implementor interest, Pages may be done before
Regions,
astearns: But I don't know how Antenna House or Prince are
prioritizing this.
plinss: Is there consensus that this is a good idea?
leaverou: If the mechanism is defined in Regions, do we still need to
define the syntax?
astearns: There is a syntax for Region [...] all content that falls in
this region, here is their style.
astearns: The same would apply when selecting a page instead of a
region.
astearns: You're just changing that part of the selector that says I'm
styling this region.
ChrisL: We still need to write this down.
astearns: It will be the same for styling content in Shadow DOM.
<TabAtkins> Pages uses a somewhat different selection mechanism
(at-rule to introduce the selector), but yeah, similar
mechanics.
leaverou: The way this will be done in Regions is through
pseudo-elements?
fantasai: Yes.
leaverou: But @page rules are more concise.
leaverou: If you have a series of things that need to differ, page or
page style, you need to repeat the page selector.
fantasai: That's same problem with regions, we should solve this for
all of the things.
<TabAtkins> ".foo::region .bar" for .bars inside of the region hosted
by .foo
astearns: The syntax for Regions has the constraint that it needs to
fit in future nesting mechanisms that reduce repetition.
leaverou: Will this apply to all page selectors and combinations of
those?
dauwhe_: I guess we just start trying things.
plinss: We're trailing off, but I'm not hearing any objection. Will
follow the work on Regions.
Bert: We have Dave as editor of GCPM, I suggest we concentrate the
effort around Dave.
Bert: We see which things are already covered in Regions.
<dbaron> Why do we want to push this into GCPM?
<dbaron> [minute taker fell off IRC]
ScribeNick: dino
Bert: People should meet informally to discuss the next steps.
plinss: I don't have an issue with David taking this on. Some people
have suggested a page layout task force so it doesn't take up
much of the group's time.
plinss: I don't want to continue dumping "all the things" into GCPM.
<dbaron> +1 to plinss
dbaron: I'd be inclined to say that this deserves it's own module.
astearns: Or a new level of paged media.
plinss: That's possible.
Rossen_: What happened to the one daniel was starting in Lyon?
Rossen_: This sounds like the same conversation we've already had.
SimonSapin: He has a proposal for the future of paged media
<dbaron> http://dev.w3.org/csswg/css-page-4/
plinss: Dave, are you willing to champion the work?
dauwhe_: yes
SimonSapin: We discussed two things: one of which leaverou asked
(styling elements based on page location), and better page
selectors (which is in the paged media spec).
plinss: We also need to expand on "spreads."
r12a: Are you going to discuss CSS Text?
plinss: We deferred because fantasai needed to prepare.
fantasai: I can maybe work on it during lunch
fantasai: Agenda+ for backgrounds and borders?
plinss: OK
dbaron: Agenda+ one thing about charter?
plinss: Let's do this one now.
Charter
-------
dbaron: I have a comment about asynchronous participation.
dbaron: Many WGs have requirements about asynchronous decision making.
e.g. WebApps, a bunch of related API groups, and HTML (but
that is a special snowflake).
dbaron: I don't necessarily want to force the asynchronous decision
making policy here, but I would like to see us try to make
asynchronous decisions more often.
dbaron: Asynchronous decisions meaning decisions are not generally
taken in a meeting like a vote. Rather the chair sends the
notification via email, people then can object before some
time period elapses.
dbaron: I often find myself unsure whether or not to object within 10s
at a meeting. I think asynchronous leads to decisions made
with more consideration.
dbaron: What do other people think?
<TabAtkins> Asynchronous decision-making will likely speed up a lot of
decisions, too. No need to wait for a slot during tel-con,
potentially getting bumped multiple weeks.
<astearns> TabAtkins: +1
ChrisLilley: On the one hand...
ChrisLilley: That can be a benefit... e.g. Tab isn't here and he needs
48 hours to object..
ChrisLilley: But I don't want to be in the situation where we're
waiting for people to read the notification, stall, etc.
ChrisLilley: How is it working in other groups?
dbaron: One of the important points is that these groups are not
making the decision EVER on the telcon, but everything is on
the mailing list.
dbaron: The forcing function is sometimes useful. I don't participate
in these groups, but I've heard it is working well.
steveZ: Asynchronous also allows people not on telcons to get
involved.
SteveZ: The notification needs to be clear what the decision will be.
israelh: In webapps, I've noticed that sometimes the decision thread
doesn't really give you a clear outcome, and we still need to
come together on a call to make the final final final
decision. How do you figure out what the tiebreaker is?
kennyluck: It's often dependent on the type of decision: publishing a
spec vs technical decisions.
<kennyluck> My point is that I don't know who can send CfCs. Everyone?
plinss: In general all I care about is making good decisions.
plinss: I'm ok with whatever technique we use to get to that point.
plinss: I'll note that we often do asynchronous because we know
someone is not yet ready/present.
plinss: dbaron, are you encouraging us to do it more?
dbaron: Yes, we should do it more.
krit: So will it be all decisions, or will we still need these F2F
meetings?
astearns: I think people will get comfortable with asking for more
time to decide.
plinss: Yes, to be clear, all WG members are free to ask for more time
or open something if it is an error.
plinss: We've never refused such a request.
zcorpan: I think asynchronous works pretty well. But if there is a
situation where we can make a decision now, that should be
available, Maybe just not the common case.
krit: I'm asking for whether all decisions must be made at telcons, or
if the mailing list was enough.
dbaron: The mailing list would be enough.
sgalineau: Agreed.
plinss: Do we want to put this in the charter?
dbaron: Some other groups have it in the charter. I don't think we
need it to be that formal, but we should move in that
direction.
SteveZ: Should we put that it is allowed into the charter?
dbaron: Maybe.
SteveZ: Maybe it should be listed as a process to stop people
objecting to the process.
astearns: There is nothing in the charter that says all decisions
require a quorum, so we're not explicit.
SteveZ: I would like to understand the rules.
<kennyluck> +1 to SteveZ
<dauwhe_> Documenting the process would be helpful for new members.
krit: dbaron, could you send a proposal to the mailing list?
dbaron: Yes.
SimonSapin: There's a good question on irc, who can ask for a decision
on the mailing list?
fantasai: It should always come from the chairs.
plinss: I don't think we should say that we're going to do everything
this way. Some things might be better this way, others might
not.
plinss: Anyone can always ask the chairs to adjust the way we work,
even for a particular issue.
plinss: The fear is that we'll be making decisions by default because
people are not participating.
astearns: It will be interesting to see how many bad decisions we've
had to back out because no one participated.
plinss: Maybe it will be better if the email is clear what the
decision will be.
plinss: We'll probably have to have discussion about what the proposed
decision will be.
<sgalineau> +1. Straw polling rarely works over email. Better make a
call to force feedback.
dbaron: I think it works for "can we publish."
SimonSapin: I don't think this is about taking options away.
plinss: Agreed.
ACTION: dbaron to send a proposal for async decisions
<trackbot> Created ACTION-596 - Send a proposal for async decisions
[on David Baron - due 2013-11-19].
<sgalineau> So the conclusion is that we'll discuss this on the
mailing list...
[Lunch Break]
Received on Thursday, 21 November 2013 23:34:17 UTC