Attribute merging

[Peter Brant]

Hi all,

There have been three issues related to CSS transforms that have come
up with 2.4-M4. All three of them are related to attribute merging.
Nothing actually changed with attribute merging in 2.4-M4, but it
became more visible due to a bug fix in the 2.4-M4 cycle. I have what
I think is a good fix for one of the issues, but for the other two I'm
not sure what the appropriate fix is.

More generally, if we could come up with a spec for attribute merging,
that would be great. Once we have that, I'll change the code to
match.

References:

Quote from dpp on attribute merging:

... snip ...
One of the biggest complaints about Helpers.bind() was that it did *not*
merge attributes. Basically, designers would do something like <input
name="firstname" class="foo bar" id="baz"> and then in the CSS Selector
Transforms, you do: "name=firstname" #> SHtml.text(name, name = _) and you
*want* the attributes merged.
... snip ...

from thread http://groups.google.com/group/liftweb/browse_thread/thread/184b7eb51d461b30
(discussing one of the two outstanding issues).

The other outstanding issue: http://www.assembla.com/spaces/liftweb/tickets/1111

Pete

[David Pollak]

Okay... here are my thoughts:

• If an attribute exists on the original Elem then that attribute should be copied to the substituted elem unless (1) the substituted elem has an attribute of the same name; or (2 [new feature]) the CSS Selector Transform explicitly discards the original attributes.
• The class attribute is special in that merging class attributes means adding together the space-separated class names.  This allows for <input class="foo">/"input" #> SHtml.text("", println _, "class" -> "bar") ==> <input class="foo bar">; We can allow overriding the class merging as a new feature.  This means that the 2.4-M4 behavior is correct in Ticket 1111
  

What do you think?

--
Lift, the simply functional web framework: http://liftweb.net
Code: http://github.com/lift
Discussion: http://groups.google.com/group/liftweb
Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code

--
Lift, the simply functional web framework http://liftweb.net

Simply Lift http://simply.liftweb.net
Follow me: http://twitter.com/dpp
Blog: http://goodstuff.im

[Jeppe Nejsum Madsen]

David Pollak <feeder.of...@gmail.com> writes:

> Okay... here are my thoughts:
>

> - If an attribute exists on the original Elem then that attribute should

> be copied to the substituted elem unless (1) the substituted elem has an
> attribute of the same name; or (2 [new feature]) the CSS Selector Transform
> explicitly discards the original attributes.

Sounds about right. Why add attributes to the original Elem if they are not
used?

> - The class attribute is special in that merging class attributes means

> adding together the space-separated class names. This allows for <input
> class="foo">/"input" #> SHtml.text("", println _, "class" -> "bar") ==>
> <input class="foo bar">; We can allow overriding the class merging as a new
> feature.

Why treat class as a special case, it seems to go against the first
point? We already have

- [attr] (e.g., "#id [href]") replaces the matching attribute’s value with
the values.
- [attr+] (e.g., "#id [class+]") appends the value to the existing
attribute.

I can see why it can be convenient to merge the class values, but it also
seems a bit inconsistent.

> This means that the 2.4-M4 behavior is correct in Ticket 1111

Hmm, why the difference between the tr & td class attrs? The tr is
merged, but the td replaced?

/Jeppe

[Peter Petersson]

On 2011-09-20 01:40, David Pollak wrote:

Okay... here are my thoughts:

• If an attribute exists on the original Elem then that attribute should be copied to the substituted elem unless (1) the substituted elem has an attribute of the same name; or (2 [new feature]) the CSS Selector Transform explicitly discards the original attributes.
• The class attribute is special in that merging class attributes means adding together the space-separated class names.  This allows for <input class="foo">/"input" #> SHtml.text("", println _, "class" -> "bar") ==> <input class="foo bar">; We can allow overriding the class merging as a new feature.  This means that the 2.4-M4 behavior is correct in Ticket 1111
  

I hope its okey that I jump in and elaborate a bit on what ticket 1111 come from to give a picture on why the simplified example look like it dose and why it is desirable to have the attributes just like they are in the template but produce (transform) it to the result it gave in M3. If there is currently no other way to express the desired behavior (small changes to the transformation code) of the transforms in 1111 to behave like in M3 then a new feature like allowing for overriding wold be a appreciated feature and maybe a necessity to be able to give designers a good amount of expressive freedom in the designer friendly templates. I am a newbie on Lift so I may be wrong.

