Wordfiles for CSS - Cascading Style Sheets

Mofi · Sep 14, 2007#12007-09-14T21:22+00:00

With some help by forum user Andreas (thanks!) my final versions of completely new CSS wordfiles are now available on the Downloads - Extras - Wordfiles page. There are 3 files available for downloading and using in your wordfile respectively wordfiles directory:

css.uew - Cascading Style Sheets (CSS) 1.0-2.1 (not case-sensitive) (last updated on 2009-12-11)

That file contains the HTML 4.01 elements (tags) and the CSS properties and values defined in the CSS standards 1.0, 2.0 and 2.1. That language is not case-sensitive. It also contains an appropriate function string, a correct list of delimiters and indent, brace and fold string definitions.

Color group 6 contains the valid names of colors and substring definitions for hexadecimal color values. That substring definitions could result in a wrong highlighting of ID selectors like #ffnote { color:blue; }. To avoid that highlighting problem don't use ID selector names that start with [A-Fa-f][0-9A-Fa-f].

Color group 7 contains lots of browser proprietary properties and values. That color group contains also all the CSS 3.0 properties and values I have found in the working drafts of CSS 3.0 from 29th July 2007.

The last color group contains the media type keywords and substring definitions for negative numbers. If for this color group the same color is specified as for the numbers, positive and negative numbers are highlighted with the same color. If you use frequently the media types in CSS files or CSS sections, than better move the substring definition line for negative numbers to a different color group like C4 or remove it completely resulting in negative numbers to be highlighted (partly) as normal text.

css2.uew - Cascading Style Sheets (CSS) 1.0-2.1 (case-sensitive) (last updated on 2009-12-11)

css2.txt is nearly the same as css.txt. It is also for CSS 1.0, 2.0 and 2.1. The main difference is that it is case-sensitive as required for XHTML. That wordfile is better when using the "Auto Correct Keywords" feature of UltraEdit or UEStudio. It has also the possitive effect that wrong highlighting of ID selectors is more restricted because now only names starting with [A-F][0-9A-F] are highlighted wrong.

css3.uew - Cascading Style Sheets (CSS) 3.0 (drafts from 07/29/2007) (last updated on 2009-12-11)

This wordfile contains the not case-sensitive definition for CSS including the working drafts for CSS 3.0 till 29th July 2007. The properties and values of CSS 3.0 are in this wordfile in the color groups C2 and C3 instead of C7 as in the other files. When using this wordfile be aware that CSS 3.0 is currently not normative. So really test your webpages when using CSS 3.0 properties.

chrisdfeld · Dec 07, 2009#22009-12-07T05:09+00:00

I ran into some limitations of the function list pattern in the current UltraEdit 15.20 CSS wordfile. The three user-contributed CSS wordfiles above use nearly the same pattern and also suffer from the same problems. Here's a quick code sample to illustrate the main issues:

Code: Select all

/* this comment appears in the function list with the selector */ #example1 { color: red; }

#example2 /* this comment also appears in the function list */ { color: orange; }

/* this selector won't appear in the function list since its brace is on a new line */
#example3
{ color: yellow; }

/* only the last clause in this selector will appear in the function list */
#example4,
#example5 { color: green; }

Leaving aside the matter of whether the syntax above is strictly valid CSS (or otherwise advisable), I have encountered those scenarios frequently in the wild and wanted to accommodate them. I created the new function string patterns below to address these cases.

Replacement for UltraEdit 15.20's default CSS.UEW wordfile, and also applicable to css.uew linked above - Cascading Style Sheets (CSS) 1.0-2.1 (not case-sensitive):

Code: Select all

/Function String = "^(["#*+,^-.0-9:=>@^[^]_a-z|~][ ^t^p"#*+,^-.0-9:=>@^[^]_a-z|~]+^){"
/Function String 1 = "^(["#*+,^-.0-9:=>@^[^]_a-z|~][ ^t^p"#*+,^-.0-9:=>@^[^]_a-z|~]+^)/^*[~/{}]++^*/[ ^t^p]++{"

Replacement for css2.uew linked above - Cascading Style Sheets (CSS) 1.0-2.1 (case-sensitive):

Code: Select all

/Function String = "^(["#*+,^-.0-9:=>@A-Z^[^]_a-z|~][ ^t^p"#*+,^-.0-9:=>@A-Z^[^]_a-z|~]+^){"
/Function String 1 = "^(["#*+,^-.0-9:=>@A-Z^[^]_a-z|~][ ^t^p"#*+,^-.0-9:=>@A-Z^[^]_a-z|~]+^)/^*[~/{}]++^*/[ ^t^p]++{"

Replacement for css3.uew linked above - Cascading Style Sheets (CSS) 3.0 (drafts from 07/29/2007):

Code: Select all

/Function String = "^(["#$*+,^-.0-9:=>@^[^]^^_a-z|~][ ^t^p"#$*+,^-.0-9:=>@^[^]^^_a-z|~]+^){"
/Function String 1 = "^(["#$*+,^-.0-9:=>@^[^]^^_a-z|~][ ^t^p"#$*+,^-.0-9:=>@^[^]^^_a-z|~]+^)/^*[~/{}]++^*/[ ^t^p]++{"

The existing /Function String line should be deleted and replaced with the appropriate lines shown above. In each case, the first pattern handles CSS rules where the opening brace comes directly after the selector, and the second pattern covers rules where there is a comment block between the selector and the opening brace.

Again, I am not necessarily endorsing the CSS syntax in my examples above, but they are commonly used. For anyone interested in additional test cases, I'm attaching a stylesheet with several more examples you can use to see the limitations of the standard UltraEdit CSS function list and (after inserting my replacement patterns) the improved listing.

(EDIT: Updated to reflect Mofi's suggested changes. The css/css2/css3.uew downloads now also include the function strings above.)

Dec 08, 2009#32009-12-08T00:10+00:00

Mofi, thanks for the already deleted feedback - I updated the strings in my original post. Cheers

Mofi · Dec 12, 2009#42009-12-12T12:01+00:00

In the meantime I really looked on the expressions itself and not only on what they are producing in the function list view. I detected that one part is useless in both expressions. For example for css.uew:

/Function String = "^(["#*+,^-.0-9:=>@^[^]_a-z|~][ ^t^p"#*+,^-.0-9:=>@^[^]_a-z|~]+^)[ ^t^p]++{"
/Function String 1 = "^(["#*+,^-.0-9:=>@^[^]_a-z|~][ ^t^p"#*+,^-.0-9:=>@^[^]_a-z|~]+^)[ ^t^p]++/^*[~/{}]++^*/[ ^t^p]++{"

[ ^t^p]++ is useless because spaces, tabs and line ending characters are already matched by the preceding [ ^t^p...]+ expression.

The wordfiles on the server of IDM have been updated once again and I have also edited the post of chrisdfeld accordingly.

chrisdfeld, if you or anyone else have an idea how to further improve the regular expressions without using Perl, feel free to post it.