Re: Proposing <indent> vs. <blockquote>

Murray Maloney wrote:

> 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.

If <indent> ever has any meaning, then it will be necessary for 
assistive technologies to expose <indent>'s presence, will it not? Yet 
earlier Mike seemed to imply screen readers could ignore <indent>:

> The problem you are ignoring is that screen readers would do better to 
> ignore presentational markup than to recognize improperly used semantic 
> markup.

http://lists.w3.org/Archives/Public/public-html/2007Apr/0790.html

So again, you and he appear to be talking about very different animals.

> The meaning may well be: this is how my boss/teacher wants it to look.

Purely presentational effects are what styling languages are for. CSS 
may not beautiful, but I don't think it's the job of this WG to fix that.

If it's not a purely presentational effect, then we should be 
encouraging people to think about what they are writing - just as they 
do when composing print documents. People don't consult style guides 
like CMOS to learn what indentation is but to learn how to present (say) 
quotations and bibliographies. And manuals of printed style tend to move 
from categorizing parts of documents by function /to/ what their 
representation should be, not the other way round.

As for bosses and teachers, they have (I believe) a moral duty, and in 
many countries a increasingly strong legal obligation, to think about 
how they can maximize accessibility as well as gratifying their own 
aesthetic whimsy. Not reducing employees or students to mindless 
automata might also be a good idea, but as far as HTML goes that's 
optional. ;)

> 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.

Web communication tools like HTML should require authors to be
specific /enough/ to communicate effectively with their audience. 
Otherwise, such tools are not fit for purpose.

<indent> is hopelessly vague IMHO.

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

HTML is not defined by broken WYSIWYG tools: <strong> and <em> have 
never been aliases of <b> and <i>, though obviously within Western 
languages they are intricately related.

> 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.

As it was /designed/ for encoding printed documents, might TEI have been 
a more appropriate tool? People who frequent W3C mailing lists seem 
generally opposed to making HTML a language that can faithfully 
represent printed documents, because like TEI it would prove somewhat 
complex. I'm not personally opposed to such an expansion of HTML, but I 
think presentational markup should be reserved for such situations and 
not presented as a reasonable option for new documents.

I also recognize there is a desire for a crude presentational subset of 
HTML defined for use by systems like Blogger. But note that while 
Blogger thinks <i> and <b> are indispensable, the developers didn't feel 
any need to provide some form of indentation mechanism.

> 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.

In so far as I believe semantic markup significantly contributes to: 1) 
a just (equal access) society, 2) furthering human knowledge, and 3) 
liberating human beings from the tedium of repetitive formatting, I feel 
impelled to encourage its adoption. But I think the list is stronger for 
including people with differing ethical perspectives. :)

>>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.

I'd call it an authority on late 20th-century American printed style, a 
small subset of documents.

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

[snip]

> It seems to be a meta-data section like in DocBook.
> Could it be used for a colophon? Maybe.

Judging by:

http://www.google.co.uk/search?q=define%3Acolophon

<footer> is less vague than "colophon" (either a printer's emblem /or/ 
material facts about a publication). But what changes would you like to 
see to the text to make it more obviously so? How about: "A footer 
typically contains information about its section such as who wrote it, 
links to related documents, copyright data, a discussion of the web 
technologies used in its production, and the like"?

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

What else do you think needs inventorying?

>>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

Did you get cut off here?

> 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.

Great, so we already handle callouts in the proposed WHATWG draft. :)

> The CMOS discusses captions, legends, credits, permissions, copyrights, and 
> so on.

We've got <legend> for <figure>:

http://www.whatwg.org/specs/web-apps/current-work/multipage/section-embedded.html#the-figure

and a class for copyright. I'm not sure what the difference between a 
credit and a permission would be. My guess is that they both indicate 
the external provenance of an idea or content, in which case <cite> 
would be appropriate, for example:

<figure><img src="sunflowers.jpg" alt="Sunflowers"><legend>Sunflowers 
are especially beautiful in Summer. By <cite>Joe 
Bloggs.</cite></legend></figure>

> Right, but I can't imagine trying to develop elements for every possible 
> document semantic.

I can imagine develop elements sufficient to cover 100% of cases 
generically and the most common web cases specifically. By contrast, I 
doubt /simple/ elements will cover even common presentational use-cases. 
e.g. People don't just want <indent>, they want a particular amount of 
indentation. And sometimes they want it on the left, sometimes on the 
right, and sometimes on both. My guess is you'd end up gibberish like:

<indent left="3em" right="3em" 
style="font-size:70%;margin-top:1em;margin-bottom:1em;">Something that 
should have been a quotation, in text that is too tiny for you to 
read.</indent>

> I think that we need a core set of presentational elements -- most of which 
> we already have --

Other than <indent>, what are the others that you hope to add to the 
existing set in HTML 4.01 Strict (<i>, <b>, <big>, <small>, <sub>, 
<sup>, <tt>)?

> a broader set of document structure elements which will accommodate common 
> use cases,

No disagreement here. WHATWG's draft does provide many of these, 
however. It doesn't provide as many as I might like, but I appreciate 
the desire to keep things simple.

> and an even broader set of data elements.

What's a "data" element? Is that like <address>?

> P.S. Interesting exchange anyway.

Glad you found it so; I certainly did too. :)

--
Benjamin Hawkes-Lewis

Received on Tuesday, 17 April 2007 01:13:13 UTC