W3C home > Mailing lists > Public > www-style@w3.org > October 2014

[CSSWG] Minutes Sophia-Antipolis F2F 2014-09-09 Part II: GCPM3/GCPM4

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 15 Oct 2014 14:06:49 -0400
Message-ID: <CADhPm3tEHXa7_8ATjdBk7Gh8D6ziu8gmXK3-Obbdud_jL0xGpg@mail.gmail.com>
To: www-style@w3.org
GCPM3/GCPM4
-----------

  - There was a wide-ranging conversation about moving GCPM3 forward,
    how to better spec items that are currently mostly magic, and
    what pieces would be better served in a different spec entirely.
    Proposed:
      - Named strings, leaders, target-counters, and bookmarks to
        CSS Generated Content Level 3.
      - Page selectors and page groups to CSS Paged Media Level 3.
      - Move complex running headers (beyond stringset) to a Regions-
        based solution.
      - Turn Footnotes section into a giant Issue.

  - For footnotes, there was general consensus that the current model
    relied too much on magic and that functioning footnotes are
    important to achieve.

  - There was some discussion of what a page is and reviving work
    on paginated views. Also on the impact of pagination on various
    APIs.

  - Later, dauwhe presented some proposals for GCPM4:
      https://dvcs.w3.org/hg/csswg/raw-file/404bad11480a/css-gcpm-4/Overview.html
      - Extensions to Regions in order to handle running heads and
        footers and footnotes, particularly for handling copying vs.
        continuation of a flow, and for extracting from the current
        page.
      - Using page templates to represent the footnote area and the
        16 margin box slots from Paged Media
    - General agreement on the approach, though it was felt the
      proposals needed more revision.

  - dauwhe offered to edit all relevant specs. \^o^/

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

  Scribe: ChrisL

Generated Content and Pagination
================================

  <astearns> http://dev.w3.org/csswg/css-gcpm/

  dauwhe: There's lots of topics to discuss, all related to
          paginated views.
  dauwhe: I'm wondering how to move GCPM3 forwards.
  dauwhe: Much of it is relatively uncontroversial and implemented
          by prince and AntennaHouse.

Footnotes and Copied Content
----------------------------

  dauwhe: Named strings is well interoperable and has been for five
          years.
  dauwhe: Few issues or comments.

  dauwhe: Running elements is controversial.
  dauwhe: It moves element content around. Lots of concern about
          this, as CSS wants to have a more general method.
  dauwhe: Region flows.

  dauwhe: Maybe move running elements and footnotes to GCPM4 and
          move rest forward.
  glazou: Are they compatibly implemented?
  dauwhe: Prince has a completely different syntax from a much older
          draft.
  glazou: So implementations are not interoperable and syntax is
          hacky and badly specified.
  dauwhe: The underlying mechanism is poorly documented, not really
          implementable.
  dauwhe: Yes, it's not like the other things.
  astearns: The feature is good but the way it is spec'd is not.

  glazou: AntennaHouse implements what is in the spec now.
  stevez: Do we deprecate or change the old approach to move
          forward?
  dauwhe: AntennaHouse prefixes everything, Prince does not.
  glazou: AntennaHouse said reimplementing new stuff was very
          unlikely.

  fantasai: We could work around it. Most of the actual generated
            content stuff is straightforward, and could be added
            to the generic CSS Generated Content module instead.
  fantasai: Then move page selectors to Paged Media.
  dauwhe: Yes, that makes sense.
  fantasai: Both those specs need to be moved forward anyway.

  glazou: In GCPM3,
  glazou: Footnotes are pure magic.
  SimonSapin: We should ping AntennaHouse on this.
  stevez: The old specs should say they are not being worked on.
  fantasai: We can document the current stuff in GCPM3 and say it
            has issues and we are looking for better solutions.
  glazou: Yes, want to see these issues in the spec.
  glazou: And have the feature marked at risk until solved.
  stevez: I'd prefer to leave the at risk mention until we get to CR.

  dauwhe: We do have a way we want to proceed based on regions and
          page templates.
  dauwhe: Some of that is in GCPM4.
  dauwhe: I made a new ED a couple of days ago.

  glazou: Footnotes needs generated hyperlinks. We don't have that
          elsewhere in CSS. It will happen with references, lists of
          pages etc. It is needed generally.
  ChrisL: We can avoid a lot of issues by not changing the dom, just
          the area trees.
  astearns: But assistive tech needs it in the dom probably.
  plinss: That raises the issue of events.
  zcorpan: What is the event model, target, cancel events etc etc?

  Bert: The latest Opera does not implement CLink, it stopped with
        Opera12. It is very useful.
  Bert: Originally it was for WAP, so a bit strange.
  glazou: Can we start from that?
  Bert: It should have a way to make things active elements.

  SteveZ: Make generated content a first class citizen, make
          it something that can be styled itself.
  glazou: That depends on what you mean by generated content. Is it
          :before and :after or something more complex?
  SteveZ: We want to make the generated content itself have structure
          so it can do more things. So it can be restyled.
  SteveZ: Shadow DOM has this,
  TabAtkins: CSS syntax is not best way to make complex content.
  SteveZ: Gradually adding more tweaks is poor. It's better to
          decide we want it structured. It's preferable to use
          shadow DOM.
  plinss: That's food for thought
  plinns: Between shadow DOM and CSS GC.
  dauwhe: Some pieces are already there, better to use them rather
          than hand-wavy magic.
  plinss: We can certainly explain CSS GC in terms of shadow DOM.
  dauwhe: That all sounds like a good plan for moving GCPM3 into a
          spec that make more sense.

  dauwhe: I'm working on running heads with regions and have been
          working with Peter Sorotokin on ePub adaptive layout.
  dauwhe: We can get flowing footnotes. Running heads are harder
          because there need to be more properties applied to the
          flow.
  dauwhe: Filling boxes with current element, but having
          fallback/persistence if not on a given page.
  astearns: There's a paper describes this well.
  astearns: (looks for)
  astearns: A wiki page of ideas,
  astearns: Given flow content up to a chapter change.
  <Bert> -> http://www.w3.org/Style/2013/paged-media-tasks#complex-headings
        some ideas for marking content for running headers and still
        using it in a flow

