Re: [dpub identifiers] Please review updated Identifiers TF wiki

The name attribute on <a> is deprecated now. To quote from the HTML5 spec:

If the a element has an href attribute, then it represents a hyperlink (a hypertext anchor) labeled by its contents.

If the a element has no href attribute, then the element represents a placeholder for where a link might otherwise have been placed, if it had been relevant, consisting of just the element's contents.


From: Nick Ruffilo 
Sent: Wednesday, April 08, 2015 2:25 PM
To: Matt Garrish 
Cc: Bill Kasdorf ; Dave Cramer ; AUDRAIN LUC ; Ivan Herman ; Stein, Ayla ; Thierry Michel ; W3C Digital Publishing IG 
Subject: Re: [dpub identifiers] Please review updated Identifiers TF wiki

Isn't the <a> supposed to be an anchor and not a link?  And <a> with a href="" is clearly a link, but otherwise, couldn't an anchor point be a logical generic grouping point. 

In the early days of web development, that is exactly how I utilized it:

<a href="#gohere">Go there</a>


<a id="gohere" name="gohere"/> 
<h1>This is where I want to be</h1>


There is probably a better way to do this, but I would argue that <a> - unless it has been re-defined to mean link and not anchor (which is extremely possible, I've still to read MUCH of the w3c docs) it would fit.

-Nick



On Wed, Apr 8, 2015 at 2:04 PM, Matt Garrish <matt.garrish@bell.net> wrote:

  A few points:
    a.. epub uses the epub:type value “pagebreak” to identify the elements (the id name isn’t the indicator) 
    b.. epub also requires @title for a human-readable value (for announcement by AT) 
    c.. the use of <a> for pagebreaks isn’t ideal. A page break not a link to anywhere and never will be. A span is more typical.
  I’d also hate to think we need more markers in digital. CFIs, while unwieldy to write, at least go in the right direction in getting away from reliance on the presence of IDs + empty elements. They can also represent ranges better than having to insert two markers, or whatever ugliness that takes.

  ID-based markers are useful in the print/digital lookup scenario noted, and they’ll have life until a better/simpler method of identifying locations comes along, but they’re still god-awful things.

  You’d think in a digital world we could pull out/identify/highlight any passage of text we want, not be as functionally useless to readers as page numbers. But here we are...

  Matt

  From: Bill Kasdorf 
  Sent: Wednesday, April 08, 2015 1:32 PM
  To: Nick Ruffilo ; Dave Cramer 
  Cc: AUDRAIN LUC ; Ivan Herman ; Stein, Ayla ; Thierry Michel ; W3C Digital Publishing IG 
  Subject: RE: [dpub identifiers] Please review updated Identifiers TF wiki

  Precisely! Thanks.



  When people respond by saying, wrt pointing just to the start of the print page on which the thing you really mean occurs (the thing the index entry means, the thing the cross reference is referencing, etc.), "what the heck good is that?", I point out that that is precisely all that those things have ever done in print. J They just say "somewhere between this point, where page 53 begins, and the next such milestone marker, which says where page 54 begins . . . somewhere between those two markers is the thing I'm trying to direct your attention to." So using them is regrettably no better, but at least no worse, than what they've always done.



  --Bill K



  From: Nick Ruffilo [mailto:nickruffilo@gmail.com] 
  Sent: Wednesday, April 08, 2015 1:25 PM
  To: Dave Cramer
  Cc: AUDRAIN LUC; Ivan Herman; Bill Kasdorf; Stein, Ayla; Thierry Michel; W3C Digital Publishing IG
  Subject: Re: [dpub identifiers] Please review updated Identifiers TF wiki



  My apologies if this has been asked before, but is there a generic "milestone" type ID?  Ultimately that's what a page-number is.  The same way a section heading, or chapter is a chunk identifier, a page is ALSO a chunk identifier.  The fact that the context is related to a concept foreign to screens (or at least, difficult to understand when it comes to screens) if you think of it as a "physical_page_number" as opposed to just "page_number" the conceptual chunk because significantly clearer and more meaningful.



  If this doesn't make sense, let me know and I'll try to word it elsewise.



  -Nick



  On Wed, Apr 8, 2015 at 12:54 PM, Dave Cramer <dauwhe@gmail.com> wrote:

  On Wed, Apr 8, 2015 at 12:41 PM, AUDRAIN LUC <LAUDRAIN@hachette-livre.fr> wrote:


    In EPUB3 files, HTML content is tagged with empty anchors like :
    "Ils n¹en veulent pas, ils n¹en <a id="page_182"/>veulent pas, elle lâche
    dans un soupir en attrapant encore une lettre."

    This means that a new paper page starts at word « veulent ».

    In parallel, the EPUB3 nav document contains an ordered list of navigation
    points in a <nav epub:type="page-list »> element :
    <li>
       <a href="chap22.html#page_182">Page 182</a>
                   </li>
    Then the label of this paper page 182 is « Page 182 ».


    In term of worflow, by good practice, we produced a new EPUB file as soon
    as text corrections have been inserted in the reprint book.





  In EPUB3, there's metadata that should indicate which print edition the pagination information is taken from [1]:



<dc:source id="src-id">urn:isbn:9780375704024</dc:source>    <meta refines="#src-id" property="identifier-type" scheme="onix:codelist5">15</meta> <meta refines="#src-id" property="source-of">pagination</meta>



  Dave



  [1] http://www.idpf.org/epub/301/spec/epub-publications.html#sec-opf-dcsource 









  -- 

  - Nick Ruffilo

  @NickRuffilo

  http://Aerbook.com

  http://ZenOfTechnology.com







-- 

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