I might be assuming something that is not correct, so let me ask,
in the case of the train, what part is delegating to the navigationItem
renderer?
I'm assuming the af|train::link part.
So, regardless of the skinning syntax (af|train::stop::link or
af|train::stop af|train::link)
you would map af|navigationItem to af|train::link.
The af|train::stop/p_AFUnvisited, and p_AFReadOnly are still within the
train
renderer, right? So there is no need put those on the resource map.
If we used af|train::stop::link format, the css parser would break it
apart, and it would end up
to be the same as if the skinner wrote af|train::stop af|train::link.
Same with af|train::stop:unvisited:read-only::link.
We'd break it apart and make it be:
af|tarin::stop:unvisited:read-only af|train::link
It's like how the user types this:
af|inputText:read-only::content
and we resolve it to this:
af|inputText:read-only af|inputText::content
- Jeanne
Simon Lessard wrote:
Linking af|train::link to navigation item alone would not be enough with
af|train::stop::link.
This is currently what I use, another why I used a single selecor for all
links.
However take af|train::stop:unvisited:read-only::link
The only way I see would be to set all 3 selectors on the resource map
(af|train::stop::link, p_AFUnvisited and p_AFReadOnly) for both link
seletors (disabled and normal). The main disadvantage with that is
that it
requires the use of one map instance per station being rendered, which
will
be much less efficient than the currently singleton map.
Regards,
~ Simon
On 10/4/06, Jeanne Waldman <[EMAIL PROTECTED]> wrote:
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
>>
>
