Re: <code type="...">

On 26/05/07, Patrick H. Lauke <> wrote:
> Some might say that HTML is already strangely specific for computing
> type applications, with its inclusion of <code>, <var>, <samp>, <kbd>.
> Further refining these elements seems weird, considering that other
> areas are still arguably lacking more adequate elements to better mark
> up content.

Further, do we have a reason for assuming that a class attribute
doesn't deal with this adequately?

> > As a use-case, a (hypothetical) javascript library -- say, during body onLoad
> > -- could parse and syntax-hilight [[[
> >
> >     <pre><code type="text/x-python-source">
> >     def foo():
> >         return [x**2 for x in range(10)]
> >     </code></pre>
> >
> > ]]] differently from [[[
> >
> >     <pre><code type="application/json">
> >     {'foo': ['bar', 'baz','quux'],
> >      'bar': 42,
> >     }
> >     </code></pre>
> >
> > ]]] in a blog posting using such code as examples.
> Your use example seems to suggest that you'd want it mainly for styling
> which case I'd argue that this could be more appropriately
> solved by using class attributes (but not by reserving those in the spec).

How about parsing to produce internal links for functions and
variables in source code, to mark syntax errors, to add commentary
about what identifiers are not explicitly author written and linking
specification for them, parsing to pretty-print source code or other
kinds of handling that requires more precise knowledge of the
particular type of code? In other words, parsing to gain some semantic
knowledge without having to make the semantics explicit?

> > Extending, user-agents might dispatch to external handlers or formatters
> > based on @type.
> Handlers? Are you proposing that <code> should actually be *executed*?

Maybe not executed, but just something that makes intelligent
presentation of content with implicit semantical value?

> > Also, I note the analog with <object type=...>.
> But <object> actually *does* something, as opposed to <code> whose
> purpose is to mark up a code fragment for display/presentation, not
> execution.

Well, there's lots of behaviour-presentation special handling that can
be added for code fragments without executing it. Take source code
folding for instance.

However, I don't really see what a type attribute adds that a class
attribute could not be used to provide instead.
David "liorean" Andersson

Received on Thursday, 21 June 2007 18:42:36 UTC