While working together with designers I would like to keep the designer friendly templates "look and feel" as close as possible to the outcome and in the case from where ticket 1111 come the designer friendly template contains class attribute in the tables th tag that alternate between 2 repeating values to give alternating colors on the table rows and also to give the correct mouseover and mouseout behavior in the template wile showing 3 rows (2 clearable) to the designer to let him express the intended design (look and feel) of the table.

As I am quite new to Lift and Scala and only newly have started to work with it, learning "by doing" wile porting a old java servlet based project into Lift there are naturally a lots of things about Lift I am still to discover, things that can be done in better and different ways given the expressive power of Lift (and Scala) so the above is my thoughts based on my current knowledge of Lift. 
Lift:s Designer Friendly Templates and CSS transforms rocks, I am still a bit stunned by the expressive power of Lift, enjoining every moment working with it.

best regards
Peter Petersson

[Peter Petersson]

... and also in this context it feels natural to me that [class+] would mean that I want to merge and [class] that I want to discards and replace.
best regards
  Peter Petersson

[Peter Brant]

Yeah, I was wondering that too.

Pete

[dave]

The selector is replacing <tr class="even"> with <tr class="odd">. By
the current rules, element replacement results in attribute merging,
hence the merged class attribute.

The td's are modified using attribute replacement, not element
replacement. Attribute merging does not apply.

I believe the rule is that attribute merging only occurs when an
element is replaced by another element. When you replace content
children, attributes, append, prepend, lift, etc. then attribute
merging does not happen. (Can someone more certain of that confirm
for me?)

dave

[dave]

On Sep 19, 6:40 pm, David Pollak <feeder.of.the.be...@gmail.com>
wrote:

> Okay... here are my thoughts:
>

>    - If an attribute exists on the original Elem then that attribute should

>    be copied to the substituted elem unless (1) the substituted elem has an
>    attribute of the same name; or (2 [new feature]) the CSS Selector Transform
>    explicitly discards the original attributes.

+1

Merging attributes by default still catches me off guard, but I'll
learn eventually :-)

>    - The class attribute is special in that merging class attributes means

>    adding together the space-separated class names.  This allows for <input
>    class="foo">/"input" #> SHtml.text("", println _, "class" -> "bar") ==>
>    <input class="foo bar">; We can allow overriding the class merging as a new
>    feature.  This means that the 2.4-M4 behavior is correct in Ticket 1111

+1

Makes perfect sense. Since class is a special attribute (being a
space separated list of values), merging this way is the least
surprising thing to do.

dave
<><

[David Pollak]

On Tue, Sep 20, 2011 at 12:37 AM, Jeppe Nejsum Madsen <je...@ingolfs.dk> wrote:

David Pollak <feeder.of...@gmail.com> writes:

> Okay... here are my thoughts:
>
>    - If an attribute exists on the original Elem then that attribute should
>    be copied to the substituted elem unless (1) the substituted elem has an
>    attribute of the same name; or (2 [new feature]) the CSS Selector Transform
>    explicitly discards the original attributes.

Sounds about right. Why add attributes to the original Elem if they are not
used?

Because the original <input name="fred" class="foo"> may not include an onblur that's added by SHtml.ajaxText().  We want to merge the two attribute sets where the right hand side wins the merge.

 

>    - The class attribute is special in that merging class attributes means

>    adding together the space-separated class names.  This allows for <input
>    class="foo">/"input" #> SHtml.text("", println _, "class" -> "bar") ==>
>    <input class="foo bar">; We can allow overriding the class merging as a new
>    feature.

Why treat class as a special case, it seems to go against the first
point?

Because the browser treats class attributes differently... as a space-delimited set of classes.  The CSS Selector Transform behavior is intended to reflect this.

 

We already have

- [attr] (e.g., "#id [href]") replaces the matching attribute’s value with
the values.
- [attr+] (e.g., "#id [class+]") appends the value to the existing
attribute.

