Re: code and blockcode

On 7/11/05, Laurens Holst <lholst@students.cs.uu.nl> wrote:
> 
> Simon Siemens schreef:
> > Up to now blockcode is rather the same as pre. I don't see any advantage.
> >
> > However, adding an attribute codelang, which has values like perl,
> > xhtml, matlab, java, ..., would give it the intended meaning. This would
> > enable
> >
> >    Browsers to provide syntax highlighting
> >    in addition to the preformated layout
> 
> And automatic formatting, too.

While this is probably in store, it would be a huge undertaking even
for one language. I've been reading the blogs of the IDE designers for
popular IDE's and it seems this is something that is very difficult to
do. Automatic formatting is akin to compilation for some languages (in
that you need to parse many files to see what are classes).

> > What would be needed is an (open) list of languages. As we could never
> > list all possible languages, a naming guide should be supplied, so that
> > it is very likely, that two people thinking of the same language use the
> > same value. For the most popular languages a fixed list is provided.
> > Maybe something like versioning should be incorporated as well (say
> > "java-1.5" or "sql-2000", where the text in front of "-" is the code
> > language and the text after "-" is the version).
> 
> At work we use a similar tag, <bdoc:snippet type="xml"> which can also
> be of type css and js. However, it would be better if this were a MIME
> type, application/xml, application/ecmascript, text/css, etc. But I
> don't know whether that is appropriate for all languages...

While MIME type is historically useful, it generally falls apart in a
semantic world. While the application and text types are the least
abused, they don't describe semantic classifications, but rather aid
in communication for UAs. What would be more useful are
classifications based on semantic categories. Examples would be:

audio/song
code/C++
code/javascript
audio/sound-effect
video/movie
video/short
document/book
document/spreadsheet
document/presentation
image/photo
image/background
image/composition

and so on.

> > A second concern (less important) are the (propably often discussed)
> > tags kbd, var, samp. We don't have anything like this in the Struktural
> > Module (but we have code and blockcode). For me kdb, var and samp are
> > some special kind of code. Obviously this is the case for say LaTeX, the
> > perl-interpreter, MATLAB, ... Since code is a specially defined way to
> > provide information almost every input and output is some kind of code.
> > And I don't see any advantage for user agents of any kind that goes
> > beyond the knowledge, that this text is some kind of code. So what about
> > a substition by the code tag extended with a/the role-attribute?
> 
> Hmm, I'm not entirely sure about that. That way, <ul> and <ol> and <dl>
> could also be replaced by <list role="...">, etc.
> 
> Although I agree that by itself it would not be a bad idea, I don't
> think it fits within the whole 'known architecture' idea. Besides, we
> kind of arrived at the 'what should be an element in XHTML, and what as
> a role' question again. So that is why I have doubts.
> 
> But on the other hand, when looking directly at XHTML 1.0
> 'compatibility', <code> with @role will degrade reasonably well, and can
> be styled specifically on UAs which support attribute selectors...
> Besides, those elements aren't very much used anyway, and code could
> then be extended to express even more, which might be desirable.

Role's purpose in a document is to provide semantic clues to how a
part of the document fits within the rest of it (e.g. header, footer,
navigation, advertisement, branding, etc) and *not* type information
or other properties (e.g. sorted, C++, code).
-- 

Orion Adrian

Received on Monday, 11 July 2005 16:55:15 UTC