- From: Robert Burns <rob@robburns.com>
- Date: Wed, 1 Aug 2007 14:54:24 -0500
- To: HTML WG <public-html@w3.org>
- Cc: wai-xtech@w3.org, "Gregory J. Rosmaita" <oedipus@hicom.net>
Hi Gregory,
On Aug 1, 2007, at 11:02 AM, Gregory J. Rosmaita wrote:
> this is a bit of re-thinking of the issues i've raised on-list about
> deprecating Q and BLOCKQUOTE in favor of a single QUOTE element,
> summarized at:
>
> <http://esw.w3.org/topic/HTML/MuchAdoAboutQ>
>
> there is also a comprehensive review of Q, QUOTE, and BLOCKQUOTE in
> HTML5
> by robert burns:
> <http://lists.w3.org/Archives/Public/public-html/2007Jul/0915.html>
I have actually been meaning to update that detailed review of Q,
QUOTE and BLOCKQUOTE to address the other issues/problem statements/
use-cases raised in the Wiki page you started. In many ways I think
of quotations and citations as in need of rounding-out. Like some of
the other features of HTML4 they're just not quite complete enough to
make them really useful. By adding a little bit to HTML5 I think we
can make this features very powerful for authors and users alike.
> =============================================================
> Additional Alternate Attribute Set for a Single Quote Element
> =============================================================
>
> 1. @type - defines the type of quotation:
>
> * type="inline"
> * type="nested"
> * type="block"
>
> these type attributes should determine how a QUOTE is rendered:
>
> * inline, embedded in surrounding non-quoted text;
> * nested, a way of including a QUOTE that includes a QUOTE;
> * block, render contents of the QUOTE element as a block element
If this is addressing the same use-case I'm thinking about I think
such attributes are unnecessary. If I understand correctly, you're
trying to provide a single semantic element for quotations that can
be presented appropriately depending on it's content model. In the
proposals associated with my review of section 3.12, I introduced
some DOM attributes and methods to help UAs query the state of a
quotation. These are intended to accomplish the same goal. These APIs
could combine with CSS pseudo-classes to allow the selection of
quotation elements depending on their content model; and it would
accomplish that without the need for author intervention. Whenever a
quotation contains block-level or structural-inline-level elements or
whenever the quotation contains nested quotations, the state of the
element's contents are all that are necessary to determine into which
of the three types you listed. We shouldn't need to require an author
to add a type element to the quotation. Simply by populating the
quotation element with contents will determine the type of quotation.
This means we would need to change some of the UA conformance
criteria to make this a possibility for future web content. In the
meantime we'll still need to maintain Q and BLOCKQUOTE.
Also I think this would work well with the QUOTE element I introduced
(and as the name you introduced too). This QUOTE element as I
introduced it adds support for IE style quotations that some authors
have grown to prefer. In other words the author is expected to
include the proper style quotation marks around the quoted text
unless the boolean @needsmarks is set in which case it behaves the
same as Q. I think this is a particularly elegant solution because
then Q becomes the compact form of the other two elements. In a
future HTML5 world, by simply using Q authors would be able to quote
any material (block or inline) and omit quotation marks and use
simply the single-letter name "Q". The same thing would be
accomplished with BLOCKQUOTE or QUOTE@needsmarks (or QUOTE with
quotation marks). However Q alone would be the most compact form of
this semantic.
To deal with the other part of the problem of an IE style quotation
element we would add the following UA conformance norms:
"Aural UAs must ignore quotation marks whenever encountered on the
boundary of a quotation element (Q, QUOTE or BLOCKQUOTE). In
particular any sequence of one or more characters in the Unicode
general categories Ps, Pe, Pi and Pf, whether these characters appear
immediately prior to the quotation tag or immediately after the
quotation tag. Whenever these characters are added by stylesheet
targeting aural media, those characters should not be ignored."
Or something to that effect. This would make it so aural UAs would
strip the quotation marks from these IE style quotation elements. If
an aural media stylesheet opted to add them back in, then the aural
browser would respect that styling (or whatever styling was applied).
This could of course be overridden by a user's default stylesheet by
setting important ::before and ::after selectors on the quotation
elements.
> 2. a for/id binding between the Q/QUOTE element and the CITE element;
> and a reuse mechanism for newly quoted material derived from the
> same resource/anchor, which contains previously quoted content,
> or content from a common source
I also have some thoughts on addressing this problem statement that I
think might be simpler and more flexible for authors. Basically as I
understand the problem statement here, we want to enable authors to
associate quotations and citations and perhaps even other anchored
phrases with their source and with one another. This would provide
proper verifiable referencing and proper attribution of statements
and ideas. If done well, it would also enable user discovery,
association, and traversal of citations, references and sources.
The way I think to address this is through the already existing @cite
attribute. It also may require the addition of a few new elements.
Basically we're trying to match and associate quotations, ideas and
in-text citations of volumes/documents and contributors with their
sources. This can get complicated, but I think it requires the
following:
• add @cite attribute to A (anchor) to attribute anchored text to a
citation and source.
- alternatively add a new paraphrase element for the same purpose
• add a new BLOCKANCHOR OR BLOCKPARAPHRASE to markup block markup of
ideas (though applying the same solution to quotations expressed
above of using DOM methods and CSS pseudo-class selectors).
- alternatively add @cite to most any element to allow attribution
of a source with any document fragment
• add @cite attribbute to CITE element
• add a new SOURCE or BIBLIOSRC element as an unstructured (or
structured, but that gets more complicated) metadata repository for
source information in the same document.
• make use of varied URI examples for the @cite attribute to show
authors how to incorporate non-URL URIs into their source citations.
Because the URI's are arranged hierarchically from left-to-right of
most general to most specific, it becomes possible for UAs to easily
match a specific citation with more general citations on the page.
For example, if a quotation and a citation each cite the same URI,
the UA could gather those together to display them in a modal dialog
a sidebar or an inspector panel.
<p>As <cite type='author' cite='LDAP://GoetheInstitute/dn=Goethe,%
20Johann' >Goethe</cite> wrote in his famous dramatic poem <cite
type='booktitle' cite='URN:ISBN;3533031845' >Faust</cite> <q
cite='URN:ISBN;3533031845' pages='224-25 hypothetically' >Let's
plunge ourselves into the roar of time, the whirl of accident; may
pain and pleasure, success and failure, shift as they will - it's
only action that can make a man.</q></p>
Similarly, something like:
<p>As <cite cite='mailto:oedipus@hicom.net'>Gregory Rosmaita</cite>
wrote: <q cite='mailto:oedipus@hicom.net'>this is a bit of re-
thinking of the issues i've raised on-list about deprecating Q and
BLOCKQUOTE in favor of a single QUOTE element</q></p>
In this sense, 1) citations are the mention of a source within the
text body; 2) quotations are direct quotations of a source; and 3)
anchors (through A or BLOCKANCHOR or PARAPHRASE or BLOCKPARAPHRASE)
serve as a exposition of an idea or a paraphrasing of a quotation.
In order to support references lists to list references of sources
(or important sources) that are cited, quoted or otherwise require
attribution in the body of the text,, we would add a new list
semantic with the elements SOURCELIST and SOURCE or BIBLIOSRC. The
BIBLIOSRC element would also support the cite element and would
typically be the most general form of the URI (the shortest form)
appearing in the document. In other words every citation of a URI, no
matter how specific, would be indirectly referencing the same
BIBLIOSRC in the SOURCELIST. BIBLIOSRC like LI or DD would support
the same either block or strictly-inline content model to support
annotated bibliographies. Other structure could be added either by
HTML5 or other recommendations. Additional information could also be
displayed by a SOURCELIST through UA retrieval of online sources such
as bookstores, the library of congress, etc. The type of metadata
supported by this source list is probably one of the only pieces of
Dublin Core defined metadata missing from HTML5.
Once an author opts to include an explicit SOURCELIST, the existing
quotations, citations and paraphrased ideas could specifically target
the source list through an IDREF style relative URL like
cite='#thissource'. UAs could still provide traversal details of the
source through direct interaction with the citation, quotation or
anchor element.
Beyond our scope but we might liaison with CSS WG to possibly:
• add @pages (string) attribute to quotation and anchor elements
(with CSS pseudo element selector to present the extracted content of
the attribute)
• add @annotation (string) attribute to quotation and anchor elements
(with CSS pseudo element selector to present the extracted content of
the attribute)
>
> 3. choosing a target attribute (actionable quotes pointing to
> text-in-context)
>
> * either reuse @cite or, since @cite is not widely supported,
> @src could be used to point at target, but i'd prefer a simple
> @href, since that seems to be the most widely supported
> exposure mechanism
I think it's important to keep @cite, @href and @longdesc separate as
they really indicate different semantics. I think those differences
are beyond the more fine-tuned difference handled by the @rel
attribute, which describes different relations of hyper-referenced
content. In contrast @cite means something more like attribution or
for verification that is not as immediately interesting to a reader.
Having said that, I think it's important for us to provide more
detailed guidance for UAs to encourage or require them to make all of
these semantics available for users to explore.
> 4. the CITE element needs a targeting mechanism for linking to
> Dublin Core reference files -- please consult the following:
>
> 4a) initial thoughts on redefining CITE's attribute set can be
> found at:
> <http://esw.w3.org/topic/HTML/MuchAdoAboutQ#head-
> 04eed162a38525f80349467cdf218ea72fddc167>
>
> 4b) Dublin Core References & Resources can be found at:
> <http://esw.w3.org/topic/HTML/MuchAdoAboutQ#line-90>
Since the @cite attribute takes a URI (not just a URL) I think it is
sufficiently specified to point to Dublin Core document, or any
document that has a URI assigned to (or assignable to) it. We can
make use of "URN" style ISBN, ISSN, etc. We can use "LDAP" URIs to
cite a specific person within a company. Or use a "mailto" URI to
unambiguously cite someone without requiring a formal directory
entry. There may be some limits to citations using existing URI
schema, but there may be other working groups that could step up and
fill the gaps (for unambiguously citing long-dead authors like Goethe
for instance).
> Note: test pages for support for the Q and BLOCKQUOTE elements as
> defined
> by HTML 4.01 can be found at
>
> <http://www.hicom.net/~oedipus/exegesis/binding.html>
> and
> <http://www.hicom.net/~oedipus/exegesis/4free.html>
>
> primary source documents, marked-up so as to be linked to at the
> paragraph, sentence, and sometimes even clause level can be found
> in the following directory:
>
> <http://www.hicom.net/~oedipus/exegesis>
>
> the pages also test for support for the CSS2 :before and :after
> pseudo-elements for the generation of emphatic quotes (i used
> the EM element for this purpose, so that there is a fallback to
> demarcate emphasis, even if the open-quote and close-quote values
> are not supported by a particular user agent -- in the ideal
> world, emphatic quotes would have the following @media screen style
> rules:
>
> em { font-style: italic; }
> em.em-quote { font-style: normal; }
> em.em-quote:before { content: open-quote; }
> em.em-quote:after { contents: close-quote; }
>
> the above style rules for the screen media type, except for the
> em.em-quote's font-style being set to "normal", as well as
> complimentary style rules using the aural media type are used
> within the test documents
I think you and others have developed sufficient use-case grounds for
adding an emphatic quotation element to HTML (something like EMQ).
This would not necessarily have a @cite attribute since there would
be no presumption that the contents of the element was a direct
quotation (though it could link to a SOURCE in the annotated
bibliography or footnotes).
Summary of additions:
• New QUOTE element to support IE style quotation semantics
- also a @needsmarks boolean attribute to change it back to HTML
style quotation element
• Two new elements: SOURCELIST, BIBLIOSRC and BLOCKANCHOR (or
PARAPHRASE and BLOCKPARA instead of BLOCKANCHOR and the existing A)
• add @cite to CITE, SOURCELIST, BIBLIOSRC, A, and BLOCKANCHOR.
• provide many more varied examples of @cite URIs including
"urn" (like ISBN), "mailto", "ldap", #IDREF to demonstrate the
flexibility of the @cite attribute (possibly liaison with others like
Dublin Core to round out URI schemas and registries: particularly for
URIing authors and other contributors)
• add new UA conformance criteria to provide interactive user
discovery of related citations, quotations, ideas and referenced
sources.
• add new UA conformance options to preform online lookup of non-URL
URI information.
• add new UA conformance options to automatically generate source
lists (while still supporting optional author manually created source
lists and annotated bibliographies)
I hope these proposals are clear. It's a lot to digest, but I think
it really adds some minor features that round-out the existing
features and would therefor have large effects for users and authors.
Take care,
Rob
Received on Wednesday, 1 August 2007 19:54:45 UTC