Re: code, samp, kbd, var

On 15 May, Ian Hickson wrote:

>> During the debate regarding HTML 5 it has, by several people, been 
>> claimed, repeatedly, that presentational elements - all of them -
>> will be added to the new language as time go by.
> 
> They won't be added to the language. They'll be added to the UA
> rendering requirements section of the specification. Elements like

  All right. It's not ideal, but I realize that no matter what I
  actually argue for, or what I show you, the WG won't change its mind.

  So how about we try the following:

   (a) All presentational elements - and yes, this does include I, B,
       FONT, and the way M is defined today - are removed from the HTML
       specification.

   (b) An Appendix is created, which list each presentational element
       found "in the wild", with typical usage, and a description of
       exactly how browsers should treat them /if/ a doctype is
       specified that allow them, and how they should be treated if not.

  This - when fleshed out further - will solve several problems:

   (a) Pedagogy. We can point those wanting to learn HTML at the new
       specification and say "Do like this".

   (b) Interoperability. We can point those wanting to write browsers to
       the appendix and say "This you might find in the wild. Support it
       or ignore it gracefully".

   (c) Theoretical. There'll be no mixup between the
       generic-coding-with-semantics camp and the rest. It'll cut down
       the debate quick.

   (d) Logistically. You can hand *one* appendix to a group consisting
       of browser vendor representatives. You can add another appendix
       detailing how each new element should be placed in context with
       accessibility and hand /that/ to a dedicated team. This'll give
       each section of the specification the specialists they deserve.


  And /then/ we can discuss what bits and pieces should be added to
  each section.

  Cosmetic, perhaps, but it may be the only way to salvage what is
  right now headed for a real bad place.




> that <i> now handles). However, we have to be pragmatic, and after
> several years of careful thought and design and research, we reached
> what the spec says now, which I think is a good compromise.

  [snip]


> I do not believe it actually causes any practical problems, though
> there might be some theoretical ones.

  The very practical problem remain: neither I nor B can be unambigously
  interpreted. They can't be changed to having semantic meaning - it would
  lead to information corruption *in the real world*.

  We can discuss this in circles - personally I must object to the
  idea of replacing presentational interpretation with semantic
  one. 

  Not, mind, that the current WA1 do that. I and B are still
  presentational.


  And worry not. I won't join the WG.

-- 
 -  Tina Holmboe      Developer's Archive           Greytower Technologies
                   http://www.dev-archive.net      http://www.greytower.net

Received on Thursday, 17 May 2007 00:16:08 UTC