I can see why it can be convenient to merge the class values, but it also
seems a bit inconsistent.

>    This means that the 2.4-M4 behavior is correct in Ticket 1111

Hmm, why the difference between the tr & td class attrs?  The tr is
merged, but the td replaced?

Because the selector is "tr"

 

/Jeppe

--

Lift, the simply functional web framework: http://liftweb.net
Code: http://github.com/lift
Discussion: http://groups.google.com/group/liftweb
Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code

[David Pollak]

On Wed, Sep 21, 2011 at 10:06 AM, dave <leed...@yahoo.com> wrote:

The selector is replacing <tr class="even"> with <tr class="odd">.  By
the current rules, element replacement results in attribute merging,
hence the merged class attribute.

The td's are modified using attribute replacement, not element
replacement.  Attribute merging does not apply.

I believe the rule is that attribute merging only occurs when an
element is replaced by another element.  When you replace content
children, attributes, append, prepend, lift, etc. then attribute
merging does not happen.  (Can someone more certain of that confirm
for me?)

Yeah.. that's right.

 

dave

<><

On Sep 20, 4:18 am, Peter Brant <peter.br...@gmail.com> wrote:
> Yeah, I was wondering that too.
>
> Pete
>

> On Tue, Sep 20, 2011 at 9:37 AM, Jeppe Nejsum Madsen <je...@ingolfs.dk> wrote:
>
> > Hmm, why the difference between the tr & td class attrs?  The tr is
> > merged, but the td replaced?

--
Lift, the simply functional web framework: http://liftweb.net
Code: http://github.com/lift
Discussion: http://groups.google.com/group/liftweb
Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code

[David Pollak]

On Tue, Sep 20, 2011 at 12:44 AM, Peter Petersson <peterss...@gmail.com> wrote:

On 2011-09-20 01:40, David Pollak wrote:

Okay... here are my thoughts:

• If an attribute exists on the original Elem then that attribute should be copied to the substituted elem unless (1) the substituted elem has an attribute of the same name; or (2 [new feature]) the CSS Selector Transform explicitly discards the original attributes.
• The class attribute is special in that merging class attributes means adding together the space-separated class names.  This allows for <input class="foo">/"input" #> SHtml.text("", println _, "class" -> "bar") ==> <input class="foo bar">; We can allow overriding the class merging as a new feature.  This means that the 2.4-M4 behavior is correct in Ticket 1111
  

I hope its okey that I jump in and elaborate a bit on what ticket 1111 come from to give a picture on why the simplified example look like it dose and why it is desirable to have the attributes just like they are in the template but produce (transform) it to the result it gave in M3. If there is currently no other way to express the desired behavior (small changes to the transformation code) of the transforms in 1111 to behave like in M3 then a new feature like allowing for overriding wold be a appreciated feature and maybe a necessity to be able to give designers a good amount of expressive freedom in the designer friendly templates. I am a newbie on Lift so I may be wrong.

While working together with designers I would like to keep the designer friendly templates "look and feel" as close as possible to the outcome and in the case from where ticket 1111 come the designer friendly template contains class attribute in the tables th tag that alternate between 2 repeating values to give alternating colors on the table rows and also to give the correct mouseover and mouseout behavior in the template wile showing 3 rows (2 clearable) to the designer to let him express the intended design (look and feel) of the table.

If we have the "don't merge" flag, then I think we'll cover a bunch of ground.

Also, it might be worth having have a semantic for doing the cyclical application of class and other attributes.  For example: "td *" #> List("hey", "dude", "frog", "moose") will result in 4 <td> elements.  I think it would be helpful to have a mechanism for piping the expanded <td>s into "td [class+]" cycleThrough List("odd", "even") which would take the collection on the right hand side and the collection found from the left hand side and applied the rule in a cycle (odd, even, odd, even).

[Peter Petersson]

hi Dave

Thanks for the clarification, sry for intervene with a newbie question
So what you are saying is that

"tbody *" #> ( "tr" #> m.map(n => ".even [class]" #> Text("odd") ) )

