- From: Sevo Stille <sevo@inm.de>
- Date: Wed, 11 Mar 1998 12:17:32 +0100
- To: Victoria Rosenfeld <jiggy@holly.ColoState.EDU>
- CC: www-style@w3.org
Victoria Rosenfeld wrote: > > but they must not be required for using CSS. I'd suggest that anything that > > can be expressed in a RE in CSS should be able to be expressed in other > > means, even if they are much more verbose. > > > Point taken. And agreed with. And if REs must not be required, they why > put them in the specs? What does including them add? > Now, it certainly does not make sense to invent a new method. While there are some more complex forms of pattern matching syntax extending RE (e.g. perl, agrep), we'll have to keep to some common level. Going by what is implemented in common software and across the WWW, I don't see any options beyond strictly literal matching (which would require multiple entries in style sheets to cope with language variants), shell metacharacters (more common than REs, but prone to fail in ambiguous cases) and REs (which would replace the shell "*" with ".*" for elementary wildcard matches - something even beginners should be able to understand). Considering the disadvantages of either, I'd prefer RE. After all, nothing does prevent beginners from using elementary wildcard syntax like "fr.*". That power users are able to write "^ *[Ff][Rr](-[A-Za-z]+)? *$" etc. to do a more waterproof match for the same purpose does not mean that all regexps have to be as powerful and complicated. regards Sevo -- Sevo Stille sevo@inm.de
Received on Wednesday, 11 March 1998 06:23:33 UTC