Re: Prioritisation

This discussion is all quite interesting, and a good one to have, but I
just want to clarify -- the way pages and references are being discussed
here are more relevant to the meaning of "pages" which is not part of the
CSS prioritization document under the original discussion. Unless I am
misunderstanding again! In which case maybe we should change the subject
line. :-)

On Wed, Aug 5, 2015 at 11:21 AM, Bill Kasdorf <bkasdorf@apexcovantage.com232
<bkasdorf@apexcovantage.com>> wrote:

> All excellent points, Nick—thanks!
>
>
>
> I particularly like the "scrolling" vs. "flipping" distinction. I will
> steal that!
>
>
>
> --Bill
>
>
>
> *From:* Nick Ruffilo [mailto:nickruffilo@gmail.com233
> <nickruffilo@gmail.com>]
> *Sent:* Wednesday, August 05, 2015 11:11 AM
> *To:* Bill Kasdorf
> *Cc:* Leonard Rosenthol; Ivan Herman; Kaveh Bazargan; Johannes Wilm; Dave
> Cramer; W3C Digital Publishing Discussion list; Matthew Hardy
> *Subject:* Re: Prioritisation
>
>
>
> Sorry for the late comments, I struggled to find time to sit down and read
> through everyone's great discussion.  Since there are a lot of great gems
> here, I wanted to mainly summarize, but also offer some of my own
> commentary.
>
>
>
> *Pages/Pagination*
>
> Some of the ways that the "page" concept has been approached is a
> simulacrum to the physical book - but I think the abstract goes a whole
> step farther.  Keep in mind that in the trade world, you can have a
> paperback and hardcover of the SAME content that have different "page"
> breakdowns.  Long before CSS, publishers were making use of media-queries
> to structure content.  The page is the way in which content is optimally
> laid out for the medium on which it is being displayed.
>
>
>
> We could even call the "page" the Display-style of structured content for
> a given medium.  From this perspective, we account for some content being
> "scrolling" and some being "flipped" (what some call paginated - but I'm
> trying to avoid using the overloaded word).  Not only are device SIZES
> taken into account, but also device capabilities.  Scrolling on a non-touch
> non-mouse device might be unreasonable.  And - in the future when there are
> new input devices, it would be useful to have a spec that took that into
> account.
>
>
>
> *Content Placement Markers*
>
> There is a clear need - at the moment - for markers denoting physical
> pages for the needs of accessibility - but as noted in the wonderful
> comments here, what we really need is just a way to point to a specific
> point in the text.  As long as we have a good location identifier of sorts,
> then we can solve this problem and it becomes an issue of authors/authoring
> tools to add these links.
>
>
>
> *Fixed Layout*
>
> Given the above definition of the Page/Pagination - fixed layout becomes
> just another render option.  Take a cookbook.  A publisher may decide to
> have a "recipe" template that shows a picture on the left, ingredients on
> the right, and a description below - all absolutely positioned on the
> canvas.  They could define this layout for devices that are 1024x768 pixels
> or more.  But, they could also define a layout for small devices that are
> reflowable - show an image, ingredients below, then instructions.  To have
> an entirely different package or content form for fixed layout is
> completely absurd (and I should know, as I've created an authoring tool
> solely FOR fixed-layout content).
>
>
>
> *Thinking abstract about structured content*
>
> In the ideal - and I do believe many publishers think about things like
> this - is to think about things in terms of content.  The display of the
> content is part of productization, but it is different for different
> mediums (hardcover, paperback, ebook, webook, etc.)  I'm not sure
> publishers are masters-of-the-web and know exactly what is best for them,
> and that is where we have the opportunity to - given our knowledge of the
> web and CSS - provide a guideline for how content should be structured to
> maximize layout on multiple devices while not losing accessibility.  I
> believe this CAN be achieved.
>
>
>
> I hope this makes sense - I was up late last night....
>
>
>
> -Nick
>
>
>
> On Wed, Aug 5, 2015 at 10:52 AM, Bill Kasdorf <bkasdorf@apexcovantage.com
> 234 <bkasdorf@apexcovantage.com>> wrote:
>
> Good point! Thanks for the reminder; that's an aspect I often forget to
> mention.
>
> One related comment: the motivation between those author-driven page
> breaks is usually relationship/association/containment-driven: "keep this
> with that," "the reader/user/student needs to see this, that, and this
> other thing at the same time," etc.
>
> JATS/BITS, the dominant XML model in the scholarly publishing world, has a
> pair of <milestone> elements for precisely that purpose. Every <milestone>
> has a @rationale attribute for saying what it's for, and there are actually
> two such elements, <milestone-start/> and <milestone-end/>, empty marker
> elements that enable getting around the well-formedness barrier often
> encountered in this context, where the starting and ending points are at
> arbitrary locations that don't necessarily align with the logical structure
> of the document. Very useful.
>
> Thanks again for mentioning the author-driven breaks!
>
> --Bill K
>
>
> -----Original Message-----
> From: Leonard Rosenthol [mailto:lrosenth@adobe.com235 <lrosenth@adobe.com>
> ]
> Sent: Wednesday, August 05, 2015 10:15 AM
> To: Bill Kasdorf; Ivan Herman; Kaveh Bazargan
> Cc: Johannes Wilm; Dave Cramer; W3C Digital Publishing Discussion list;
> Matthew Hardy
> Subject: Re: Prioritisation
>
> Bill, as with various times in this thread, I completely agree with you
> concerning references into content.
>
> However, I think there is a part of this that is being overlooked and is
> quite important.  Author-forced page breaks due to (usually but not always)
> changes in some semantic element.  In a book, this would be chapter breaks
> (so a new chapter starts at the top of a new page), but in a magazine it
> could be an article, or before tables in a scientific paper or …
>  Fortunately, there is work being done in this area in CSS.  Unfortunately,
> there is zero support amongst the various UA’s to support it.
>
> Leonard
>
>
>
>
>
> On 8/5/15, 10:00 AM, "Bill Kasdorf" <bkasdorf@apexcovantage.com236
> <bkasdorf@apexcovantage.com>> wrote:
>
> >To be clear, since I've long been an advocate of page markers: I view
> them as necessary _at the present time_ but a blunt and arbitrary
> instrument.
> >
> >I would even go so far (perhaps surprising, coming from me) to call them
> brain-dead. The reason is that they have absolutely no relationship to the
> inherent structure and content of the document. They just mark where pages
> happened to break, in a particular rendering, which is based on a designer
> having decided on a certain complement of specifications (page size,
> margins, font size, leading, spacing, etc.) that resulted in a certain
> amount of content fitting on a given page, having started at an arbitrary
> point based on what happened to fit on the previous page. That's all they
> are. But we need the dumb things.
> >
> >Nobody, certainly not me, would argue that this is the best way to embed
> reference points in a document. In fact the activity that I am nominally in
> charge of on the W3C DPUB IG (nominally because I completely depend on Ivan
> for the heavy lifting brain work and knowledge base) involves looking at
> how to identify fragments within a document, _without_ having to embed
> reference points at all. (Sidenote: this fragment identification actually
> requires two locations, either explicit or implied. Mostly implied, because
> if you can reference the actual structure of the document, then what you
> are really doing is pointing at the starting location of the fragment, the
> ending location of which is typically provided by markup, e.g. the end of a
> <section> or <p> or <span>. But you also have to be able to define
> fragments that aren't neatly aligned with the document structure--either
> because they're smaller than the markup delineates or because they overlap
> the structural components of the document. That's where the fun starts.)
> >
> >But I digress. The point is that OF COURSE it is better for the reference
> points in the document to be based, at least as a foundation, on the
> document structure, down to the paragraph level and any phrase-level markup
> that paragraphs might contain. Duh!
> >
> >The reality of this particular time in history, however, is that there
> are still too many situations where the reference to the authoritative
> paginated version is still relied upon (back-of-the-book indexes, scholarly
> citations, cross references, teachers saying "turn to page 53," etc.). So
> we are stuck with our brain-dead page markers. Would we like something
> better? You bet! We're working on that. But in the meantime we still have
> to have those damn page break markers. It's called the real world.
> >
> >--Bill K
> >
> >-----Original Message-----
> >From: Ivan Herman [mailto:ivan@w3.org237 <ivan@w3.org>]
> >Sent: Wednesday, August 05, 2015 5:58 AM
> >To: Kaveh Bazargan
> >Cc: Leonard Rosenthol; Johannes Wilm; Bill Kasdorf; Dave Cramer; W3C
> Digital Publishing Discussion list; Matthew Hardy
> >Subject: Re: Prioritisation
> >
> >
> >> On 05 Aug 2015, at 11:45 , Kaveh Bazargan <
> kaveh@rivervalleytechnologies.com238 <kaveh@rivervalleytechnologies.com>>
> wrote:
> >>
> >>
> >>
> >> On 5 August 2015 at 10:36, Ivan Herman <ivan@w3.org239 <ivan@w3.org>>
> wrote:
> >> Leonard,
> >>
> >> > On 04 Aug 2015, at 21:38 , Leonard Rosenthol <lrosenth@adobe.com240
> <lrosenth@adobe.com>> wrote:
> >> >
> >> > With the focus here on terminology, I think that we also need to be
> careful about what the definition of a “page” is in this context.
> >> >
> >> > In reading over the various messages here, I see (at least) three
> different definitions.
> >> >
> >> > 1 – The content that fits on the device’s screen/output without
> requiring any scrolling.
> >> > 2 – The content that maps to a semantic concept in the publication
> (eg. Index, chapter, article, etc.) and may require scrolling
> >> > 3 – The content that maps to the printed or fixed layout
> representation.
> >> >
> >>
> >> I like this differentiation, and I would think that #2 is indeed very
> important but we may want to, eventually, completely dissociate it from the
> concept of paging.
> >>
> >> My understanding is that publishers, these days, put some sort of a
> page mark into the digital output (in the form of an invisible element, of
> a metadata, etc.). The purpose of this is to be able to *link* (either
> conceptually or through real hyperlinks) into the document. It is obviously
> important for various use cases that came up in this thread already (and
> others) like academic reference or classroom usage. But, just as you say,
> handling these may require scrolling and that because the concept of these
> anchors are, actually, orthogonal to display, ie, pages in terms of #1 and
> #3.
> >>
> >> I think there is an interesting discussion to have on where anchors
> should be put, what is the granularity of those, can (in future) some sort
> of a robust anchoring approach take over the need for these anchors, etc.
> It is largely a usability issue, but I think it is better if we separate it
> from the concept of pagination…
> >>
> >> [...]
> >>
> >> I think we would make progress so much faster if we could refer to
> chunks of information (e.g. paragraphs, as lawyers do now) rather than the
> 100s of years old physical page model, which is a really too big a target
> anyway. But the publishing industry is not exactly forward looking, so I
> guess we'll be stuck for a few more decades with having physical pages as
> the "version of record". :-(
> >
> >Let us be optimistic!:-)
> >
> >Whether paragraphs are the right chunks, or sections, or something else:
> I really do not know. Actually… there may not be a universal answer: what
> is necessary for legal documents (and which would probably work well for,
> say, scholarly publishing, eg, in humanities, where page references are
> ubiquitous) may be an overkill for novels. (Think of the number of
> references you would have in the "War and Peace" :-)
> >
> >But yes, putting markers (and/or providing means to links) into chunks of
> information is the right abstraction.
> >
> >Ivan
> >
> >
> >>
> >>
> >> --
> >> Kaveh Bazargan
> >> Director
> >> River Valley Technologies
> >> @kaveh1000
> >> +44 7771 824 111241 <%2B44%207771%20824%20111>
> >> www.rivervalleytechnologies.com242
> <http://www.rivervalleytechnologies.com>
> >> www.bazargan.org243 <http://www.bazargan.org>
> >
> >
> >----
> >Ivan Herman, W3C
> >Digital Publishing Activity Lead
> >Home: http://www.w3.org/People/Ivan/244 <http://www.w3.org/People/Ivan/>
> >mobile: +31-641044153245 <%2B31-641044153>
> >ORCID ID: http://orcid.org/0000-0003-0782-2704246
> <http://orcid.org/0000-0003-0782-2704>
> >
> >
> >
> >
>
>
>
>
>
> --
>
> - Nick Ruffilo
>
> @NickRuffilo
>
> http://Aerbook.com247 <http://Aerbook.com>
>
> http://ZenOfTechnology.com248 <http://zenoftechnology.com/>
>
>
>