Re: Backwards compatibility of new selectors

> Yes, folks seem to want a better bracketing mechanism

Can I suggest that if such a system is introduced that it be unable 
to override the existing non-ambiguous system, such that the brackets 
can simply be stripped out and everything parsed as per normal.

This is my pseudo-language I have gathered from the selectors 
discussion:

CORE = elementName?, pseudo?, id?, (class)*, attrib

elementName = alphanum string

pseudo = ':', alphanum string

id = '#', alphanum string

class = '.', alphanum string

attrib = '[', attName | attEquals | attApprox, ']'

attName = alphanum string

attEquals = alphanum string, '=', alphanum string (may be quoted)

attApproc = alphanum string, '~=', alphanum string (may be quoted)

SIMPLE = CORE

FIRST = '//', SELECTOR, '/'

LAST = '/', SELECTOR, '//'

FIRSTLAST = '//', SELECTOR, '//'

CONTEXT = SELECTOR, Space, SELECTOR

SEQ = '/', SELECTOR, Space, SELECTOR, '/'

SEQImmediate = '/', SELECTOR, Space?, '~', Space?, SELECTOR, '/'

PARENTCHILD = SELECTOR ~ SELECTOR

SELECTOR = PARENTCHILD | FIRSTLAST | FIRST | LAST | CONTEXT | SEQ |
SEQImmediate | CORE
__
| Mortar: Advanced Web Development <http://mortar.bigpic.com/>
| Neil St.Laurent                  <mailto:stlaurent@bigpic.com>
| Big Picture Multimedia

Received on Thursday, 4 December 1997 15:10:30 UTC