[whatwg] Syntax Highlighting

[James Graham]

Ian Hickson wrote:

>I can see the argument for, namely that it gives metadata much like <meta 
>name="author" content="Foo Bar"> gives metadata, and that there is no 
>requirement for the UA to do anything with it since it is merely a hint.
>
>The way it is defined now, it just says what _kind_ of text is expected in 
>the textarea, so that in future UAs can do something with it if they want.
>
>It's also very cheap as far as the spec goes, taking just one paragraph.
>
>
>I can also see the arguments against (indeed I originally argued it 
>shouldn't be added because of these), namely that it won't be implemented,
>
"won't" is such a strong word. I've already pointed out one case 
(Konqurer) where syntax highlighting would be trivial to implement. With 
something like Mozilla, a single interested developer could add this 
functionality themselves (perhaps the code which provides syntax 
highlighting in new versions of Nvu could be ported to work in general 
textareas?). It's certainly a feature that would appeal to the sort of 
person likely to implement it. If, as it happens, it's not implemented, 
we haven't lost anything. The increase in complexity of Web Forms 2 is 
negligible and with no required behavior, there is no interoperability 
problem.

> 
>can't be tested
>
I genuinely don't understand this point. How is this worse than any 
other feature that has no clearly defined rendering or other special 
properties (such as a special attributes in the DOM)? Features that fall 
into this category include many existing HTML elements.

>The way it is defined now, it is just as useless as <meta>: UAs will never 
>do anything with it.
>  
>
Unlike <meta> there are clear use cases that will improve the UI of any 
browser that chooses to implement them. <meta> doesn't have clear use 
cases in general-purpose UAs (but does have use cases in special 
situations or for specific-use UAs).

>It's also just confusing to have this in the spec without clear use cases.
>  
>
There are clear use cases - syntax highlighting, at least of of HTML, is 
one - this would be useful for the large number of people who use a CMS 
with a HTML UI, people who leave comments with embedded markup on 
websites and other similar cases. It would also make it possible to 
write features such as the Firefox BBCode Extension [1] that did not 
require formatting options for every supported content type to appear 
for all context menus [2], which would improve the UI of such features. 
Intelligent markup-ignoring spell-checking is another obvious use case. 
Other use cases can be simply determined by starting a text editor and 
seeing what language-specific features are provided. At present, it is 
a-priori impossible for web browsers to implement any of this 
functionality, despite the fact that for much of the population the web 
browser is their primary text editor. Including a single, simple, 
attribute in the spec gives UA vendors (or vendors of UA extensions) the 
ability to provide better text editing functionality. Not including that 
attribute prevents anyone from taking the lead and providing improved 
editing features, yet has no appreciable gain.

[1] 
https://update.mozilla.org/extensions/moreinfo.php?application=firefox&id=128
[2] 
http://jedbrown.net/mozilla/extensions/BBCode/Screenshots/bbcode-bbcode-contextmenu.png