Re: Prioritisation

Deborah,

If the discussion assumes PAGE is a high-level concept - then you are
correct, but I believe - and how I framed my notes (and may have failed) is
that a PAGE is actually just a media-query - it's a defined set of display
styles that are applied to structured content based on the form in which it
is being displayed.

Under that assumption - then it is completely relevant to CSS.  The
"printed page" is then just a media-query abstraction.  What becomes the
relevant CSS question is: What abstractions are needed for the structured
content?

What interactions and states are needed?  what regions are "static"
(header/footer) vs non-static.  Obviously a reading system could take
advantage of "position: absolute/fixed;" for a header/footer element, but
how would that interact with scrolled or flipped chunked content?  regions?
etc.

I think this is all EXTREMELY relevant to CSS because the page is a visual
representation.  Unless I'm mistaken, CSS is the visual representation of
the structured HTML content, no?

-Nick

On Wed, Aug 5, 2015 at 12:13 PM, Deborah Kaplan <
dkaplan@safaribooksonline.com> wrote:

> 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.com
> 232 <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/>
>>
>>
>>
>
>


-- 
- Nick Ruffilo
@NickRuffilo
http://Aerbook.com
http://ZenOfTechnology.com <http://zenoftechnology.com/>