#3 Syntax highlighting inexact
The syntax highlighting for CSS, while working as
expected in most cases, is easy to confuse because the
individual elements can't be checked for the context
they appear in.
For example, the rules:
#content:hover { font-weight: bold }
.content:hover { font-weight: bold }
both have the word "content" highlighted, because it is
a known CSS property name and is followed by a
semicolon (which currently are the only criteria for
detecting a property name). However, as the word
appears in a selector, it cannot be a property name,
and should thus not be highlighted as one.
For another example, at-keywords can be highlighted
when they appear in declaration values (for example),
so in the following rule:
h1 { display: @import }
which is not valid CSS, the word "@import" is
highlighted as an at-keyword, even though at-keywords
are illegal at this position. I'm sure there are more
problems like this.
The solution would be to provide more sophisticated
partitioning of the document into partition types such
as "selector", "property" and "value". This would be
relatively easy to achieve if the Eclipse text plugin
component supported nested partitions, which is an
overall plan item for 3.0, but has not yet been
implemented.
When the feature gets implemented for 3.0, we should
move to using it to provide the extra precision in
syntax highlighted. If the plan item is deferred, we
should investigate a custom partition scanner
implementation.
Logged In: YES
user_id=346040
net.sf.wdte.ui.text.rules contains implementation of nested
partitioning. And it works well even with nested languages.