Hello all, Well, at first I made it that way beause dual pseudo-element was completely removed because it was buggy. However, now that it was made that way I don't dislike it. It depends how you see the link I guess, both have a semantic sense. That being said, on a practical side, the current version is much easier since the link rendering is deferred to the navigationItem renderer so pushing complex style class in it can be problematic. For instance, how would it be possible to emulate the following using resource map?
af|train::stop:unvisited:read-only af|train::link The new version of the selector would be af|train::stop:unvisited:read-only::link, but I don'T know if the current architecture could support that. Regards, ~ Simon On 10/4/06, Jeanne Waldman <[EMAIL PROTECTED]> wrote:
I wonder if we should support multiple pseudo-elements. That is, I wonder if : af|train::stop af|train::link af|train::overflow-start af|train::link af|train::overflow-end af|train::link would make more css-sense if the skinning definition was instead af|train::stop::link af|train::overflow-start::link af|train::overflow-end::link The top bunch seems to say "style the train's link for the train that is inside the other train's stop". Up until now I have said that multiple pseudo-elements is illegal. I don't see it used in the css spec at all. But it seems to me that it fits the css syntax more than the top definition. What do people think? Some background: I used to have this: af|inputText:disabled af|inputText::content and a team member pointed out that it makes more css sense to have this: af|inputText:disabled::content. So I changed the definition to be af|inputText:disabled::content, but the parser still parses it to af|inputText:disabled af|inputText::content and it gets generated to .af_inputText.p_AFDisabled .af_inputText_content. Pavitra Subramaniam wrote: >I didn't realize that it was going to be used this way. We don't need the stop-link like I suggested. > >Thanks >- Pavitra