is doing a transformation on the TD by using the ".even [class]"
(attribute replacement rule) that results in the attribute replacement
(easy to understand) but for the parent TR elem this transformation
expression would act like the TR had a implicit ".even [class+]"
(attribute merge rule) on it but thats just an illusion as it is
actually the element replacement rule that kicks in on the "TR" element
so that transformation of the element "<tr class="even">" correctly (by
the element replacement rule) results in the class attribute merge....
this has been harder to grasp but the thought is sinking in and it
starts to make sense ;-)

But now, how would you go about to change this transformation expression
(I guess a fairly common one) to produce a replacement also on the tr
(as it did in M3)?
Preferably without changing the template code.

best regards
Peter Petersson

>>> Hmm, why the difference between the tr& td class attrs? The tr is

[David Pollak]

On Wed, Sep 21, 2011 at 11:48 AM, Peter Petersson <peterss...@gmail.com> wrote:

hi Dave

Thanks for the clarification, sry for intervene with a newbie question
So what you are saying is that

"tbody *" #> ( "tr" #> m.map(n => ".even [class]" #> Text("odd") ) )

is doing a transformation on the TD by using the ".even [class]" (attribute replacement rule) that results in the attribute replacement (easy to understand) but for the parent TR elem this transformation expression would act like the TR had a implicit ".even [class+]" (attribute merge rule) on it but thats just an illusion as it is actually the element replacement rule that kicks in on the "TR" element so that transformation of the element "<tr class="even">" correctly (by the element replacement rule) results in the class attribute merge.... this has been harder to grasp but the thought is sinking in and it starts to make sense ;-)

But now, how would you go about to change this transformation expression (I guess a fairly common one) to produce a replacement also on the tr (as it did in M3)?

"tbody *" #> (".even [class]" #> "odd")

 

Preferably without changing the template code.

best regards
 Peter Petersson

On 2011-09-21 19:06, dave wrote:

The selector is replacing<tr class="even">  with<tr class="odd">.  By
the current rules, element replacement results in attribute merging,
hence the merged class attribute.

The td's are modified using attribute replacement, not element
replacement.  Attribute merging does not apply.

I believe the rule is that attribute merging only occurs when an
element is replaced by another element.  When you replace content
children, attributes, append, prepend, lift, etc. then attribute
merging does not happen.  (Can someone more certain of that confirm
for me?)

dave
<><

On Sep 20, 4:18 am, Peter Brant<peter.br...@gmail.com>  wrote:

Yeah, I was wondering that too.

Pete

On Tue, Sep 20, 2011 at 9:37 AM, Jeppe Nejsum Madsen<je...@ingolfs.dk>  wrote:

Hmm, why the difference between the tr&  td class attrs?  The tr is
merged, but the td replaced?

--
Lift, the simply functional web framework: http://liftweb.net
Code: http://github.com/lift
Discussion: http://groups.google.com/group/liftweb
Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code

[Peter Petersson]

On 2011-09-21 19:55, David Pollak wrote:

On Tue, Sep 20, 2011 at 12:44 AM, Peter Petersson <peterss...@gmail.com> wrote:

On 2011-09-20 01:40, David Pollak wrote:

Okay... here are my thoughts:

• If an attribute exists on the original Elem then that attribute should be copied to the substituted elem unless (1) the substituted elem has an attribute of the same name; or (2 [new feature]) the CSS Selector Transform explicitly discards the original attributes.
• The class attribute is special in that merging class attributes means adding together the space-separated class names.  This allows for <input class="foo">/"input" #> SHtml.text("", println _, "class" -> "bar") ==> <input class="foo bar">; We can allow overriding the class merging as a new feature.  This means that the 2.4-M4 behavior is correct in Ticket 1111
  

I hope its okey that I jump in and elaborate a bit on what ticket 1111 come from to give a picture on why the simplified example look like it dose and why it is desirable to have the attributes just like they are in the template but produce (transform) it to the result it gave in M3. If there is currently no other way to express the desired behavior (small changes to the transformation code) of the transforms in 1111 to behave like in M3 then a new feature like allowing for overriding wold be a appreciated feature and maybe a necessity to be able to give designers a good amount of expressive freedom in the designer friendly templates. I am a newbie on Lift so I may be wrong.

