[whatwg] Syntax Highlighting [was: several messages]
jg307 at cam.ac.uk
Fri Dec 10 02:48:13 PST 2004
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.
More information about the whatwg