Copying Flows
-------------

  dauwhe: With content in both running heads and the regular tree,
          copy will not move.
  dauwhe: We use this in regular tree and also in region chains.
  SteveZ: Do flows restart? If so, it avoids repeating things.
  fantasai: We had an issue on having flow-from as either a property
            or a function in the content property. If you have it in
            the content property, then could have flow-from() and
            copy-from().
  SteveZ: It needs flow-into to do that.

  Bert: I'm thinking about sticky copies. It's more a pull model
        rather than a push model.
  Bert: Running header pulls from available candidates that have
        been labeled,
  Bert: With some elements marked never copy. I'm thinking of a
        syntax that makes it clear we are marking elements as
        candidates
  dauwhe: Like a dictionary running head?
  Bert: Headers have parts in common but they're not all identical.

  * fantasai ponders Bert's ideas
  <fantasai> Note to self: elt { flow-name: foo; }
             elt2 { content: extract-flow(foo) | copy-flow(foo) |
continue-flow(foo); }

  dauwhe: Sounds like epub adaptive layout.
  dauwhe: Candidates only within x number of pages then they expire.

  glazou: Some of them apply to non-paginated models as well, and
          then become far harder to explain.
  SteveZ: This all applies to a single page.
  glazou: We did not say the viewport is a page.
  dauwhe: The nearest candidate is displayed in a fixed region as
          the page scrolls.
  plinss: You can define so it also works in paginated views. It's a
          better model than treating pages as a special thing.

Defining Pages
--------------

  dauwhe: The largest question is: what is a page?
  dauwhe: dpub dom pagination:
  <dauwhe> https://www.w3.org/dpub/IG/wiki/UseCase_Directory#Pagination
  dauwhe: API for which page displays.
  astearns: The set of requirements is similar to those for regions
            API.
  astearns: The lists map pretty closely.
  astearns: We will need APIs like this to extend it.
  dauwhe: Still thinking which part of this list should get
          addressed first.

  astearns: Overflow section had a heading for paginated content
            (scribe missed)
  astearns: The page templates proposal well received but we can't
            work on it until we have pages. We need paginated view.

  Rossen: This was the motivation for Regions:
  Rossen: Two things often seen; all the focus is on layout and
          programmability is often less developed.
  Rossen: For non-print paged layout, we need a sound object model.
  Rossen: Defining an OM for regions was a hard task. Using GC moves
          us away from using something well defined into a less
          defined area
  Rossen: Windows store apps used epub viewers than started using
          regions. We got good feedback to use region as a page.
  Rossen: We don't define a page, the app author defines what is a
          page. The browser is one app that makes pages.
  Rossen: A bunch of regions paginate content,
  Rossen: Define the fragmentation.
  Rossen: Regions is a fundamental low-level building block for any
          templating model
  Rossen: Do not solve the application problems, solve the platform
          problems. Does fragmentation do enough?
  Rossen: What breaks should a fragmentation context respect? Should
          be user defined, use named fragment breaks, and be matched
          on application level.
  Rossen: You need to define what a page is and what fragment breaks
          to use.
  dauwhe: I agree with most of that.
  dauwhe: Do not limit to underlying building blocks. You can also
          make a high level pagination solution as long as it gives
          us script access to what happened so its not magic.
  Rossen: Great.

  Rossen: So you made a simple repeater template to make pages.
  astearns: But it's okay to expose only overflow pages without flow
            into it (....) (scribe missed)
  SteveZ: The goal is high level declarative mechanisms that are
          useful, Also for apis to get at the created objects.
  SteveZ: We need to see what people actually use in practice, after
          experimentation, then add high level mechanisms
  glazou: We are doing the same thing with motion path; it
          drastically simplifies complex transforms.