While working together with designers I would like to keep the designer friendly templates "look and feel" as close as possible to the outcome and in the case from where ticket 1111 come the designer friendly template contains class attribute in the tables th tag that alternate between 2 repeating values to give alternating colors on the table rows and also to give the correct mouseover and mouseout behavior in the template wile showing 3 rows (2 clearable) to the designer to let him express the intended design (look and feel) of the table.

If we have the "don't merge" flag, then I think we'll cover a bunch of ground.

Thanks David for take time to answer, yea if it simplify a (as i think) fairly common pattern like my cyclic ".odd" ".even" replacement on the TR (and TD) to be expressed in a transform like this it would be great to have it.

"tbody *" #> ( "tr" #> m.map(n => ".even [class]" #> Text("odd") ) )  

I have not come up with a solution for doing what I want with this transform in M4 so I have reverted back to M3 for now.

Also, it might be worth having have a semantic for doing the cyclical application of class and other attributes.  For example: "td *" #> List("hey", "dude", "frog", "moose") will result in 4 <td> elements.  I think it would be helpful to have a mechanism for piping the expanded <td>s into "td [class+]" cycleThrough List("odd", "even") which would take the collection on the right hand side and the collection found from the left hand side and applied the rule in a cycle (odd, even, odd, even).

...would be great, looking forward to see what will emerge from this.
best regards
  Peter Petersson

[Peter Petersson]

On 2011-09-21 21:01, David Pollak wrote:

On Wed, Sep 21, 2011 at 11:48 AM, Peter Petersson <peterss...@gmail.com> wrote:

hi Dave

Thanks for the clarification, sry for intervene with a newbie question
So what you are saying is that

"tbody *" #> ( "tr" #> m.map(n => ".even [class]" #> Text("odd") ) )

is doing a transformation on the TD by using the ".even [class]" (attribute replacement rule) that results in the attribute replacement (easy to understand) but for the parent TR elem this transformation expression would act like the TR had a implicit ".even [class+]" (attribute merge rule) on it but thats just an illusion as it is actually the element replacement rule that kicks in on the "TR" element so that transformation of the element "<tr class="even">" correctly (by the element replacement rule) results in the class attribute merge.... this has been harder to grasp but the thought is sinking in and it starts to make sense ;-)

But now, how would you go about to change this transformation expression (I guess a fairly common one) to produce a replacement also on the tr (as it did in M3)?

"tbody *" #> (".even [class]" #> "odd")

oh my, that brilliant, thanks David I will try it tomorrow.

[Peter Petersson]

On 2011-09-21 21:20, Peter Petersson wrote:

On 2011-09-21 21:01, David Pollak wrote:

On Wed, Sep 21, 2011 at 11:48 AM, Peter Petersson <peterss...@gmail.com> wrote:

hi Dave

Thanks for the clarification, sry for intervene with a newbie question
So what you are saying is that

"tbody *" #> ( "tr" #> m.map(n => ".even [class]" #> Text("odd") ) )

is doing a transformation on the TD by using the ".even [class]" (attribute replacement rule) that results in the attribute replacement (easy to understand) but for the parent TR elem this transformation expression would act like the TR had a implicit ".even [class+]" (attribute merge rule) on it but thats just an illusion as it is actually the element replacement rule that kicks in on the "TR" element so that transformation of the element "<tr class="even">" correctly (by the element replacement rule) results in the class attribute merge.... this has been harder to grasp but the thought is sinking in and it starts to make sense ;-)

But now, how would you go about to change this transformation expression (I guess a fairly common one) to produce a replacement also on the tr (as it did in M3)?

"tbody *" #> (".even [class]" #> "odd")

oh my, that brilliant, thanks David I will try it tomorrow.

So simple yet so powerful, "tbody *" #> ( m.map(n => ".even [class]" #> Text("odd") ) ), works great and I am back on M4 :-)
best regards
Peter

[Peter Petersson]

On 2011-09-21 21:12, Peter Petersson wrote:

On 2011-09-21 19:55, David Pollak wrote:

On Tue, Sep 20, 2011 at 12:44 AM, Peter Petersson <peterss...@gmail.com> wrote:

