- From: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
- Date: Mon, 16 Apr 2007 23:46:48 +0100
- To: public-html@w3.org
- CC: Murray Maloney <murray@muzmo.com>
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