Hi, As you probably know, these are the major outstanding items on the 1.0 development plan (in terms of additional features, anyhow). What follows is my thoughts on some of this stuff, along with a number of the issues involved in implementing these features. If anything's not clear or you have any bright ideas as to how to go about solving some of the problems, then please say so. Equally, if I appear to be exhibiting signs of madness, then don't hesitate to tell me ;) Pseudo Selectors ---------------- I've spent a little time looking at these and have a very hacky, not very efficient, proof-of-concept implementation of the :link, :visited, :hover and :active pseudo classes. This has highlighted a number of things: 1) Matching of pseudo selectors is a bit tricky, as it's based upon information external to the document tree. In some cases (e.g. dynamic pseudo classes) information as to whether a selector matches an element is unknown until the user interacts with the document, which is well after we've generated the style information for any given box. 2) As styles are cascaded, it would appear that it's necessary to create style structs for each permutation of pseudo classes for matching later. This is a) hideously expensive in both computation time and memory requirements and b) just not nice ;) 3) Dynamic changes to the box tree (i.e. after tree creation time) are incompatible with the way the layout engine is designed to work. We currently have some limited support for later changes to the box tree in the form of object fallback processing. I suspect, however, that this simply isn't rich enough to support all the things that fully dynamic transformation of the box tree will require. My current implementation does the following things: 1) The css_get_style API has been extended to allow the user to specify a mask of the acceptable pseudo selectors to be merged into the provided style struct. [Pseudo selectors are treated as always matching when matching a rule's selector and then post-processed to prevent merging of rules with undesireable pseudo selectors]. This permits extraction of style information for various permutations of pseudo selectors. 2) Each box in the tree gets allocated 5 style structs over and above the base style struct. This allows for storing dynamic pseudo class styles for later matching. [After extracting an auxiliary style struct from the CSS code, the box generation mechanism compares the auxiliary struct with the base one. If they match, the auxiliary is discarded] 3) :link and :visited may be trivially determined by considering the current href parameter to box_construct_*. If it is non-NULL, then the :link pseudo class must be in operation; it is then simply a question of determining if the link has been visited before. For this, urldb is queried. Any match results in the :visited pseudo class being used. As :link and :visited are mutually exclusive, we can simply incorporate the appropriate style information into the base style struct. This does, unfortunately, cause visiting a link and then clicking back to not react to the changed visited state. 4) Dynamic pseudo classes (currently only :hover and :active) are processed later in the core browser's mouse handling code. When a mouse event occurs, an attempt is made to match the dynamic pseudo classes by manipulating the style of any box under the current mouse position. The changed boxes are inserted into a list for restoring to their default state at a later point. The boxes in question are then forcibly redrawn. The outcome of this test code is this: 1) Static pseudo classes (i.e. :link, :visited and :first-child) are relatively simple to support. First-child has already been supported for some time (as this information can be trivially determined from the XML tree). :link and :visited have very little impact upon box tree generation if they are incorporated into each box's style struct as appropriate. Dynamic updating of the visited state wouldn't be possible in this scheme, however. 2) Dynamic pseudo classes are out. There's no way to support them without some major work on the layout engine and CSS code. This won't happen before 1.0, so I suggest postponing these until then. 3) The language pseudo class is also something I suggest ignoring until after 1.0. 4) The :first-line and :first-letter pseudo elements would be possible with a small amount of effort but I'm not sure that this is desireable before 1.0. 5) The :before and :after pseudo elements would be possible to implement (and are required for generated content). As these elements would be processed at box tree creation time it would be a case of generating the required boxes and inserting them into the tree; the style information could then be discarded. Generated Content and Lists --------------------------- The reason that generated content is on the plan for 1.0 is mainly my fault. I've always believed that the simplest way to get proper list support is to implement content generation and then put together some default stylesheet rules to produce the right kind of output. Some time ago, Richard produced some code to do counter generation. This is sat in the render/ directory of the source tree, but is currently unused. Lists will obviously require something of this kind of functionality. The CSS specification also contains a display property value of "list-item" which, if implemented, would provide the appropriate content and marker separation that lists expect but would not, alone, provide all the required features for lists. For ordered lists, we would require some internal usage of the counter code, too. The 3 list properties would also need implementing. Generated content, on the other hand, is rather more generic but does not necessarily cater for the specific semantics of lists. The question is; which is the one to go for? [NB: if we choose display: list-item and friends, all the nonsense about pseudo selectors can probably be postponed until after 1.0. Whether this has any bearing on the situation, I don't know]. John.