On Aug 2, 2007, at 1:49 AM, Dave Pawson wrote:
> On 01/08/07, Robert Burns <rob@robburns.com> wrote:
>>
>> Hi Gregory,
>>
>> On Aug 1, 2007, at 11:02 AM, Gregory J. Rosmaita wrote:
>
>>> there is also a comprehensive review of Q, QUOTE, and BLOCKQUOTE in
>
>>> <http://lists.w3.org/Archives/Public/public-html/2007Jul/0915.html>
>
>>> =============================================================
>>> 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.
>
I'm not sure I'm following what you're saying here, but I'll respond
to continue the dialogue.
> I think that argument is flawed, relying on structure rather than
> markup?
> I don't believe it addressed the inline vs block usage that Gregory
> enables
> explicitly via markup.
My proposal relies on the structure of the markup. So it does rely on
markup. That is when a Q or QUOTE element contain what HTML5 is
calling structural-inline elements or block-level elements the DOM
API returns a value or block. Likewise if the quotation contained
only strictly-inline level markup it would indicate that through the
DOM API. Finally, if the Q or QUOTE element contained other Q or
QUOTE or BLOCKQUOTE elements nested within them the DOM API would
signal that as well. All of this could also be exposed to CSS through
pseudo-CSS selectors. There's no reliance on the presence of
quotation mark code points.
>
> div/quote vs p/quote.
>
> Many authors use improper markup using divs as their only block
> level division.
> Is the above inline or block level?
Without markup I cannot tell. However, my proposal relies on markup
so it would always provide an answer.
<q><p>Many authors use improper markup using divs as their only block
level division.</p></q>
The above is block level and would be returned from the DOM API that
way and made available as a CSS class selector.
<q><em>Many</em> authors use improper markup using divs as their only
block level division.</q>
The above is strictly-inline level and would be returned from the DOM
API that way and made available as a CSS class selector.
> Also, relying on the appropriate codepoint for quotes could result
> in confusion
> depending on the editor used.
Again, my proposal does not rely on the code point at all. It relies
on the markup contained within the Q or QUOTE (or even BLOCKQUOTE)
elements.
The only thing that would be added by explicit attributes (as Gregory
suggested) would be the possibility of an incongruence between the
contents of the element and the value set for the attribute. For
example:
<quote type="inline" ><p>Many authors use improper markup using divs
as their only block level division.</p></quote>
This would be errant markup. However, it's errant markup that is
simply unnecessary since the UA can already identify the actual
content model used inside the element without the need for an author
provided attribute value.
> I think SGML / XML should use markup rather than structure to infer
> semantics.
I agree. The code points I refer to is to deal with the situation
where authors want to include quotation marks in their markup.
Basically the norm I propose tells aural UAs to ignore quotation
marks whenever they appear on the boundary of a QUOTE element. For
example:
â€œ<quote>Hereâ€™s a quotation.</quote>â€