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

[CSSWG] Minutes TPAC F2F 2013-11-12 Tues II: Text Module, Charter, Styling Left vs Right Pages

From: Dael Jackson <daelcss@gmail.com>
Date: Thu, 21 Nov 2013 18:33:49 -0500
Message-ID: <CADhPm3vK1m+1o2A_zYXF7wX+r7P21EegB03qjQWBNW+vQiLN_w@mail.gmail.com>
To: www-style@w3.org
Text Module

  - Discussion was deferred.


  - 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
  - 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.


Text Module
  ScribeNick: SimonSapin

  fantasai: Are we to prepared to discuss this?
  plinss: Let's defer.


  <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
  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
  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:
  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
  leaverou: We can't just keep adding properties, we need a more generic

  <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

  <TabAtkins> SimonSapin:
  <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
  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
  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
  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
  * 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
  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
  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
  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

  leaverou: The way this will be done in Regions is through
  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
  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.


  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
  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
  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
  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
  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

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