Re: Proposing <indent> vs. <blockquote>

At 11:16 PM 4/15/2007 +0100, Benjamin Hawkes-Lewis wrote:
>Murray Maloney wrote:
>>He didn't say "without semantics". I took his meaning to be "without
>>the semantics of blockquote" Perhaps you didn't read it the same way.
>
>I can't read Mike's first email as asking for anything other than <indent> 
>without any semantics. I'll leave it to Mike to clarify what he meant if 
>he wishes.
>
>>Suspiciously like a semantic definition? Whatever do you mean?
>
>The words you chose appeared to describe non-visual relationships between 
>ideas, not merely a visual formatting. This has two implications:
>
>1) We can probably come up with a semantic element to fulfill the use-case.

I think that everyone has agreed that <indent> may not be the best spelling.
Even so, I don't think that we could identify a single meaning for the element
that is represented in presentation by a deeper margins. The meaning is legion.
The meaning may well be: this is how my boss/teacher wants it to look.

>2) If we can't, we can probably come up with better language to express 
><indent>'s non-significance for web communications.

How can you continue to say that it is non-significant? An indented block 
conveys meaning.
It's just hard to say what its meaning is in every instance. And I, as an 
author, should not
be required to be specific about the meaning of every phrase and block that 
I utter.

[...]

>>The merit of <indent>, perhaps with a different/better spelling, is
>>obvious to those in the audience who realize that truly semantic
>>markup will never gain traction until it becomes easier not to abuse
>>it than it is to abuse it.
>
>Two questions:
>
>1. Is there any evidence that introducing new presentational markup will 
>make it "easier not to abuse" semantic markup? Here's some evidence 
>against that idea. <b> and <i> are not deprecated in HTML 4.01 or XHTML 
>1.x. Yet WYSIWYG editors that spit out <strong> and <em> for [B] and [I] 
>buttons are commonplace. By your logic, that shouldn't be happening.

<strong> and <em> are aliases for <b> and <i>. Always have been.

I have worked on document conversion projects in which millions of pages of
technical manuals were being converted into markup. It was fairly common 
practice
to markup text in bold or italic as <b> and <i> and subsequently have an 
editor
review the markup and swap in semantic tags. Rather than tag everything as a
part number or an index term, which would have been tag abuse, they used 
presentational
tags to capture the only meaning that could be inferred by visual 
inspection by non-experts.

>2. If people can't be bothered to use semantic markup now, how will you 
>entice them to do so in the future, especially when they can just keep 
>using the presentational elements you've introduced instead?

The question assumes that I want to convince anybody of the need for them 
to use semantic markup.
I do not. Nor should you, I assert. It should be enough that they can use 
presentational markup
to achieve the results that they are after, and we can use semantic markup 
to achieve the results
that we are after.

[...]
>I haven't got a copy of the Chicago Manual to check, but I don't 
>understand how it's an authority on /hypertext/ documents at all.

An authority on documents. We are talking about documents.
I wasn't proposing that <indent> or <whatever> would be used
within forms.

>>Ideally, we would have an HTML element to correspond to every logical
>>element of a "Document", but we don't.
>
>So why don't we spec those logical elements rather than <indent>?

I didn't suggest that we shouldn't, although I think that it might take a
while to sort out a canonical list. But ultimately, it's because document
elements are not always semantic. We need to acknowledge that.

>WHATWG's draft already includes semantics for note and warning, and a 
><footer> element which equates to colophon:
>
>http://www.whatwg.org/specs/web-apps/current-work/multipage/section-global.html#class3
>
>http://www.whatwg.org/specs/web-apps/current-work/multipage/section-global.html#class5
>
>http://www.whatwg.org/specs/web-apps/current-work/multipage/section-sections.html#the-footer

I can't quite tell what a <footer> is. The description is a bit vague to me:

         The footer element represents the footer for the section it 
applies to.
         A footer typically contains information about its section such as 
who wrote it,
         links to related documents, copyright data, and the like.

It seems to be a meta-data section like in DocBook.
Could it be used for a colophon? Maybe.
How would you signal that? With a class attribute?

>What would be wrong with adding the following as elements, predefined 
>classes, types, or WAI-ARIA roles:
>
>1. epigraph (these seem quite common on blogs)
>2. dedication (never seen one of these on the web)
>3. tableofcontents
>4. index (for alphabetical lists of local links)

I am in favor of adding all of those. But I think that a more thorough 
inventory is in order.

>For subordinate paragraphs in legal and technical documents, I believe we 
>need a way of semantically associating particular numbering systems with 
>blocks. One option would be to bring back alphanumeric types for <ol>, but 
>that would require some accessibility testing. Another option would be to 
>use heading elements to demarcate each subordination, but style them to be 
>inline with the following text. A third option would be to just use 
><strong>, but that wouldn't help assistive technology in skip over whole 
>sections, so I don't think that's a good idea.

Numbering systems is


>Judging by:
>
>http://www.google.co.uk/search?q=define%3Acallout
>
>callout has no agreed meaning, representation, or behaviour. How does the 
>Chicago Manual define it?

There are lots of different kinds of callouts. Kind of like nested text blocks.
You know when you need one, but you don't always have a name for what it is.
Callouts can sometimes be like the proposed <aside> and sometimes <caption>
or <legend>. When you hover over an image an the title text appears, that 
is a callout.
The CMOS discusses captions, legends, credits, permissions, copyrights, and 
so on.

>>But we have also discovered that everyone tends to trust <b> and <i>
>>even though they do not contribute to deeper semantic understanding.
>>They are trusted because they do not make any claims about semantics,
>>except where attributes might be employed to add a layer of semantics
>>that may be discoverable by reading a profile or employing a GRDDL
>>transform.
>
>Why should semantic claims added by profiles or GRDDL be trusted either?

I suppose that they should only be trusted if/when experience dictates that
a given site is reliable in its use of CLASS and other attributes. That will
often be the case for an intranet in which one has faith.

>>>>That's not to say that semantics can't be overlayed onto HTML, it
>>>>  can. Using a variety of techniques, including CLASS attributes, 
>>>> profiles, GRDDL, XSLT, and so on, HTML content be used coerced
>>>>into being semantically rich.
>>As I said, the advantage would be to make HTML semantically rich --
>>that is, rich beyond the semantics of "hypertext document
>>publishing."
>
>But the semantics of "hypertext document publishing" seem completely 
>open-ended.

Right, but I can't imagine trying to develop elements for every possible 
document semantic.
I think that we need a core set of presentational elements -- most of which 
we already have --
a broader set of document structure elements which will accommodate common 
use cases,
and an even broader set of data elements. After that, class attributes can 
be used in microformats
and by GRDDL to extract data from the document.

>>What I am suggesting is that HTML will suffer from abuse at least as
>>long as there is not sufficient markup to perform normal document
>>composition.
>
>Sure. I just don't believe we need any presentational markup to perform 
>"normal document composition".

Ya, I get that. Too bad.

Regards,

Murray

P.S. Interesting exchange anyway.

Received on Monday, 16 April 2007 03:17:11 UTC