CSS lexer updates: Looking for comments and suggestions

10 views

Skip to first unread message

Jason Oster

unread,

Sep 25, 2008, 2:25:58 PM9/25/08

to scintilla...@googlegroups.com

Hello all,

I've been working on the CSS lexer, and I would like to gather comments
and suggestions from any web developers who might use it. Details of the
changes and additions (including the complete patch, as it is now) are
available on the Scintilla feature request tracker:
http://sourceforge.net/tracker/index.php?func=detail&aid=2122992&group_id=2439&atid=352439

I would like to first focus on the parenthetical syntax with CSS
pseudo-classes. CSS3 is set to include new pseudo-classes such as :not()
and :nth-child() which will allow simple expressions or numbers as
selector arguments.

The current CSS lexer can correctly style some of these CSS3 selectors,
for example:

a:not([name]) { /* All anchor tags except ones with a name attribute */
color: red;
}

But cannot properly style others:

*:not(a) { /* All tags except anchors */
color: black;
}

In this example, the 'a' is styled the same as the operators
(SCE_CSS_OPERATOR). With my patch, the 'a' will instead be styled
properly as a tag (SCE_CSS_TAG). But this introduces a slight issue:

div:nth-child(3) {
background-color: blue;
}

The current CSS lexer styles the '3' the same as the operators, and my
patch instead styles it as a tag. I do not believe numbers should be
styled as tags. Should a new style definition be included for numbers
that appear within pseudo-class parentheses?

That said, none of this 'argument processing' is currently applied for
pseudo-elements:

a::after(b) {
content: '!';
}

This example is invalid CSS, but demonstrates that the 'b' is not styled
as a tag with either the original CSS lexer or my patch. Should it be
changed to allow tags to appear within pseudo-element arguments?

Another point I would like to bring up is with vendor-specific
extensions to CSS. My patch includes support for vendor-specific
properties, pseudo-classes, and pseudo-elements. MDC has a fairly well
documented list of extensions to CSS that they support:
http://developer.mozilla.org/en/CSS_Reference/Mozilla_Extensions

Some of their vendor-specific pseudo-classes use arguments. In this
case, it's not right to style those args as tags, so the current
implementation in my patch attempts to style those args as another
vendor-specific pseudo-class. This allows one to write CSS like this:

a:-moz-system-metric(windows-default-theme) {
color: green;
}

... and have the "-moz-system-metric" and "windows-default-theme" both
take on the same style. But then again, it also allows one to write
invalid CSS that gains this styling:

a:windows-default-theme {
color: green;
}

"windows-default-theme" is not a valid vendor-specific pseudo-class!

So the whole reason for this quirky implementation is to keep the number
of keyword changes to a minimum; why include a 'vendor-specific
pseudo-class arguments' keyword list if it's not necessary, right?

And again, this special-case handling is not applied to vendor-specific
pseudo-elements.

What say you, web tech heads? Any solutions to these issues? Am I
missing anything? It would be great to get these changes into Scintilla
sooner rather than later.