CSS conventions for gwt-commons
Essington
type of style for each UI Widget included in gwt-commons so those
widgets could be used out of the box so to speak.
I have been thinking a bit about how we could supply default style
without wrecking user efforts to style the widgets.
The first thing I thought, was that we should have someone come up with
a "theme" that includes a color pallet and maybe anything else that
would be used for styling widgets in gwt-commons.
Then we should decide on CSS style naming conventions for gwt-commons.
I think that naming should attempt to be intuitive, and consistent
across the library. All gwt-commons UI elements should either have a
consistent class, or prefix for every named component.
GWT uses the gwt- prefix for all of its widgets. we could use a prefix
like gwt does (maybe gwtc- or gcomm-) or we could use an additional
classname again something like (gwtc or gcomm). I like the idea of
using the additional classname, but it is something we should decide
upon.
for instance if we had a Foo widget that had a title and a sidebar the
css might go something like:
have classes like:
gwtc-foo
gwtc-title
gwtc-sidebar
but then the selectors end up with a lot of gwtc- littered around them.
but if we used additional classnames we could have:
gwtc.foo
gwtc.title
gwtc.sidebar
then the selector could be simpler
.gwtc.foo .title rather than .gwtc-foo .gwtc-title
Then if there was some side of overlap or classname conflict, the extra
class could be used to specify ...
.gwtc.foo .sidebar rather than .gwtc-foo .gwtc-sidebar
or if you wanted to style all the titles in commons
.gwtc.title rather than .gwtc-title
Once we decide on standards for css naming, every widget should have a
sample style sheet written for it using the pallet from the commons
theme.
these stylesheets could be placed in a common place in all commons
modules ( public/defaultStyle/ for instance) but they shouldn't be
given a <stylesheet> tag in the modules gwt.xml (or the stylesheet tag
should be added, but commented out). With these default stylesheets, a
user could either cut and paste the style from the supplied css, and
edit it to their needs, or they could just add the <stylesheet> tag to
their gwt.xml.
This solution would also make it very simple to exclude all the default
style css from a build by using an excludes element in a <public> tag
of the users gwt.xml file.
<public path='public' excludes='**/defaultStyle/*.css' />
Anyone else have any thoughts?
-jason
Robert Hanson
> The first thing I thought, was that we should have
> someone come up with a "theme" that includes
> a color pallet
I agree, but is there anyone on the list also a designer?
> Then we should decide on CSS style naming
> conventions for gwt-commons. I think that naming
> should attempt to be intuitive, and consistent
> across the library.
Agreed. I don't have any strong personal preferences with regard to
naming, but maybe someone else does.
> these stylesheets could be placed in a common place
> in all commons modules ( public/defaultStyle/ for instance)
> but they shouldn't be given a <stylesheet> tag in the
> modules gwt.xml (or the stylesheet tag should be added,
> but commented out).
Yes, defaultStyle is good... or maybe commonsStyle? And I agree, it
should not be automatic.
> This solution would also make it very simple to
> exclude all the default style css from a build by using
> an excludes element in a <public> tag
Yes, that makes a lot of sense.
Rob
mP
.gwtc-foo .gwtc-sidebar rather than .gwtc.foo .sidebar.
This helps avoid any potential clashes. I also like to have all my
classnames in a single class file ... this way its all centralised and
easily modified...
ash
im severely style challenged and still wear clothes from the 80s.
---
i like the concept of themes, but i am unclear how you plan on
implementing it.
i would prefer to see a prototype in code to get my head around it
rather that u trying to write about it.
i also figure that u and mP are passionate about this topic, so im
happy to go with both of your conclusions.
understanding it is the bonus for me.
btw, i created a sandbox area for the commiting team. feel free to use
it to codify your ideas.
if we want a deliverable out by year end, then the sooner we get
concrete with stuff, the better.
rgds ash
http://www.gworks.com.au
Robert Hanson
> implementing it.
He isn't proposing anything special. Just a single CSS (MP) in the
public/commonsStyle (RH) directory.
This CSS would NOT be imported by default (JE). The user would need
to add the appropriate <link> to the HTML or <stylesheet> element to
the module config.
All CSS class names would be prefixed with "gwtc-" (JE/MP) to avoid
naming conflicts with user-defined CSS class names.
If the user was using their own CSS file and not a theme, then they
could exclude the CSS files from their project with the following line
(JE).
<public path='public' excludes='**/commonsStyle/*.css' />
Does that help? Does anyone not agree with this?
Rob
Essington
On Nov 19, 8:27 pm, "mP" <miroslav.poko...@gmail.com> wrote:
> I believe all stylenames(aka classnames) should be fully qualified..
>
> .gwtc-foo .gwtc-sidebar rather than .gwtc.foo .sidebar.
Well, if we use separate class names then you can still "fully qualify"
the names
.gwtc.foo .gwtc.sidebar ...
The difference is if you use a Bar widget as the sidebar in Foo, you
could specify:
gwtc.foo .gwtc.bar.sidebar rather than .gwtc-foo .gwtc-bar.gwtc-sidebar
I just like the idea of separate classnames. It seems a bit more
flexable, but may be a non-issue in the big picture.
> This helps avoid any potential clashes. I also like to have all my
> classnames in a single class file ... this way its all centralised and
> easily modified...
At first this sounds reasonable, but as the library grows I think it'll
become a bit difficult to deal with.
If I need to modify or add a classname for Foo, and all classnames are
in some constant file, I have to go find that file, then find in that
file where the foo constants are, before I can even begin to add the
foo constant. This is also a bit of a namespace nightmare. there is no
separation between all the constants, so any class that attempts to
access any one constant gets all of the constants.
This is akin to storing every instruction manual for all of the garage
doors in town in one big box in the bank across town. If you want your
instructions, you've gotta go to the bank, and dig through everyone
else's instructions before you can get to yours. I don't know about
you, but I keep my garage door instructions in the house with the rest
of the appliance instructions :-)
I wouldn't be above having constants that are used by many classes
stored in a central place.
and again the separate classname scheme would be reasonable here
something like:
public class Foo extends Widget
public static final String STYLE_FOO_WIDGET = "foo";
public Foo(){
super(DOM.createDif());
setStyleName(StyleConstants.STYLE_GWT_COMMONS);
addStyleName(STYLE_FOO_WIDGET);
}
}
It wouldn't require contributers to modify non-related parts (the
external style constant class) of the library to submit a Widget. Any
style classes used by their class are located in their class, and not
in a common style class.
The only benefit I could see with placing all the styles in a central
location would be to allow making wholesale changes to the names. This
would be a breaking change for anyone using the library, and we don't
need to facilitate such things through design.
-jason
Essington
On Nov 20, 3:28 am, "ash" <ash...@gmail.com> wrote:
> jason,
>
> im severely style challenged and still wear clothes from the 80s.
not to worry, blue jeans and t-shirts will always be in style :-)
>
> ---
>
> i like the concept of themes, but i am unclear how you plan on
> implementing it.
basically I said "Theme" because I didn't really have a better word.
What I meant is that we should decide on a specific color pallet,
document that pallet, and use only that pallet when creating the
default/example css for a given gwt-commons widget. That way, all the
widgets in gwt-commons will appear to be cohesive rather than a
disparate set of unrelated parts.
> > i would prefer to see a prototype in code to get my head around it
> rather that u trying to write about it.
I'll try to modify my Rounded Corner widget as an example, and submit
it to the sandbox today sometime.
> > i also figure that u and mP are passionate about this topic, so im
> happy to go with both of your conclusions.
When we reach a consensus :-)
And this is just css ... we haven't even started talking about code
style yet ...
Essington
> it to the sandbox today sometime.
o.k. here's a fully functional widget, and stylesheet, with comments to
boot:
http://gwt-commons-sandbox.googlecode.com/svn/branches/jason/gwt-commons/src/org/gwtcommons/user/
I didn't add a gwt.xml file (module definition) or anything, I just
wanted to get this up to show what I had in mind.
It would be nice if we could settle on a particular template for class
level comments as well (and also require that every public/protected
method and constructor be commented). What I have included in this
widget is just a suggestion.
The included sample CSS also shows many of the possible selectors that
would be used with the widget.
-jason
Andre Freller
I agree that we first have to discuss coding styles so I'm going to add my comments to Jason's page:
http://groups-beta.google.com/group/gwt-commons/edit/code-style?hl=en
Regards,
Freller
ash
> First let me introduce my self. I leave in Brazil and am currently working
> on big on line airline ticketing system for travel agencies only. I work
> with Java since 1996 and before that Perl and C back to 1984. We decided to
thx for taking the time to introduce yourself. good to see some other
poor sucker here of a similar vintage to myself. the y-generation tends
to want to lock us up in a mental asylum. in my case thats probably
preferable. pls continue to provide feedback and contribute where
possible. im listening...
i now know more about u than i know about the other guys here (except
for ian and mP). i can imagine what they are like through their
community work. their postings have provided good signal on what they
are like, what they value and how much they care.
> very happy to see this initiative and I hope to contribute to it.
glad to c that we share a goal.
> I agree that we first have to discuss coding styles so I'm going to add my
i prefer to do other things first. coding styles will follow
eventually, but that is just my approach.
best wishes ash
http://www.gworks.com.au
Andre Freller
On 11/23/06, ash <ash...@gmail.com> wrote:
>
> good to see some other poor sucker here of a similar vintage to myself.
> the y-generation tends to want to lock us up in a mental asylum.
Tell me about it! The good part is that they stop arguing with pity ...
> > I agree that we first have to discuss coding styles so I'm going to add my
> i prefer to do other things first. coding styles will follow
> eventually, but that is just my approach.
Fare enough, so what do you think should be our priority and following steps?
[]'s
Freller