- From: Brett Zamir <brettz9@yahoo.com>
- Date: Tue, 28 Dec 2010 15:05:29 +0800
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<ash at ashleysheridan.co.uk> 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 >> >> >> >
Received on Monday, 27 December 2010 23:05:29 UTC