- From: Andrew n marshall <amarshal@usc.edu>
- Date: Thu, 4 Dec 1997 21:49:58 -0800
- To: "'neil@bigpic.com'" <neil@bigpic.com>
- Cc: "'www-style@w3.org'" <www-style@w3.org>
I finally figured out what few things were really bothering me: 1.) The use of the '/' in too many notations, especially as a bracketed notation. This is also the source of my concern about whitespace, so if that problem is eliminated, then I could care less about whitespace in between operators and selectors. 2.) The 'following sibling' relationship is a relationship between exactly two selectors. Therefore any bracketed syntax '/.../' meaning 'an ordered grouping of siblings' can be represented by the transitive property of a binary operator. For example: / one two three / might be equivalent to one | two | three where '|' is the 'following sibling' operator. 3.) I still strongly believe first-child and last-child should be pseudo-classes, solely for readability. 4.) I'm disappointed in the lack of mapping between the characters used in the notation and their usage. But I'm not annoyed enough to do anything more than mention it here. (My preferences would be '~' for SIBLING relationships drawing on the use of tilde to denote similarity, where siblings have similar placement on a document tree; and '!' for immediate adjacency drawing on the use in English of stressing a statement, her we stress a relationship.) So this changes my proposal only with respect to whitespace around the '~', which is now more relaxed (and equivalent to the current CSS-2 spec). And since I'm being asked to write out examples in a previous incomplete proposal, I will arbitrarily choose '|' to represent the 'following sibling' relation operator. Since I have no particular reason for this, if anyone sees a problem, please let me know. In addition, please throw out all my previous arguments on parsing. It's obviously I am actually clueless to the process (and at this point that is fine by me; I do UIs and multimedia, not languages and grammars). ------------------------------------------------ Selector syntax proposal for sibling, child and first/last relationships ------------------------------------------------ To refer to an child (immediate descendant), place the '~' between the parent selector and the child selector. For example: DIV.sect ~ P {...} would refer to any immediate P child of a DIV with class "sect". This should refer to the first, second, fifth, and sixth P, but not the third or forth P: <DIV class="sect"> <H3>Section Title</H3> <P>first</P> <P>second</P> <OBJECT> <P>third</P> <P>forth</P> </OBJECT> <P>fifth</P> <P>sixth</P> </DIV> To refer to any following sibling, place the '|' between the leading selector and the following sibling selector. For example: OBJECT | P {...} would refer any sibling P after an OBJECT, which is both the fifth and sixth P's in the previous example HTML. I'm not going to say whether this is necessary, however I include because it keeps the mean of the operators consistent. To refer and immediate sibling, place both the '|' and the '~' between the two selector in either order. For example: H3 ~| P {...} or H3 |~ P {...} both refer to the first sibling following a H3 only if it is a P element. The first P meets these requirements in the above HTML. For both operators, whitespace on either side of the operator is optional. For example: H3~|P{...} and H3 ~ | P { ... } are both legal and equivalent. Selection of the first and last children in a block is done by the pseudo-classes first-child and last-child. For example: OBJECT ~ :first-child {...} refers to the first child of any object tag. The tilde was used here to denote the descendant must be an immediate child on an object tag. The third P satisfies this in the above HTML. OBJECT ~ :last-child {...} refers to the last child of any object tag. The forth P satisfies this in the above HTML. NOTE: As much as I can tell, both of the above are impossible in the existing CSS-2 spec! I have referred to the first element without any element type. The pseudo equivalent of the following: OBJECT // / ^generic element???? On Thursday, December 04, 1997 12:30 PM, Neil St.Laurent [SMTP:neil@bigpic.com] wrote: > There is no problem with a parser extracting meaning from future/past > context, it shouldn't be a problem on the parsing side. I'm guessing > that resolving in the parsing state is a lot quicker than trying to > resolve the pseudo-classes at a later time. On the account of readability, I don't care on this one. I believe the time difference is likely to be nominal since the average case will include a limited number of pseudo-classes. And this determination only occur once on the initial rendering of a page because it is dependant on the document tree, not rendering placement such as :first-line or first-letter. > H1 ~P > > The operator appearst o work on P, rather than a relational > operator. Of course, this display would resolve my problem with > determining which element the style applies to, it would more clearly > be P than H1. It is a binary operator denoting the relation between the two, just like in the current CSS-2 spec. > / //H1/ ~ P / ~ EM //I/ > > Clearly that isn't human readable, but simply refers to the first I > inside an EM that is the direct descendant of a P which is directly > following the first H1. > > Please, with your syntax show me how the above would be done (I'm not > entirely clear on what you are proposing yet). H1:first-child ~| P ~ EM I:first-child {...} not perfectly readable, but I think it goes a long ways towards getting there. > > > > H1 ~(DIV P) > > > /H1 ~ /DIV P// > > > or whatever.. > > How is your expression any different than: > > H1 ~DIV P /* P descendants of a DIV child of H1. Awkward, but > > It is different, because I admit that in my example I have no idea > what element the style applies to, it could be the DIV or the P? > In any case, my concern over what style the element applies to needs > to be addressed. I understand this to be always the last element referenced, so both would refer to the P element. Andrew n marshall student - artist - programmer http://www.media-electronica.com/anm-bin/anm "Everyone a mentor, Everyone a pupil"
Received on Friday, 5 December 1997 00:46:15 UTC