W3C home > Mailing lists > Public > public-digipub-ig@w3.org > April 2016

RE: HTML-Note and bibliographies

From: Bill Kasdorf <bkasdorf@apexcovantage.com>
Date: Mon, 25 Apr 2016 21:03:39 +0000
To: Leonard Rosenthol <lrosenth@adobe.com>, Shane McCarron <shane@spec-ops.io>
CC: "public-digipub-ig@w3.org" <public-digipub-ig@w3.org>
Message-ID: <CY1PR0601MB14227108C90810CEAA3B170EDF620@CY1PR0601MB1422.namprd06.prod.outlook.com>
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).

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? ;)

[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?]

—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<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
Received on Monday, 25 April 2016 21:04:11 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 25 April 2017 10:44:42 UTC