[whatwg] Syntax Highlighting [was: several messages]

[James Graham]

Ian Hickson wrote:

>On Wed, 30 Jun 2004, James Graham wrote:
>  
>
>>I was having thoughts about a somewhat similar feature - the ability to 
>>specify a input 'language' for a text-area and possibly to specify a 
>>subset of language elements allowed. This would principally be for 
>>situations in which the input was text supplemented by a markup language 
>>such as (x)html, textile, bbcode or similar. Providing this information 
>>would allow the UA to provide word-processor-like editing controls for 
>>the textarea. Allowing the specification of a particular subset of the 
>>language (e.g. html, 'a' elements only, 'href' and 'lang' attributes 
>>only) would allow the UI to be further refined. Clearly one would need a 
>>set of default language profiles to ship with the UA. A good 
>>implementation might allow the set of profiles to be easily extended. 
>>There would need to be a mechanism for storing and fetching the 
>>information about the allowed subset of the language.
>>    
>>
>
>Realistically, I just can't see something of this scoped getting 
>implemented and shipped in the default install of browsers.
>
I agree that the bit about limiting the allowed input, client side, is 
unwieldy.

>  
>
>
>
>On Thu, 1 Jul 2004, James Graham wrote:
>  
>
>>So something that would roughly work: Add an optional dataformat (better 
>>name?) attribute that takes a URI. For XML formats, this will typically 
>>be the namespace of the format, for other formats it must simply be 
>>globally unique. Additionally, specify a set of string -> URI mappings 
>>for common formats such as HTML, XHTML and others so they may be 
>>identified by the shorter string (which must not be a valid URI) rather 
>>than the long URI. The behavior of the UA in response to the presence of 
>>the attribute is not specified.
>>    
>>
>
>The problem with this is I imagine UAs would probably just end up doing 
>nothing, and we'd be back to where we are now.
>
The details of that suggestion were way too complex. But replace all the 
rubbish about URIs with 'allow an optional attribute specifying the MIME 
type of the data type expected in the textarea'. Since many browsers use 
text editing components that already support features such as syntax 
highlighting (or, I would be surprised if they don't), it would seem 
very plausible that at least some browsers would make use of this 
attribute to provide a better text editing experience. Since many 
applications (e.g. CMS systems) require the input of specific data types 
(html) in text areas, this could be a big usability win for any browser 
that implements it. Clearly syntax highlighting is not the only 
possibility - a spellchecker could be set up to ignore certian data 
types or certian poritions of the text in a particular data type.

(there are also interesting possibilities for outputting data, e.g. 
code, to textareas so that syntax highlighting is avaliable for free. 
But that may be bad for accessibility).