W3C home > Mailing lists > Public > www-style@w3.org > September 2015

[CSSWG] Minutes Paris F2F 2015-08-26 Part III: Defining Pagination, CSS Priorities from DigiPub [css-page-template] [dpub-css-priorities]

From: Dael Jackson <daelcss@gmail.com>
Date: Fri, 11 Sep 2015 14:38:31 -0400
Message-ID: <CADhPm3svoXPu9sQyAN5FOE6=zCveA-M=qgM_rj-W+nnggGkRUQ@mail.gmail.com>
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

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