<br/>

GCPM4: Running Headers and Region Flows
---------------------------------------

  (break)
  Scribe: TabAtkins
  <dbaron> projector is showing http://dev.w3.org/csswg/css-gcpm-4/
  dauwhe: The motivation for this was playing around with regions,
          seemed to be a better path forward for running
          heads/footnotes in gcpm3.
  dauwhe: This is an attempt to collect some of the bits I think
          would need to be added to Regions to get solve these use-
          cases.
  dauwhe: First thing, sometimes we want the <h1>s to display in the
          document normally and *also* pull their content into a
          region for a running head.
  dauwhe: So it seems we need a property to do this.
  dauwhe: We've argued about names, so it's flow-policy here in the
          first draft.
  dauwhe: flow-policy: extract | copy;
  <astearns> could also be a keyword on flow-into
  dauwhe: [explains example from spec]

  dauwhe: Next is the idea of "persisting" the flow, so running
          heads stay the same on each page until a new one fills the
          region.
  dauwhe: flow-persist property
  <dauwhe> http://www.idpf.org/epub/pgt/
  dauwhe: Peter Sorotokin mentioned this in the epub adaptive layout
          spec.
  dauwhe: epub had "flow-options" which had exclusive | static |
          last.
  dauwhe: "static" would take the first instance of that element in
          the document and keep that forever.
  dauwhe: Which wasn't useful for running heads - it never changed.
  dauwhe: So "persist" just uses the last one until something
          happens to replace it.
  dauwhe: Sometimes if there are multiple instances of the element
          on the page you need to be able to tell which one to use.
  dauwhe: So first/start/last/first-except values.
  dauwhe: Those seem to be some modest extensions to Regions that
          would make running heads possible to implement on top of
          Regions.

GCPM4: Page Templates
---------------------

  dauwhe: Next piece is page templates.
  dauwhe: Page spec has 16 predefined margin boxes.
  dauwhe: Really they're quite useful and been great for making
          books for a few years.
  dauwhe: But it's only a small subset of the possibilities we'd
          like to address.
  glazou: The 16 margin boxes are nearly an interoperable
          across the batch processors - Prince/WeazyPrint/etc
  glazou: But some aspects of how they layout in the margin is magic.
  glazou: And they don't cover all the cases you may want when you
          do layout in a book.
  glazou: So the idea is to allow the creation of *any* kind of
          margin box through @slot that can override the definition
          of these 16 named margins.
  glazou: Those margin boxes then just become a predefined
          special-case of @slot, maybe through a UA stylesheet.
  dauwhe: There have been various syntaxes for this kind of things,
          and @slot seems to be the easiest thing so far.
  glazou: Also they allow footnotes/reference areas.
  dauwhe: Right, extending it beyond the page margin area to do side
          notes, pull quotes, etc. Using Regions to take content
          form the document and placing it somewhere special.

  astearns: Is this *only* for creating paginated views, or is it
            useful for single-page views as well?
  astearns: I'm thinking of wikipedia pages that have multiple slots
            for marginalia and references - seems useful.
  glazou: Yeah, that should be usable in ordinary pages too.
  dauwhe: In Page Template and epub adative layout, these are
          defined inside of an outer template, not in @page.
  dauwhe: We might have both @slot in @page and outside, or some
          alternative that handles both.
  glazou: This is similar to what iBooks and such does.
  glazou: Easy to generate those rules for CSS from those apps.
  glazou: I don't see any technical difficulty with my editor
          vendor's hat on.