On 2011-09-20 01:40, David Pollak wrote:

Okay... here are my thoughts:

• If an attribute exists on the original Elem then that attribute should be copied to the substituted elem unless (1) the substituted elem has an attribute of the same name; or (2 [new feature]) the CSS Selector Transform explicitly discards the original attributes.
• The class attribute is special in that merging class attributes means adding together the space-separated class names.  This allows for <input class="foo">/"input" #> SHtml.text("", println _, "class" -> "bar") ==> <input class="foo bar">; We can allow overriding the class merging as a new feature.  This means that the 2.4-M4 behavior is correct in Ticket 1111
  

I hope its okey that I jump in and elaborate a bit on what ticket 1111 come from to give a picture on why the simplified example look like it dose and why it is desirable to have the attributes just like they are in the template but produce (transform) it to the result it gave in M3. If there is currently no other way to express the desired behavior (small changes to the transformation code) of the transforms in 1111 to behave like in M3 then a new feature like allowing for overriding wold be a appreciated feature and maybe a necessity to be able to give designers a good amount of expressive freedom in the designer friendly templates. I am a newbie on Lift so I may be wrong.

While working together with designers I would like to keep the designer friendly templates "look and feel" as close as possible to the outcome and in the case from where ticket 1111 come the designer friendly template contains class attribute in the tables th tag that alternate between 2 repeating values to give alternating colors on the table rows and also to give the correct mouseover and mouseout behavior in the template wile showing 3 rows (2 clearable) to the designer to let him express the intended design (look and feel) of the table.

If we have the "don't merge" flag, then I think we'll cover a bunch of ground.

Thanks David for take time to answer, yea if it simplify a (as i think) fairly common pattern like my cyclic ".odd" ".even" replacement on the TR (and TD) to be expressed in a transform like this it would be great to have it.

"tbody *" #> ( "tr" #> m.map(n => ".even [class]" #> Text("odd") ) )  

I have not come up with a solution for doing what I want with this transform in M4 so I have reverted back to M3 for now.

Just for the record if someone finds it's way in here this is the way to do it (as David pointed out elsewhere in this thread)

"tbody *" #> ( m.map(n => ".even [class]" #> Text("odd") ) )

Ticket #1111 is closed as invalid as this is not a regression from 2.4-M3 to M4.

best regards
  Peter Petersson

[David Pollak]

On Wed, Sep 21, 2011 at 11:28 PM, Peter Petersson <peterss...@gmail.com> wrote:

On 2011-09-21 21:12, Peter Petersson wrote:

On 2011-09-21 19:55, David Pollak wrote:

On Tue, Sep 20, 2011 at 12:44 AM, Peter Petersson <peterss...@gmail.com> wrote:

On 2011-09-20 01:40, David Pollak wrote:

Okay... here are my thoughts:

• If an attribute exists on the original Elem then that attribute should be copied to the substituted elem unless (1) the substituted elem has an attribute of the same name; or (2 [new feature]) the CSS Selector Transform explicitly discards the original attributes.
• The class attribute is special in that merging class attributes means adding together the space-separated class names.  This allows for <input class="foo">/"input" #> SHtml.text("", println _, "class" -> "bar") ==> <input class="foo bar">; We can allow overriding the class merging as a new feature.  This means that the 2.4-M4 behavior is correct in Ticket 1111
  

I hope its okey that I jump in and elaborate a bit on what ticket 1111 come from to give a picture on why the simplified example look like it dose and why it is desirable to have the attributes just like they are in the template but produce (transform) it to the result it gave in M3. If there is currently no other way to express the desired behavior (small changes to the transformation code) of the transforms in 1111 to behave like in M3 then a new feature like allowing for overriding wold be a appreciated feature and maybe a necessity to be able to give designers a good amount of expressive freedom in the designer friendly templates. I am a newbie on Lift so I may be wrong.

While working together with designers I would like to keep the designer friendly templates "look and feel" as close as possible to the outcome and in the case from where ticket 1111 come the designer friendly template contains class attribute in the tables th tag that alternate between 2 repeating values to give alternating colors on the table rows and also to give the correct mouseover and mouseout behavior in the template wile showing 3 rows (2 clearable) to the designer to let him express the intended design (look and feel) of the table.

