RE: HTML-Note and bibliographies

All good answers—thanks!

The @role work is definitely helpful. And I was not aware of @kind; thanks for calling it to my attention.

Guess I should read your draft spec before making more comments, huh? ;)

And apologies for bringing up edge cases. They were indeed edgy. When I characterized some of them as "publishers will want to . . ." it was in recognition of the fact that publishers have a tendency to cling to their print page-based practices (hence the asterisk / dagger / double dagger example, which is actually very traditional). Many are coming around to realize that in a lot of cases what the web can do is actually better.

One other comment: in addition to academic papers, another heavy user of multiple simultaneous systems of notes is legal publishing.

--Bill

From: Shane McCarron [mailto:shane@spec-ops.io]
Sent: Monday, April 25, 2016 6:22 PM
To: Bill Kasdorf
Cc: Leonard Rosenthol; public-digipub-ig@w3.org
Subject: Re: HTML-Note and bibliographies

First - I have updated the spec at [1] to reflect the value of "none" handling as I envisioned it.  Happy to evolve that.


[1] https://spec-ops.github.io/html-note/


Some comments inline:

On Mon, Apr 25, 2016 at 4:03 PM, Bill Kasdorf <bkasdorf@apexcovantage.com<mailto:bkasdorf@apexcovantage.com>> wrote:
Personally I would prefer the ability to make a more semantic distinction between types of notes in a publication; it's about the nature of the note rather than whether it is numbered or not, or with what type of number. I can see publishers just resorting to @class for that (especially if ARIA doesn't supply sufficient distinctions in the semantics, which it currently doesn't).

Well - we already (at your request) have @role to distinguish between types of notes.  This draft spec references those role vales.  This draft spec also suggests that we could use @kind as a way of distinguishing the style of note.  This would be more semantically meaningful than @class but would still allow for styling (CSS selectors can do things based upon the value of other attributes).



Actually, the way most publishers would think of this, though, it is related to position, which is a rendering issue—e.g., footnote, endnote, margin note, so using @class to convey that rendering distinction might be reasonable after all. BTW limiting @type to the options we use in <ol> is going to be a problem because publishers will want to specify glyphs like *, †, ‡, etc. (also arguably a rendering issue, or just part of the content, in which case your "none" strategy would work). And to make that even more fun, the use of that progression of glyphs tends to be page-specific (starting over with * for each new page), so there pagination raises its [ahem] head again. But I guess that's for the CSS folks to figure out, right? ;)

I wouldn't object to extending the family of supported "types" if people want to propose that.  I took advantage of type because it felt natural for most classes of notes.  Obviously that was a bit naive.  The changes I made today would permit the use of odd symbols as the "title" of a note, which would then be displayed instead of their ordinal number.  I could also see allowing the definition of a custom ordered collection that would then be used automatically...  but now we are getting into very complex edge cases.  Resetting the counter per page...  it would work right now if each "page" were a "group".  But a mutation event (page resize) would suddenly become VERY expensive.


[Related question re @type: what happens in non-latin languages that don't use 1 or a? Are browsers smart enough to implement those @type values appropriately for a designated language?]

No.  Nor are they meant to be.  "a" and "A" are explicitly the Latin alphabet.  There is no support for an ordered list that uses non-Latin characters.


—Bill Kasdorf

From: Leonard Rosenthol [mailto:lrosenth@adobe.com<mailto:lrosenth@adobe.com>]
Sent: Monday, April 25, 2016 4:27 PM
To: Shane McCarron
Cc: public-digipub-ig@w3.org<mailto:public-digipub-ig@w3.org>

Subject: Re: HTML-Note and bibliographies

Yes, but @type means different things on different objects.  Look at @type on <ol> vs. @type on <input>.  But you want this to match a list, since you see a group of notes as a list.   But then that makes me wonder if something like note-role (ala aria-role) on an <ol/ul> wouldn’t be better than a whole new element type.

But yes. type=“none” would  be fine if it isn’t a list type.

Leonard

From: Shane McCarron <shane@spec-ops.io<mailto:shane@spec-ops.io>>
Date: Monday, April 25, 2016 at 4:11 PM
To: Leonard Rosenthol <lrosenth@adobe.com<mailto:lrosenth@adobe.com>>
Cc: "public-digipub-ig@w3.org<mailto:public-digipub-ig@w3.org>" <public-digipub-ig@w3.org<mailto:public-digipub-ig@w3.org>>
Subject: Re: HTML-Note and bibliographies

@type already has meaning in HTML and having its meaning be wildly different on another element would violate the principle of least surprise.  But I do like the idea of another value.  It does not have to be a single character; although that would make it more consistent with the other defined values.  How about type="none" when the type of a note should not affect its display value?

Also, no real reason that the title attribute of any note could not be included in its display value if it has one.  So, for example

<note type="1" title="My Note" id="note1">Some text for my note</note>
<note type="none" title="My Other Note" id="note2">The text for my other note</note>

When referenced as

<p>Some content <noteref note="note1"/> some additional content <noteref note="note2"/> with more content after</p>

Could result in a display like:

Some content 1. My Note some additional content My Other Note

Or whatever.  NOTE: The styling above is NOT what is being proposed.  But it is hard to do markup styling in email.


On Mon, Apr 25, 2016 at 12:58 PM, Leonard Rosenthol <lrosenth@adobe.com<mailto:lrosenth@adobe.com>> wrote:
Not a big fan of “empty” having a meaning.

Why not change type to something else – like list-type?   And then use type for footnote, endnote, biblio, etc.  This would be the semantic types (ala aria-role) while you still have group, which points to the specific group of notes (at least that was how I read it).

Leonard

From: Shane McCarron <shane@spec-ops.io<mailto:shane@spec-ops.io>>
Date: Monday, April 25, 2016 at 1:07 PM
To: "public-digipub-ig@w3.org<mailto:public-digipub-ig@w3.org>" <public-digipub-ig@w3.org<mailto:public-digipub-ig@w3.org>>
Subject: HTML-Note and bibliographies
Resent-From: <public-digipub-ig@w3.org<mailto:public-digipub-ig@w3.org>>
Resent-Date: Monday, April 25, 2016 at 1:08 PM

There was a question in the meeting today about whether a bibliography could be supported via this spec.  My answer was that it could.  I was wrong because:

  *   A "note" always has a "type"
  *   A "type" maps to the display value type ala the HTML "ol" element; i, I, 1, a, or A [1]
  *   A "note" always has a "value" that is a number (just like the HTML "ol" element
But I like the *idea* of being able to do bibliographic references using the same mechanism.  I can envision supporting this by changing the model such that:

  *   If "type" is empty for a note, then prefer its title attribute for display value
  *   If there is no title attribute or the contents are empty, then use its "value" in decimal form for the display value
Does this sound okay?

[1] http://spec-ops.github.io/html-note/index.html#note-types


--
Shane McCarron
Projects Manager, Spec-Ops



--
Shane McCarron
Projects Manager, Spec-Ops



--
Shane McCarron
Projects Manager, Spec-Ops