Simon Lessard wrote:
Hello all,
Well, at first I made it that way beause dual pseudo-element was
completely
removed because it was buggy.
yep, we never had keys with multi-pseudo-elements, so it wasn't written
to support it.
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
You would map af|train::link to af|navigationItem.
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.
The parser would have to change, definitely to support it.
We can leave this issue alone for now, since there are so many more
important issues to work out.
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
