- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 15 Oct 2014 14:06:49 -0400
- 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