GCPM4: Footnotes
----------------

  dauwhe: Next, footnotes.
  dauwhe: If we have a footnote in markup, we can flow it into a
          region...
  glazou: The fact that you have a counter in both footnote and the
          leftover reference is through flow-policy: copy, so it
          gets copied and shows up in both places.
  glazou: But we still need a hyperlink.
  hober: What happens if I call getBoundingClientRect() on something
         with "copy"?
  TabAtkins: The element generates a *ton* of boxes, so it's a
             really big bounding rectangle.

  Bert: [something about links]
  plinss: Bert was talking about a case where the footnote is stored
          somewhere else, and there's just a link to that footnote
          somewhere; Bert wants to replace that with a footnote
          counter and possibly a link to that footnote.
  Bert: So one case is using an existing link and displaying the
        target as a footnote.
  Bert: But in this case [referring to the example] you don't need a
        link. It's UA behavior.
  chrisl: You were just arguing the opposite half an hour ago, about
          CLinks!
  glazou: [provides an example]
  plinss: Bert's point is that if we define them in terms of
          something the UA can understand, the UA can make them
          links via UA magic.
  plinss: I don't disagree that that's possible, but I'd rather
          explain the magic, so people can use it for other things.

  zcorpan: Do these show up in browser history?
  TabAtkins: As long as they have IDs, yeah, it should be normal
             navigation.
  hober: What if they don't have IDs?
  TabAtkins: Then they won't work. You need IDs.
  plh: What if you put this link into some other browser?
  <chrisl> that should work. useless otherwise

  ???: What about :link, :visited?
  Bert: You need markup for that.
  TabAtkins: Nah, no requirement there.
  fantasai: Document languages define what a link is.
  Bert: You need events for pseudo-elements.
  glazou: Yes.
  zcorpan: You can already clink on ::before, etc.

  plh: I don't think we need to expose anything special at the API
       level, besides events, to make generated links.
  plinss: I don't think that the linking behavior should be defined
          in GCPM. So where does it go?
  TabAtkins: There's no existing spec for it, so it goes somewhere
             new.
  plh: And we need to think about its mapping to ARIA.

  dauwhe: Outside of linking, this region stuff gets us at least
          some of the way to footnotes.
  dauwhe: There's still a strange relationship between the footnote
          reference and the footnote itself.
  dauwhe: They need to be on the same page, which is impossible in
          some cases - they need to be able to overflow.
  plinss: In general you want the slot to grow to the point where it
          barely doesn't push its own footnote ref to the next page.
  dauwhe: That's a thorny problem.
  TabAtkins: I think, unfortunately, that that's something we need
             to do footnote-specific; we probably can't generalize.
  dauwhe: I just want to minimize the magic/specialization to what
          needs it.
  SteveZ: There's some generalization possibly here - we have
          invisible markers, maybe some hint that the footnote needs
          to be near the marker, etc.

  dauwhe: It would make my job easier if I could generate content at
          the location the footnote disappeared from, to fill with a
          content.
  TabAtkins: Maybe look at old Content drafts - Hixie defined some
             stuff for that.
  Bert: General problem of footnotes is that the ref is implicit;
        people expect to mark up just the footnote, not what it's a
        footnote *to*.
  glazou: You've seen the flow-policy:copy? Maybe a way to extract
          the element to the footnote section, leaving only the
          outermost node behind (to fill and link).
  glazou: You could use similar rules to generate a footnote index.
  dauwhe: This mechanism allows us to have arbitrary numbers of
          footnotes and position them somewhere else. Probably lets
          us meet the crazy demands.

  [some missing discussion about linking to pages, with some sort of
       selector-in-fragment thing]

  <chrisl> http://example.org/foo.html#selector(some-selector-here)
  hober: That uses something called epub CFI, which lets you
         robustly link into an epub.

  Bert: Another wrinkle - the footnote area needs to conditionally
        generate, so if there are no footnotes, the border doesn't
        show up either.
  dauwhe: Yes, I tried to re-use the required-flow from Page
          Templates for this, so if there wasn't anything flowing in
          it just wouldn't generate.
  astearns: That's what it was for.

