On 6/13/2010 10:45 PM, Bjartur Thorlacius wrote:
While using @lang for this purpose sound good in theory it will simply
overload it with information it wasn't really designed for. Something
like @type=application/perl or somesuch might work better. That also
has the benefit that we don't need to build a new list of names of
programming languages (and take care of languages with similiar/same
names, such as Go vs Go!).
(Sorry for the very delayed reply)

I like the @type idea, and it can be extensible too via application/x-*.

I think <code/> could benefit for this approach too, in order to keep them in harmony.

Brett


On 6/13/10, Ashley Sheridan<[email protected]>  wrote:
On Sun, 2010-06-13 at 13:57 +0800, Brett Zamir wrote:

Has thought been given to allow textarea, input and/or contenteditable
elements to use an attribute (maybe like<code/>  does with
class=language-XX) so that user agents might be able to display the
editable text with syntax highlighting code automatically?

This should not adversely affect users who do not have such browser
support, nor does it put pressure on browsers to implement immediately
(add-ons might take care of such a role). But having a convention in
place (even if languages are not predefined) would ensure that the
burden of implementing such support could be shifted away from the
developer if they are not so inclined.

I'd prefer to see a dedicated attribute (also on<code/>) since the
language type does convey general interest semantic information, but I
think it would also ideally be consistent (i.e., the same attribute to
be used in<code/>  as in<textarea/>, etc.).

Maybe @lang/@xml:lang could be used for this purpose if its definition
could someone be widened to recognize computer languages.

It would be nice, however, to also have some means of indicating that
the web author is providing their own styling of the element in the
event they wish to use their own editor.

thank you,
Brett Zamir

I think maybe not a class, as the class attribute already has a purpose
and is probably already used in a<code class="php">  type of capacity
already by some sites showing code excerpts. I'd suggest maybe extending
the lang attribute, but it's also conceivable that a code snippet might
be in Perl and written with French comments, and the lang attribute
wasn't meant for multiple values like the class attribute is. Perhaps
the best solution is to use another new attribute altogether?

It is a good idea though, I think, as it does add a lot of semantic
meaning to the content.

Thanks,
Ash
http://www.ashleysheridan.co.uk





Reply via email to