- From: Dael Jackson <daelcss@gmail.com>
- Date: Fri, 11 Sep 2015 14:38:31 -0400
- To: www-style@w3.org
Defining Pagination
-------------------
- dauwhe asked the group how to proceed with pagination since it
was a major priority of digital publishing.
- There wasn't consensus on overflow triggering pagination and
instead was decided that the first step would be a model for
how pagination works.
- There were several different mental models from members of
the group, but it ultimately was decided that the first
problem was to figure out and define the relationship
between the viewport and the doc tree and from that
definition the group could then move forward on explaining
how regions and fragmentation use that relationship to
become paginated view.
- RESOLVED: Create a new module describing connection between
viewport and doc tree and explaining page boxes with
name TBA. plinss, Florian, Rossen are editors.
CSS Priorities from DigiPub
---------------------------
- The group reviewed the document from the DigiPub Interest Group
and had several pieces of feedback:
- There was a desire expressed for the list to be more
concrete proposals and less of a laundry list.
- It was recommended to ask for font-variant instead of
font-feature-settings as it's a better property.
[font-feature-settings was only intended to fill in
the gaps that font-variant hadn't filled, not as a
cheap substitute for font-variant]
- Using the content property on elements received a lot of
interest, but may be difficult for accessibility reasons.
Also there was evidence that browsers had tried it before
and had to walk back the changes due to Web compat.
- It was expressed that mathematical layout will be hard,
particularly due to interaction with font shaping.
- There was interest in the problem of tracking reading
location across devices, but no conclusive proposal.
===== FULL MINUTES BELOW ======
scribe: dael
Defining Pagination
===================
dauwhe: [reads us all a wonderful story that you can read here:
http://epubzero.blogspot.fr/2015/08/the-genesis-of-pagination.html ]
<dauwhe> https://www.w3.org/dpub/IG/wiki/Pagination_Requirements
dauwhe: I'm going to talk about pagination and what we need to do.
dauwhe: As we know there's lots of specs that touch on this and
there have been various attempts to work on them
dauwhe: This is a major priority of the digital publishing
community. We publish content and it's better in a
paginated form.
dauwhe: We think this is a good thing for users and we'd like to
reduce the dissidence between ebook and web reading. We'd
like to have a spec so people can polyfill it.
dauwhe: What is the path forward, what do we need to work on, who
is interested, how much of this is CSS and how much is
Houdini, what do we need to do to keep this going forward
and getting worked on? The whole digital community is
interested.
astearns: One of your topics is what is CSS and what is Houdini.
There shouldn't be that much distinction
hober: Houdini is a wholly-owned subsidiary.
astearns: The Houdini part is the APIs that we need to provide for
when a paginated view happens. When things get
fragmented there need to be APIs for where your content
went, how many pages you have. That's the only Houdini
part.
dauwhe: And dpub has written requirements docs for those APIs.
astearns: That's my take on it. Does anyone else have a different
idea?
SteveZ: One of the major questions in pagination is templates and
how do they get specified. Is it declarative which is CSS
or is it Houdini?
SteveZ: There's an observation that runs through things where
sometimes you don't know how to standardize because you
don't have enough experience. Houdini lets people
experiment and that might be where we are with template.
SteveZ: Trying to do that piece declaratively seems to be a lot
harder to do. The rule for picking which page template you
use is hard in a declarative point of view. That would be
one example where a Houdini interface gave you a set of
content and you can explore that content and pick a page
template.
<leaverou> since when is houdini only about JS?
dauwhe: The thing triggering pagination, do we all agree that's in
that section of the overflow spec?
ChrisL: Yeah, that seems right. Can you think of anywhere else?
astearns: Named flows and regions can do the same thing with
non-declarative bits.
liam: Does it have to be non-declarative?
astearns: The script you need to add or remove regions is the
non-declarative.
liam: Yes. I can imagine a world where one does not need JS for
that.
liam: So the question isn't just what do we have, but where should
we go.
ChrisL: I would clarify to say it's the primary place, but other
things could trigger as well.
SteveZ: I'm not sure I subscribe to that in the sense that it
seems to be pagination is something you do, not so much a
result of overflow. That distinguishes the thing that
begins and follows from I want to put this content into a
set of pages. I don't have to overflow anything.
astearns: I can see the similarity between overflow paged and
scroll. You're putting your content in a large virtual
container. In both cases you're auto-generating a place
and providing some UI to get through the content.
SteveZ: Distinction is in scrolling you have one template that
you're extending. In pagination you have many templates.
The other piece of pagination is the breaking issue and
dividing it into pages.
Florian: Since I became a co-editor of Overflow to work on things
related to this, I think this is something to look into.
Sometimes you want multiple flows going into a page.
There can be an existence of a page more than the amount
of content that's overflowing it.
johanneswilm: So you provide some JS foundations and you hope
someone will try and make examples and you build the
spec based off of those experiences? There's not
that many, there was one implementor in 2012 and
that was me. There is now viviostyle. Is that all?
astearns: Financial Times has their own. New York Times used to
use one.
johanneswilm: Are we getting the feedback back?
dauwhe: Also all the ebook reading systems. iBooks. I get the
sense these aren't the most elegant constructs.
astearns: When we were creating regions I was soliciting feedback.
dauwhe: And we have formatters that say if there's an @page rule
that triggers the pagination.
Bert: I think that overflow is a secondary way of getting
pagination. The primary is based on the templates like
SteveZ said. The last template might be scrolling. The
primary reason for pagination is do I have another region to
go into and in the last one you might want a scroll bar.
Florian: That's what the overflow spec is doing. It's triggered by
overflowing. Do I want more pages or do I want to scroll
once I reach this one. Once you have these pages and
going ahead and creating additional containers is the
point. That doesn't generate the page.
SteveZ: A key distinction is the page is a container separate from
the content. The template says what the container should
look like. There is a pouring notion. The way we've done
multi-col is you can take an element and turn it into
multiple columns, but that takes away from you the ability
to have the first page be one column.
Florian: With pagination you could do this. The first
element/page/thing gets filled, content overflows, you
select the second with a pseudo, and that one you apply
the multi-col. What it doesn't do is if you have two
flows, one English one Chinese and they're supposed to
run parallel.
dauwhe: Or it's a signal we don't have the conceptual model.
SteveZ: Another issue is the page floats. For high quality output
you want to order them. You have two page-wide floats and
two half-page floats, you want to stick those two half
page floats next to each other and that's not easy to do
in a specified way. I don't think we have the ability to
deal with that.
Florian: I think that's a problem, but a different problem. We
have a certain set of page floats, but if it's not layout
smart enough you can go over it in Java.
dauwhe: And to have that implementation experience, it would be
nice to have content.
liam: Sometimes you have to be careful to look at the complex and
the simple. SteveZ- I sent a mail to the list with examples
of page floats including the exact example you mentioned.
But that's not specific to pagination. That happens in
floats.
liam: There's motivations to fix that beyond pagination, I think
it's separate.
dbaron: Slightly different issue, a lot of CSS is very clear about
how UA and user and author preferences interact. One of
the problems with things like @page is that become less
clear. It's clear how @page is intended if you're using
CSS as a typesetting. You and the publisher and the
printer know all the sizes. It's less clear when you have
a developer and you have someone on the other side of the
world.
liam: ChrisL asked why this doesn't exist for screens. One issue
is @page you hard-wire the page size and you don't really
know it.
fantasai: You just say @page { size: auto } and it works.
liam: It's been in the spec, the implementations have improved.
The other thing that mitigates it is the calc() function.
Even if you say page size auto you have a problem.
fantasai: We have margin properties.
liam: I'm oversimplifying, but the things calc was introduced for
are thing in printing.
dauwhe: I'd see huge problems if we have this in the browser and I
could set margin boxes with something flexible enough that
it would work in different screen sizes.
johanneswilm: If you want to make it really great it will take a
lot of time to render. I don't think browsers will
render that. If there's an expectation browsers will
want to put it in this needs to be considered, but
if it's not sufficiently complex we won't have good
books.
dauwhe: What's the next step we can do? It seems like there's not
consensus on overflow triggering pagination.
fantasai: We've got paged media spec, it exists for all its faults.
We got the fragmentation stuff. We have overflow: page
from Opera which at a basic level is straight forward.
You will want to style controls, though.
astearns: Before that we need an API.
fantasai: That's a parallel issue
plinss: We need a model for what boxes will be built before the
API.
Florian: And if regular pagination is explained by fragmentation.
fantasai: The way I see it is that when you're in a paged media
mode you're generating pages, just like 'overflow: paged'
generates. You page rather than scroll and you're
generating page boxes, as many as necessary.
fantasai: Rather than switch pages as in 'overflow: paged' you pick
the next paper.
Florian: Then how do you explain it for pages generated by not
overflowing the root. Like the crop marks and bleed area
when they're in the middle?
fantasai: I imagine overflow: page being a stack of page boxes.
fantasai: We probably want a different mechanism for assigning
styles to that, since @page rules are for the root
element only.
Florian: The first part I agree.
fantasai: If it's a stack of boxes it's just like a scroller and if
the bleed marks are outside that you don't see them
unless we add a property later.
johanneswilm: Isn't this the difference between having all the
content to how many pages you need or the one where
you have a page, put your content, and add another
page and put your content. They're slightly
different models.
fantasai: The model we're going with so far is you generate as
many page boxes as necessary.
dauwhe: Even for page layout programs, I don't see having CSS do
something where you hide your content by default.
fantasai: If you really want to do that, I make a div and give it
500% height, which makes it 5 pages tall, and give it
overflow hidden so that's all I get. But it shouldn't be
the default model. It shouldn't be the default for
overflow: page.
dauwhe: How much needs to be done to get this box model? We kind
of have it in the introduction to CSS display. I hear from
dpub is the box tree 6 months or 6 years?
plinss: It has to fall out from the working group to Houdini.
Florian: If this is a long topic, we need to make time for it.
It's not going to run itself. I think there's consensus
we need progress, but we've had difficulties setting
aside enough time.
astearns: And we've had difficulties getting browsers to express
implementation interest. We've had overflow draft for a
while. If that's the mechanism we should have more
interest.
Florian: I'm partly guilty because what's in overflow isn't
sufficiently specified yet.
astearns: I don't think the main problem is time for theorizing
and specifying. I think it is lack of interest in
spending time on implementing even though we've known
pagination is something CSS should get to. Even though
dpub is breathing down our neck for it.
Florian: I think it's both because...the problem you described is
real, but smaller groups of JS and polyfillers that want
to experiment don't quite have enough.
plinss: Anything polyfills has been DOM hacks, not layout.
tantek: What about howcome's prototypes?
jdaggett: I'm sort of hearing this and seeing similar things in
the next topic. I don't see if there's a place in the
room to talk priorities of implementors, we have to
focus on priorities of specs and not getting tangled in
the prioritization for individual browsers.
dauwhe: I'll have more comment when we're on the priorities
documents.
Florian: What's the point of if browsers won't do it, they're not
the only CSS consumers. If we spend a reasonable time and
flesh out the model it would be good.
ojan: Calling an ereader a browser is fine.
Florian: Desktop browsers haven't shown much interest, but there
are ebook readers that are interested.
dauwhe: Pagination with CSS is probably a billion dollar industry.
They're stuck doing this in non-standard ways.
plinss: I'd like to see the ability for the user to opt-in to
pagination. Either I'm scrolling or I want to be in ebook
mode.
plinss: We need to make sure the model is set up. Sometimes the
author only want paginated, but it should be the also the
flip side.
plinss: It would be nice if the user could select that mode.
plinss: Some browsers are having reader mode.
SteveZ: Does that say overflow: page is not the right way to go?
plinss: It's a way to go.
Florian: It can do both, but I don't know if it's the best way.
SteveZ: Overflow: page seems like a dead end route. It doesn't
seem the obvious way for what plinss suggested.
hober: It is. It's the equivalent. It doesn't do everything, it's
a long way though.
SteveZ: But I'm concerned about getting the whole way.
hober: Let's get somewhere.
SteveZ: You can get somewhere but you can't get the rest.
liam: When howcome showed his footnote draft the problem was you
can't extend to multiple levels of footnote which is common.
That kind of review requires looking at the more complex
picture.
fantasai: What are we trying to solve with overflow: page that we
can't?
SteveZ: Multiple inputs.
dauwhe: I think we could extend overflow with giving a name to a
slot.
plinss: I think that's a bit of a red herring. There's always been
a missing component. There's the box tree and outside that
is the viewport. The route mapping has always been this
fuzzy area. We've never defined that space, especially
when there's crimping the viewport starts acting really
strange. We don't have a coherent model and we need to
define that.
plinss: Once we have that pagination overflow it may make perfect
sense living in that gray space. They'll be in a coherent
interoperable manner.
dauwhe: I agree 100% as I was reading through spec trying to find
the definition of canvas and viewport and it's not there.
dauwhe: What is the relationship between canvas containing block,
viewport etc.?
plinss: And I'll bet every impl is different.
Florian: Back to the problem with example of two parallel
contents, we haven't solved it in non-paginated either.
Once we have a way to do that, then we can pour that in.
We don't have a model, but once we do it may work. We
don't have that piece.
dauwhe: What plinss said I saw the models of scrolling and
pagination as different parts of the same.
Rossen: There's two repeated concepts. One is being able to
fragment content through multiples of fragmented
containers.
Rossen: We've convinced ourselves there's multiple way to do this.
Rossen: We're also trying to define an application model to which
browsers may have to adhere. It's this paginated view. I
want to flip or whatever. It's a lot harded to expect when
can set the same requirements for the browser. This is
going back to the times astearns and I were fighting for
regions, it's give enough primitives in the platform, so
that if people want to do paginated...
Rossen: It's not my job as an implementor to do it, I'm giving you
all the tools.
Rossen: We're going a step further with Houdini, we're saying we
want to pull out even more. We are giving you the box tree
and all that and you can solve it.
Rossen: I think the distinction needs to be made that we can
trigger fragmentation in multiple ways. Not necessarily
the browser level.
Rossen: The print preview, that's what we do. The huge amount of
JS to implement this is really 3 lines to see if there's
overflow and if we want to go to that next page.
Rossen: Going back to how do we trigger pagination, my reservation
here is when you say pagination you're saying I want to
put the browser into some app mode that the browser isn't
built to be.
johanneswilm: I think I agree with a lot of that. If I want to
read NYT in a paginated form I assume they will have
a paginated form. I don't see the advantage of the
browser doing that. The JS polyfills may be the end
product. It still should be spec'ed. That's why I
was asking, are we the only ones trying or are there
other JS apps out there that are trying to consume
content?
johanneswilm: We're a small start up, but you said it was a
billion dollar industry so I'm sure someone is
interested.
plinss: If the NYT want to give someone paginated on their site,
they can build a paginated view, and then inside that have
a little paginated box that users can flip through. But
then when I print that, I only get one page. The problem
is that it's then completely disconnected between what's
going on on the viewport and canvas, if I hit print I'm
only going to get one page. I can't take their app
experience and express that in a paginated viewport. I've
built two things and there's no mapping in between them.
plinss: I'd like to give them something to build that can map
between them.
<fantasai> plinss++
johanneswilm: There are ways to get around that.
plinss: Sure. But I don't want them to have to design for that.
There are UA that will go in the viewport. They've
disconnected their paging experience from the ebooks. I'd
like a coherent model.
SteveZ: When dauwhe brought this up he wanted to know what terms
he can use in pagination. I just heard Rossen say
fragments, plinss say regions. If the regions are changed
is separate, but the concept of a container that has
things poured in is there. What pieces go in what
direction. Also what the container can do to how the
content is presented.
SteveZ: We're at a point that fragments and regions are basic
building blocks.
SteveZ: Is that a constant enough model or what more do you want?
plinss: The regions are giving us the tools, but we don't have the
overall explanation of the model. Once we have that I want
it expressed in all these tools. I want to be using the
same CSS tools everywhere. I want to give the author the
ability to play outside the document and the viewport. If
that's through declarative CSS or what-have-you, I want it
to be there.
Florian: Isn't that tied to using the fragmentation overflow to
what is out there?
plinss: It's not changing the root box mapped to the DOM, it's the
viewport out there.
plinss: @page is trying to describe something in that region
that's not defined.
Rossen: I can only speak for our implementation, but internally
the thing between the viewport and the document or
whatever is there, we also always have a root element
that's private to the platform. It's a div with a style
and it is extremely easy because in our case it's a div
with an overflow and a scrollpage.
Rossen: If you want pagination we can make multiple boxes.
plinss: Are you making new divs?
Rossen: New roots....no.
Florian: In that model it's coherent that rather than having that
on the route you do pagination and overflow.
Rossen: We re-use our regions implementation.
plinss: It sounds like you're doing what I have in mind for
spec'ing. That you're doing it with a div instead of box
is implementation detail. I want to spec that and give the
author the ability to apply styles.
Rossen: We are giving them that ability by prop BG color.
Florian: Explaining the model so that we know the reason @page
works is it's applying to that thing. That makes sense to
me overall. The details need writing.
astearns: Who will write them.
Florian: That's what I signed up for by accident.
SteveZ: Is writing that the first step?
plinss: Sounds like.
plinss: Is this a new spec or an outgrowth of an existing one?
SteveZ: It's easier to do separately.
dauwhe: Sounds like the introduction to CSS Display.
SteveZ: I don't think it is.
SteveZ: It's kind of hidden a bit in 2.1 but we've never extracted
that piece.
Florian: And @page is kind of dealing with it.
plinss: I think we can make it a new doc.
dauwhe: This is starting the make sense. Is this where we talk
about viewport?
dauwhe: This document could maybe talk about the parts of 2.1 that
mention viewport and canvas and would include whatever is
hosting the element.
astearns: It looks like there's two sentences in 2.1
dauwhe: Yes.
Florian: And a bunch of things trying to hook into it.
plinss: Do people agree this is a new spec?
Rossen: Can we start it as an existing and fork if needed? It
sounds like display module is a good start for this work.
plinss: I don't know if what exists there now makes sense.
Florian: If that thing explains pagination, how do we tie it with
overflow that is also explaining pagination?
SteveZ: When we have a model it should be clear how to answer that.
Florian: I'm trying to figure out dependency.
hober: That needs to be written down.
dauwhe: I think we're looking for something that will be the
parent of overflow and @page.
dauwhe: I think hopefully if we start down this path it will
provide a way to say how we talk about this unicorn.
Florian: Either this unicorn object is a fundamental and it has a
bunch of content or what fantasai said earlier that
pagination on overflow explained how that thing worked.
Which explains the other.
SteveZ: My model which I may be wrong is this model describes how
it gets to an external place.
Florian: Okay, and overflow hooks into that to explain how to
overflow.
SteveZ: It tells you what you can find out about the external
structure.
Bert: In the model I have it is close to SteveZ. I think there are
things like regions that are independent of elements. Those
regions have their own properties and define how things
overflow and pagination. @page is a kind of region. All of
those are this external structure. And they have their own
properties including content and overflow.
plinss: So do we have agreement to start a new doc?
Florian: I think we do, but who is going to write?
plinss: I'm willing to edit.
Florian: I'm interested, but don't know if I have the resources.
dauwhe: Interest without knowledge.
Rossen: I can contribute.
SteveZ: I'm happy to read.
Florian: This needs to be tied into the device adaptation doc. I
spent a bunch of time review that with ppk and he pointed
out the same problem.
Rossen: I think we'll end up splitting it into different specs and
tying in the terminology.
dbaron: It's a bit disturbing to have the viewport spec and a
viewport defined elsewhere.
hober: Why don't we defer the name to the editors?
RESOLVED: Create a new module describing connection between
viewport and doc tree and explaining page boxes with
name TBA. plinss, Florian, Rossen are editors.
plinss: Is that a close on pages?
dauwhe: Yes, that feels like progress.
<break=15min>
* fantasai TabAtkins, can I action you to pester that guy who was
unhappy with all the hyphenation properties to send
email expressing his unhappiness?
* TabAtkins Yeah, I just need to find who it was.
<fantasai> ACTION TabAtkins Find unhappy dude at Google who
dislikes hyphenation properties and have him send email
explaining his unhappiness to www-style
<trackbot> Created ACTION-715
CSS Priorities from DigiPub
===========================
<plinss> http://www.w3.org/TR/2015/WD-dpub-css-priorities-20150820/
<dauwhe> Prefer the editor's draft, which is already updated:
http://w3c.github.io/dpub-pagination/priorities.html
Bert: The digipub interest group started this document with
important things for the publishing industry that have a
relation to CSS. At the same time this is only a first WD so
it's not the last word, nor does everything in there
definitely have to do with CSS. It would be good for us to
look through the list and see if they have the right model
in mind.
Bert: I hope this is the first round of the conversation that
leads to a decision of what we should do. There's three
tables in the spec, so it would be easiest to go through
them and make a comment on it.
Bert: You, dauwhe, are the editor.
dauwhe: Thank you for putting this on the agenda. I think the
digipub interest group is chartered to provide a forum to
discuss the requirements of digital publication.
dauwhe: And possibly to communicate with other WG if the open web
platform isn't meeting some of our needs.
dauwhe: This document is an early draft. A list of what are we
missing in our day to day work. If we could change
something to allow us to publish more and better, what
would it be.
dauwhe: The list is 3 categories. The first is features that are
well specified, mature, and implemented in most browsers,
but not everywhere which prevents us from using it. Fill
in these pieces and our life is better. It's not the
responsibility of the WG to force implementation, but the
implementors are in the group so we thought a polite
reminder would be good for this forum.
dauwhe: Next category is things where the spec seems mature but
it's not widely implemented yet. Third is things where
there needs to be fundamental design decisions.
jdaggett: Looking at some of the things in 2.1, I'm sort of
wondering where they are coming from. Are we going down
the list, are you giving an introduction or...?
dauwhe: I don't have a method. Bert wanted to go through the list
to see if these things are in scope and if the WG can do
these things. Some of 2.1 the WG can't do anything. One of
the functions of this document is to say we find these
things important.
jdaggett: OpenType Math Tables seems over the moon.
dauwhe: We have an interesting process. This comes from Peter
Krauzberger and he's looking for anything that can help
him.
astearns: It's not just Peter. He's a spokesperson for all the
publishers that want to produce good math types.
jdaggett: That's a low level feature. I think you want to be more
specific instead of just create a laundry list.
ChrisL: I agree with about that. All the others are CSS, this one
is a low-level feature.
dauwhe: That's valid and useful feedback I can take to dpub.
Perhaps find another context or flush it out.
Font Feature Control
--------------------
jdaggett: One other comment, font-feature-settings is listed and I
think it should be font-variant. It's already
implemented in FF and the Safari is underway as we speak.
ChrisL: But those are two different things.
ChrisL: I understand you're making the point that people should
use font-variant, but these are orthogonal. I don't see
they should remove it.
jdaggett: If they're going to implement, they should emphasize
font-variant instead of font-feature-settings because if
you have font-variant the need for font-feature-settings
goes away.
dauwhe: This seemed like the smallest step that would give us
power.
Florian: So that entry could read as if you can get us just that
we can survive, even if getting the other thing would
remove most of the need.
dauwhe: We're starving and will take crumbs.
fantasai: You don't want people to use font-feature-settings. It's
not a good interface and we would much rather people
advocated for font-variant.
<ChrisL> well, not go away, but be much reduced for common cases.
Its not clear whether they were concerned with the common
cases or the edge cases when adding this to their document
<fantasai> font-feature-settings has bad cascading behavior, uses
font-specific syntax (is not cross-platform or
cross-font).
dauwhe: That's useful information for us.
Hyphenation
-----------
Florian: There's hyphens in your list with high priority. On the
call not too long ago we were talking about features
around hyphen. I was wondering if that discussion is to
be read in a new light in view of this proposal.
dauwhe: Having the ability to allow text to hyphenate at all is
this. The conversation was to detect if it hyphenated and
make design choices.
Florian: Yes. Given that no browser will support every language,
just knowing if they hyphenate is good.
dauwhe: Our needs are more modest. Most of us only publish in one
or two languages. Just having the raw property itself
would be a big step forward for the status quo.
fantasai: Particular localizations will have the dictionary. If
the browser doesn't ship with all the languages it will
probably support it in the localizations of that region,
if the dictionary is at all available to them.
dauwhe: Our prospective isn't similar in that we don't worry about
the edge cases much.
Florian: Or the author and user and UA being independent.
dauwhe: Correct.
<leaverou> re: hyphenation properties, I don't see anything about
maximum length of whitespace. We had huge issues with
that and Antennahouse, I thought something was planned?
astearns: Did you want to go further down the list or open for
questions?
dauwhe: I'm fine for general questions unless Bert did you want to
go through the list?
Bert: My initial idea was go top to bottom, but many of them are
related. So maybe, I don't know.
Bert: Some of these are specific and some are generic so it could
be better distinguished.
Bert: The third table is what I find most interesting.
Generated Content
-----------------
Florian: On the second table, content property on elements, what's
our stance?
tantek: It exists?
Bert: We have an old spec and I want to revive it.
Florian: Is it web compat?
Bert: Why not?
Florian: It's all over the place with people applying it and does
nothing. We'll have paragraphs replaced by dots by people
who didn't do clear fix correctly.
gregwhitworth: I thought this was possible.
dauwhe: It's contentious for a11y. My feelings on this are
changing quickly. I got used to it because it's supported
in Prince and its been kicking around the web for a while.
Some of my use cases involve not having a content property.
I'm agnostic about this.
Florian: My impression is that in addition to this it's also not
web compat. So should we decide that a11y concerns aren't
that bad on this feature, can we do this without breaking
the Web?
liam: They're two separate questions. The a11y question, we have
content and pseudo elements. It's a problem, but not a new
problem. Then the question is there legacy code in style
sheets that would start working and therefore break.
Florian: My impression is there was so much it would break.
astearns: There are ways working around it.
liam: How do we find out?
zcorpan: I recall that we tried and had to take it out. I'll look
it up.
gregwhitworth: I have bugs on this and I thought Chrome did this.
Firefox is inserting the sum of them. Let me try
and pull one up.
Bert: Most of the cases where content property would be used is
things like margin boxes and regions, but it would be useful
to be completely generic.
Florian: I think that's why Opera added and it broke.
SteveZ: So if we do define content to container map and we allow
it to be defined, you could get the same functionality.
Bert: It still requires the content property to get defined.
SteveZ: The container is not an element.
dauwhe: We're planning to do work on generated content spec.
fantasai and I were supposed to work on it and ran out of
time. We started the long process of cleaning.
Florian: The feedback could be that content property is unlikely
to be applied to elements as-is.
fantasai: For the a11y issue we could have slightly different
syntax when applying to an element. The stuff causing a
problem wouldn't be valid on elements. We could do that
with a keyword or required fallback. We have options.
Florian: But just waiting for this won't happen.
gregwhitworth: So Chrome did this in 2012. They've since changed.
<gregwhitworth> So in 2011: Opera, FF passed this test IE/Chrome
did not: http://jsbin.com/wefocufige/edit?html,css,output
esprehn: Can you explain the container you're talking about? I'm
not sure I follow what you want to add content to.
dauwhe: In the document we have essentially book content, where we
may want to replace the content, say we tagged a chapter
number, we may want to replace what was in the manuscript
with a counter. We may want to change the structure there
to do all kinds of designs. We sometimes replace the
content of semi-decorative elements with single characters.
dauwhe: We're making design changes, but we need to apply some
specific font or character to an element. dpub can work on
more use cases given what we need.
esprehn: Shadow DOM supports replacing visual content and we've
been advocating for that to replace content. We've got
questions about multiple levels of outer and inner and
that should be the DOM.
Bert: But that's not tied to the stylesheet. I can only have it on
DOM even if I have multiple stylesheets. My user stylesheet
can override the content property.
esprehn: I question replacing sections of the page with the
stylesheet.
Bert: The example is there's a chapter number and I want to
replace it with some image. I say okay, replace it by the
counter that is defined in the stylesheet. If I have to use
some HTML fragment, where is that defined. It's not in the
stylesheet.
Florian: Shouldn't this be solved by the transformation language
from glazou.
TabAtkins: Or JS.
Florian: It's not very declarative.
dauwhe: It sounds like where I should go and work on use cases
with dpub.
esprehn: That would be great.
Math
----
jdaggett: Mathematical layout is difficult. It would be good to
pull that out and get at what you really want to try and
achieve.
dauwhe: I think even since we've been working over the last few
weeks there have been intense discussions about the future
of math on the web platform. We're trying to figure out
what's the best way forward.
jdaggett: When you're doing math layout you're doing per glyph
layouts and you would have to really go whole hog to
achieve something that would be sane for any normal
person to use.
esprehn: On Chrome we support adding the primitives so you can add
it yourself.
jdaggett: In practice this is one area where you will spend many
years trying to accomplish it.
astearns: So we'll start.
jdaggett: Keep in mind that behdad recently pushed his shaping
engine to 1.0 and he started it 10 years ago.
Line Breaking and Pagination
----------------------------
dauwhe: Moving on to the third category, we put pagination here
but we've talked about that today. A lot of the things
here are related to hyphenation. There's the font metrics
API thing that will be useful for various reasons.
Bert: In the case of hyphenation and line lengths, they're
presented as independent properties. I'd like to see
something where these and some others are tied together so I
don't have to say I want three letters before the hyphen and
I can be more subtle where I try to make this last line 75%
long or try and do something better if that doesn't work.
dauwhe: I've been on the losing end of that a few times.
liam: There's a couple of difficulties. Politically there are
organizations that have style rules that are reflected in
properties like this and if you have an automatic thing it's
hard. They design things have dials that let you fill in
these things for those reasons. Because a design agency has
a specification and it's hard to automate something that
works well.
liam: TeX does a bad job. It does an error message if you do
something bad and the assumption is there's an author to fix
it.
Bert: It gives errors when it can't resolve, but it has an
algorithm before.
liam: But it has very bad worst cases. Maybe it's not as optimal
as TeX, but it's necessary.
Bert: And you say the programs are made that way because the style
guides. It's a chicken and egg thing.
dauwhe: Much of our progress comes from waiting on the old guard
who insists on these things to retire.
tantek: Do you have a screenshot of the error messages?
dbaron: Find a file for an academic file in TeX and you'll find a
lot of them.
liam: I've seen it have two words in an entire line because that
works out "less bad".
dauwhe: Any other comments on this before we move on? I know
there's a lot of work to do.
dbaron: There's a lot of material in the pagination section.
dauwhe: Yes there is.
tantek: It's a good summary. Each line is deep.
jdaggett: One other comment. You have text-align character-based.
I sort of pushed back on this feature. I think you need
to maybe think about how you can come up with a way to
have alignment that's not based on having the text align
property.
dauwhe: We need the result, we don't have an attachment to how.
Since it has existed and existed in CSS 4 Text, we aren't
aware of alternate designs.
jdaggett: Maybe a feature in grid that says align with this grid
line, for example.
dauwhe: That's useful. I sort of don't have that information in
dpub isolation.
Indexing
--------
TabAtkins: I have a small question. I've never seen merge
sequential page numbers. How is that to work?
dauwhe: FO has this and there are extensions in AH when you're
generating indexes.
TabAtkins: The example is clear. Is this operating on text and
assuming it's comma separated numbers?
dauwhe: Yes.
tantek: Is that English specific or have you seen across multiple
languages?
SteveZ: I don't remember.
liam: I sent a proposal a few weeks ago to handle this in indexing.
How common is it, you'll find it in almost every textbook
in the west.
TabAtkins: The display is clear and obvious.
liam: How it comes from markup, each of these numbers will have a
number in HTML that's pointing to the definition or the
discussion or a figure. Typically you have definitions,
references, and illustrations. References are the ones you
cut out. If you have references and illustrations they'll be
repeated. So you collapse based on classes.
TabAtkins: It sounds like this is an aspect of a higher level
index generating feature. So by itself it doesn't make
any sense.
dauwhe: Yes.
TabAtkins: The spec just has a propdef and an example.
liam: I have a detailed proposal I can send. I need to review it.
dauwhe: I'll re-write. There's a sense of generating content and
there are a lot of pieces to that. I have the weeds, but
not the trees and houses right now.
Location Identification
-----------------------
tantek: How adaptive or responsive are the pieces of published
content. Across different screens and such.
dauwhe: The industry as a whole is moving to the point. Digital
reading is moving across a variety of screen sizes. The
industry is moving in a direction where we need to design
content for a wide range of situations.
tantek: I'm concerned about the amount of detail in the page being
in CSS it seems that once you enter a publication on one
device you're expected to finish there where more and more
people are reading across multiple places. If all your
pagination is done magically from CSS you lose that.
SteveZ: Character number works fine. You're absolutely correct
that people are reading more in different places and where
you were is kept in the cloud.
tantek: That's what we use URLs for.
SteveZ: There's a place not on either device.
tantek: That's a bias to centralization.
johanneswilm: Its got to be something people can remember. People
used to remember a page number, but a paragraph
number is too much but also going to their offline
device we can't do a URL.
tantek: Page numbers are broken.
johanneswilm: But unit needs to be what some person use.
Florian: Paragraph numbers should work across.
johanneswilm: But can they remember. Someone needs to experiment.
dauwhe: And there's independent location numbers. It sounds like
we're starting to talk about annotations with some kind of
bookmark.
liam: And web annotations is working on that. The example doesn't
make clear, but the page numbers won't be in the document,
they come from following the link and what page number did
this occur on in this rendering by following the link.
That's a separate issue to annotation.
tantek: I think it's the same issue, it's part of the reading
experience. And second that layer is something that people
are trying to figure out. If we try and solve all these
pagination problems we might put ourselves into a corner.
Without figuring that out you won't get presentation right.
Florian: What it's going toward is these number schemes are
logical not physical. Character offset doesn't work, but
you can do one tick mark every 1000 unicode characters.
tantek: There's great ideas, no one is shipping them.
liam: Virtually all people are remembering page numbers.
astearns: Some devices it's taking it portrait to landscape.
SteveZ: There's a different problem between people remembering and
machines remembering. Machines can remember in a different
way. Are you trying to give a reference for the people or
the machines? Machines remember fine.
tantek: Not across implementations.
SteveZ: True, there is no standard, but in principal it's easier
to solve.
tantek: People share urls all the time. I don't see the
distinction.
SteveZ: That's not a problem we need to solve.
tantek: Not this working group. But without that being figured out
to come degree, the deep dive on pagination may produce
something broken.
SteveZ: You don't want to use the presentational based for the
human or the machine.
SteveZ: Is epub talking about standardizing bookmarks.
hober: yes, it's called epub cfi.
dauwhe: We have lots to do here and lots to consider so let's move
on.
<zcorpan> https://gist.github.com/zcorpan/2c2b3114ddd636515b95
httparchive results for 'content' without :before/:after
(1877 matches out of.... 1,182,701 text/css files)
Received on Friday, 11 September 2015 18:39:29 UTC