Publishing
----------

  glazou: Do we want a WD?
  dauwhe: Don't think it's ready for one yet.
  glazou: I think it is. If the issues are in prose. Just so people
          can talk about it.
  ??: This isn't really just GCPM anymore, though.
  TabAtkins: Maybe call it Books?
  glazou: I don't care about the name, just call it something.
  plinss: I want us to avoid making GCPM garbage-collection.
  plinss: Let's just put them in other appropriate modules, or make
          new ones. If we need a place to store things, we have a
          wiki.

  Bert: I notice these don't just apply to pages. Can we just define
        that the browser is a single page?
  plinss: I agree that we need a better definition of "page", and we
          should stop differentiating between "page behavior" and
          "screen behavior".
  dauwhe: Maybe put the first part here in Regions level 1 or 2?
  glazou: Agree. And the footnotes stuff should go in a Hyperlink
          module, with some notes about how to create footnotes.

  plinss: I wanna explain @page in terms of a generic template
          mechanism.
  plinss: There's no reason you shouldn't be able to add slots of an
          arbitrary <div> or whatever.
  dauwhe: I'd be happy to help edit Page Template. Should I also be
          an editor of Content?
  TabAtkins: Sure; we're not doing much with it right now.

  Bert: Say you had a paper page with a template, you have to define
        what happens with overflow.
  Bert: You can repeat the template on the next page...
  TabAtkins: Page Template has a mechanism for linking slots between
             multiple templates.
  Bert: But you sometimes also need to control which template to use
        based on previous templates, or sometimes based on content.
  * dauwhe http://dev.w3.org/csswg/css-page-template/#selection-from-required-flows
  astearns: Page Template has required-flow, it's to tell if content
            will show up to help decide what template to use. It's a
            first step, but this mechanism can be extended.

Fragmenting the Box Tree API
----------------------------

  dauwhe: Regarding paginated views, interesting discussion happened
          in the break. [something about presentational box tree]
  plinss: The gist is that we need to redefine pagination in terms
          of the box tree. Our current model with multiple viewports
          is kinda broken.
  plinss: So a paginated document is just a series of anonymous
          boxes that content flows into, etc. Need some box-tree
          APIs, which we've talked about before.

  astearns: Would it make sense for that project to take on
            overflow:paged and describe everything in that model?
  plinss: Possibly.
  dauwhe: Are you intending to actually create a spec at this point?
  dauwhe: Or maybe a joint project with TAG?
  plinss: We talked before about just making a box-tree API, as a
          longer-term project.
  dbaron: I'm definitely more interested in work on generic stuff
          like that, than pseudo-elements and at-rules for specific
          solutions.
  plinss: We might be able to define a deep model, but make
          conformance shallow enough that implementations can work
          their way there without having to dive all the way down.
  hober: Hard to tell what's up until I see something.
  plinss: Right. Plan is to deprecate the geometry stuff from DOM,
          and have a way to get from DOM to box tree, and query
          geometry from there. Have events on boxes. Etc.
  dbaron: Ehhhhhhh
  <dbaron> (specifically concerned about having events on boxes)
  <dbaron> (I also said (right after my first comment) that I was
           still concerned about defining box tree API given
           implementation differences)
  plinss: Maybe not all at once. But eventually.

  hober: I think equating these features with a box tree API is not
         necessarily a good idea. At least, it's less clear.
  plinss: I think we can start by defining the model, and very
          gradually decide what to expose.

Paginated Views
---------------

  astearns: Being impatient, I'd rather not tie paginated views to
            this topic. I think it should be informed by that work,
            but should run in parallel.
  plinss: Right. I think it'll run in parallel with everything for
          some time.
  astearns: So Opera is very interested in getting paginated views
            implemented. I'd like to see the group get more
            interested in it.

  hober: Have there been more changes to review?
  astearns: It was slightly defined in GCPM, it's now completely
            undefined.
  <dauwhe> http://dev.w3.org/csswg/css-overflow-3/#paginated-overflow
  dauwhe: The whole section is just issues now.
  florian: Even the little that Opera implemented didn't exactly
           match the specs. There are people whose brain can be
           picked to see how that worked.
  fantasai: There was an idea to use @page to style pages in a
            paginated view; the viewport becomes a special case.
  <zcorpan> http://www.opera.com/docs/specs/presto2.12/paged-overflow/
            might be relevant.

  astearns: dbaron, could you commit to filling in that section?
  dbaron: Maybe. I'd like to have someone else help out too; I think
          my work on T&A is more important.
  astearns: dauwhe, is this another spec you might want to edit?
  astearns: I can help with the API side.
  dauwhe: I can commit to at least digging up what's in Håkon's old
          stuff.
  dbaron: Håkon and I had a thread about that a few months ago.

  plinss: I think we need a better definition of overflow, page
          templates, and update Paged Media to explain everything
          it's doing in terms of those two modules.
  plinss: Is that Paged Media 3? Or 4?
  <zcorpan> http://lists.w3.org/Archives/Public/www-style/2014Jun/0126.html
            - opera feedback on paged media
  fantasai: I'd say it's a few days of work to ready Paged Media for a WD.
Received on Wednesday, 15 October 2014 18:07:17 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:25 UTC