[whatwg] Syntax Highlighting
jg307 at cam.ac.uk
Tue Dec 14 09:16:42 PST 2004
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
>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  that did not
require formatting options for every supported content type to appear
for all context menus , 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.
More information about the whatwg