If we have the "don't merge" flag, then I think we'll cover a bunch of ground.

Thanks David for take time to answer, yea if it simplify a (as i think) fairly common pattern like my cyclic ".odd" ".even" replacement on the TR (and TD) to be expressed in a transform like this it would be great to have it.

"tbody *" #> ( "tr" #> m.map(n => ".even [class]" #> Text("odd") ) )  

I have not come up with a solution for doing what I want with this transform in M4 so I have reverted back to M3 for now.

Just for the record if someone finds it's way in here this is the way to do it (as David pointed out elsewhere in this thread)

"tbody *" #> ( m.map(n => ".even [class]" #> Text("odd") ) )

I'm unclear as to what you are doing with this code.  Why the m.map(....) code?  What's m?  Also, there's no reason to have Text("odd") when "odd" will work just as well.  Why is: "tbody *" #> (".even [class]" #> "odd") not sufficient?

[Peter Petersson]

On 2011-09-22 14:45, David Pollak wrote:

On Wed, Sep 21, 2011 at 11:28 PM, Peter Petersson <peterss...@gmail.com> wrote:

On 2011-09-21 21:12, Peter Petersson wrote:

On 2011-09-21 19:55, David Pollak wrote:

On Tue, Sep 20, 2011 at 12:44 AM, Peter Petersson <peterss...@gmail.com> wrote:

On 2011-09-20 01:40, David Pollak wrote:

Okay... here are my thoughts:

• If an attribute exists on the original Elem then that attribute should be copied to the substituted elem unless (1) the substituted elem has an attribute of the same name; or (2 [new feature]) the CSS Selector Transform explicitly discards the original attributes.
• The class attribute is special in that merging class attributes means adding together the space-separated class names.  This allows for <input class="foo">/"input" #> SHtml.text("", println _, "class" -> "bar") ==> <input class="foo bar">; We can allow overriding the class merging as a new feature.  This means that the 2.4-M4 behavior is correct in Ticket 1111
  

I hope its okey that I jump in and elaborate a bit on what ticket 1111 come from to give a picture on why the simplified example look like it dose and why it is desirable to have the attributes just like they are in the template but produce (transform) it to the result it gave in M3. If there is currently no other way to express the desired behavior (small changes to the transformation code) of the transforms in 1111 to behave like in M3 then a new feature like allowing for overriding wold be a appreciated feature and maybe a necessity to be able to give designers a good amount of expressive freedom in the designer friendly templates. I am a newbie on Lift so I may be wrong.

While working together with designers I would like to keep the designer friendly templates "look and feel" as close as possible to the outcome and in the case from where ticket 1111 come the designer friendly template contains class attribute in the tables th tag that alternate between 2 repeating values to give alternating colors on the table rows and also to give the correct mouseover and mouseout behavior in the template wile showing 3 rows (2 clearable) to the designer to let him express the intended design (look and feel) of the table.

If we have the "don't merge" flag, then I think we'll cover a bunch of ground.

Thanks David for take time to answer, yea if it simplify a (as i think) fairly common pattern like my cyclic ".odd" ".even" replacement on the TR (and TD) to be expressed in a transform like this it would be great to have it.

"tbody *" #> ( "tr" #> m.map(n => ".even [class]" #> Text("odd") ) )  

I have not come up with a solution for doing what I want with this transform in M4 so I have reverted back to M3 for now.

Just for the record if someone finds it's way in here this is the way to do it (as David pointed out elsewhere in this thread)

"tbody *" #> ( m.map(n => ".even [class]" #> Text("odd") ) )

I'm unclear as to what you are doing with this code.  Why the m.map(....) code?  What's m?  Also, there's no reason to have Text("odd") when "odd" will work just as well.  Why is: "tbody *" #> (".even [class]" #> "odd") not sufficient?

Before I stripped down the example code in ticket #1111 to the above it actually did a bunch of stuff with the objects from a "val m: JMap[Integer, aJObject] = ...." hence the m.map stuff. Yea I don't know why I keep wrapping it up in Text ;) bad habit from to much java coding I guess ;).