Re: Alternate Additional Attribute Set for a Single Quote Element

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:
> <>
> there is also a comprehensive review of Q, QUOTE, and BLOCKQUOTE in  
> by robert burns:
> <>

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  

> 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  

 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=''>Gregory Rosmaita</cite>  
wrote: <q cite=''>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)  
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:
> <
> 04eed162a38525f80349467cdf218ea72fddc167>
> 4b) Dublin Core References & Resources can be found at:
> <>

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
> <>
> and
> <>
> 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:
> <>
> 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)
 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  
 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,

Received on Wednesday, 1 August 2007 19:54:43 UTC