- 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:43 UTC