Overly-aggressive changes to setStyleName in 1.4

[Joel Webber]

All,

A while back, we made a set of changes to the behavior of UIObject.setStyleName() and its related methods. The idea was to normalize existing practice by defining the concept of a 'base' style name that is used as a prefix on 'dependent' style names. This is a useful pattern because it gets around issues created by the anemic css selectors in IE.

For example, a widget that needs to several orthogonal aspects to its style would do something like this:

styleName = 'myWidget myWidget-focused myWidget-disabled'

With these styles defined like so:

.myWidget { /* basic stuff common to all states */ }

.myWidget-focused { /* focus highlight */ }

.myWidget-disabled { /* turn the text gray, perhaps */ }

If we had instead defined the style name like this:

styleName = 'myWidget focused disabled'

We would have no reliable way of specifying a rule like this:

(.myWidget && .focused) { }

(that's not valid CSS syntax, of course, but it's also inexpressible in a cross-browser manner)

Given how commonly this sort of structure is needed, and given that it can be kind of a pain to implement this by hand, we decided to codify the concept of a base style name directly into UIObject. This way, if you do something like setStyleName("yourWidget") to the above sample, it would update the class name to be "yourWidget yourWidget-focused yourWidget-disabled".

The mistake we made, I think, is assuming that everyone would want to use this structure, and that we could make a breaking change to UIObject.setStyleName(). What I'd like to propose is that we back that change out (leaving setStyleName() to just clobber the entire class name, like it used to), and add get/setBaseStyleName() methods instead. This way, old code would continue to work as it always has, and widgets that want to use this structure can do so easily.

If no one has any objections to raise about this change, I'll send out a change list within the next day or two.

 

Thanks,

joel.

[Sandy McArthur]

No objections, just a thought that maybe this would feature would best
live in a utility class designed for managing element's CSS Classes.

--
Sandy McArthur

"He who dares not offend cannot be honest."
- Thomas Paine

[o...@out.to]

Hi Joel,

I think your suggestion is fine and will suit current and future GWT
developers best.

However, the most problematic change to the whole style handling is
that in the current 1.4 RC 1 implementation, removeStyleName() throws
an IllegalArguementException if the last (base) style is to be
removed. IMO that is unfortunate in two ways:

1.) it breaks current applications to the point that they do not work
anymore (e.g. ours dies when an IllegalArguementException is thrown,
because in other context of the code it means that something went
terribly wrong)

2.) it leaves the checking whether the style to be removed is allowed
to be removed up to the caller

If removeStyleName() should not leave the className empty, then maybe
it should either just not remove the last style, or replace it with
the "gwt-nostyle" name. Maybe if setStyleName() is left as it was
before, so should removeStyleName().

[Ian Petersen]

On 7/2/07, Joel Webber <j...@google.com> wrote:

> If we had instead defined the style name like this:
>
> styleName = 'myWidget focused disabled'
>
> We would have no reliable way of specifying a rule like this:
>
> (.myWidget && .focused) { }
>
> (that's not valid CSS syntax, of course, but it's also inexpressible in a
> cross-browser manner)

I'm a bit late to the party here, but are you saying that the
following CSS is not cross-browser?

.myWidget.focused {
/* styles here */
}

It's been a while, but I could have sworn that syntax works.

Ian

--
Tired of pop-ups, security holes, and spyware?
Try Firefox: http://www.getfirefox.com

[Joel Webber]

I sure wish it did. This unfortunately does not work on IE :(

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Google Web Toolkit Contributors" group.
To post to this group, send email to Google-Web-Toolkit-Contributors...@googlegroups.com
To unsubscribe from this group, send email to Google-Web-Toolkit-Contributor s-unsu...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit-Contributors?hl=en
-~----------~----~----~----~-- ----~----~------~--~---

[Mat Gessel]

At first, it may seem like it works; but when you add more rules you
find that IE is applying styles where it shouldn't. IE will apply the
rule to any element using the last class.

So PushButton.pressed is treated as .pressed. This works fine until
you decide that you want to apply a different style to
ToggleButton.pressed.

http://www.quirksmode.org/css/multipleclasses.html

--
Mat Gessel
http://www.asquare.net/gwttk/

On 7/4/07, Ian Petersen <ispe...@gmail.com> wrote:

[stuckagain]

Ah great that somebody notices this!

One of my widgets no longer works because of this change.
When the widget had some secondary style attached I could no longer
remove
that style by just using setStyleName. It took me an hour or so to
realize that the
behaviour changed this dramatically.

[Fred Sauer]

On 7/4/07, Joel Webber <j...@google.com> wrote:

I sure wish it did. This unfortunately does not work on IE :(

This IE bug appears to be present only in quirks mode, at least as far as IE7 goes. There's some additional info in the "multi-class selectors" section at http://blogs.msdn.com/ie/archive/2005/09/02/460115.aspx .

+1 reason for GWT strict (standards) mode support/endorsement :-)

Fred


 

On 7/4/07, Ian Petersen <ispe...@gmail.com> wrote:

On 7/2/07, Joel Webber <j...@google.com> wrote:
> If we had instead defined the style name like this:
>
>  styleName = 'myWidget focused disabled'
>
> We would have no reliable way of specifying a rule like this:
>
> (.myWidget && .focused) { }
>
>  (that's not valid CSS syntax, of course, but it's also inexpressible in a
> cross-browser manner)

I'm a bit late to the party here, but are you saying that the
following CSS is not cross-browser?

.myWidget.focused {
/* styles here */
}

It's been a while, but I could have sworn that syntax works.

Ian

--
Tired of pop-ups, security holes, and spyware?
Try Firefox: http://www.getfirefox.com

--
Fred Sauer
fr...@allen-sauer.com

[Joel Webber]

If only they could have fixed it in IE6... I guess we're stuck with it until IE6 dwindles away to nearly nothing (sometime in the next geologic era). Argh!

--~--~---------~--~----~------------~-------~--~----~

You received this message because you are subscribed to the Google Groups "Google Web Toolkit Contributors" group.

To post to this group, send email to Google-Web-Toolkit-Contributors@googlegroups.com
To unsubscribe from this group, send email to Google-Web-Toolkit-Contributors -unsub...@googlegroups.com

[Miroslav Pokorny]

You could synthesis rules to help IE. After a stylesheet loads (re)write its rules for ie...I believe IE7 by Dean Edwards does something similar to cater for similar issues.

--
mP

[Joel Webber]

It might indeed be a good idea to come up with slightly higher-order styles in GWT that would allow us to synthesize such rules. Even cooler would be the ability to generated optimized CSS for an application, dead-stripping, rewriting rules, etc. I believe Kelly's been batting around an idea for 'style bundles' that might allow something like this, but it's probably a way off yet.

joel.