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>
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]
> *Sent:* Monday, April 25, 2016 4:27 PM
> *To:* Shane McCarron
> *Cc:* 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>
> *Date: *Monday, April 25, 2016 at 4:11 PM
> *To: *Leonard Rosenthol <lrosenth@adobe.com>
> *Cc: *"public-digipub-ig@w3.org" <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>
> 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>
> *Date: *Monday, April 25, 2016 at 1:07 PM
> *To: *"public-digipub-ig@w3.org" <public-digipub-ig@w3.org>
> *Subject: *HTML-Note and bibliographies
> *Resent-From: *<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