[whatwg] Syntax Highlighting [was: several messages]

[James Graham]

Ian Hickson wrote:

>On Wed, 8 Dec 2004, James Graham wrote:
>  
>
>>>They don't. At least, none of the browsers I know about have syntax 
>>>highlighting editors of that kind, as far as I know.
>>>      
>>>
>>I would have thought that any browser using a standard widget set might 
>>already have syntax highlighting avaliable (but disabled). However I 
>>neglected the fact that most browsers use custom widget sets to deal 
>>with CSS requirements.
>>    
>>
>
>As far as I know, even standard widgets don't do syntax highlighting 
>editors, but I may be wrong.
>  
>
As far as I can tell, in the standard toolkit, some do and some don't. 
Even for the ones that don't have syntax highlighting in the toolkit, 
implementations in products based on the toolkit tend to exist somewhere.

>>I'm not sure why. It has almost no side effects since it's just a hint 
>>to the client and doesn't affect the actual data being uploaded in any 
>>way. It it perfectly backwards compatible. Since many HTML applications 
>>require text entry and most people who edit text (other than in a web 
>>form) choose to use an editor other than notepad there is clearly demand 
>>for better-than-notepad text editing in HTML. Without information about 
>>the data type expected, UAs can't really provide this. With that 
>>information they can.
>>    
>>
>
>Because it has almost no side effects since it's just a hint to the 
>client. It just isn't something that people are going to implement any 
>time soon (it's exactly the kind of feature that gets delayed to later 
>releases over and over)
>
Well, maybe that's true, I don't know. Since syntax highlighting in 
particular is an obvious UI feature that many people will appreciate in 
any browser that implements it , it's the sort of thing that, if a 
single browser implements, everyone else will implement too (before 
Safari implemented spell checking almsot no one had that feature, very 
soon almost everyone will have that feature). But I'm not sure what the 
cost is if no one implements it; we're just in the same position we're 
in today. Moreover, I'm not sure what the cost is if only one browser 
implements it - there is no interoperability issue.

>, and I'd rather not add features to WF2 that 
>aren't going to have a big impact or be easy to implement well.
>  
>
I don't see how it's "hard to implement well". From the point of view of 
WF itself, there is no implementation requirement (which is to say no 
particular behavior is expected of the client upon finding such an 
attribute in a document) and no interoperability concern. This means 
that it adds almost no complexity to the spec. However it does allow for 
the /possibility/ of rich behaviors that are not currently possible and 
would make HTML more useful for applications. Hence it seems to fit the 
scope of web forms rather well.
(it might, I suppose, be difficult to implement particular features, 
such as syntax highlighting, that are possible when one knows the 
particular format of content expected in a <textarea> if one has to 
start from scratch. On the other hand, if one is using a toolkit that 
supports these features already, it might be trivial to add these 
features and so implementations will be very fast).

>At this point I'm looking for things to drop, not things to add. :-)
>  
>
Sure. But in this particular case, I happen to think that the overall 
measure of benefit, which we can parameterise something like: 
(probability of implementation) * (usefulness of feature if implemented) 
/ (added complexity), is pretty large even if p(implementation) is small 
because, not only is the feature useful but because the added complexity 
is almost zero. Therefore,, I think it's worth adding to the spec even 
at this late stage.