Item11116: Uniform buttons: add 'foswiki' class names to BUTTON

For BaseSkin I am trying to get buttons created with %BUTTON% styled the same as foswikiButton (plus variants). I am largely done with the CSS, but by supporting both jqXXX and foswikiXxx styles the overhead becomes big: the file gets really big, even compressed.

The simpler way is to let BUTTON emit foswikiXxx class names.

(trunk only)

Patch attached

Actually, the same goes for TABPANE.

-- ArthurClemens - 07 Sep 2011

Aren't jqButtons and foswikiButtons two different things, i.e. quite different wrt markup? The first is stuff emitted via %BUTTON, the second is an html <button ...>.

-- MichaelDaum - 08 Sep 2011

They are but that doesn't matter, the differences can be handled in css. A foswikiButton can be: a, button, input[type=submit].

No html change is needed.

The idea of uniform buttons is that given a skin X, all interface controls have the same look. Skins can implement their own design with CSS.

-- ArthurClemens - 08 Sep 2011

Well, basically I think, we should adopt jquery-ui theming ... which requires widgets to adhere to YANC (yet another naming convention).

I am about to check in a new jquery-ui theme that doesn't look as goofy as the others. See screenshots at Item11119.

-- MichaelDaum - 08 Sep 2011

That looks good. That would require that jquery-ui is loaded, or?

-- ArthurClemens - 08 Sep 2011

Yes.

-- MichaelDaum - 08 Sep 2011

And because foswikiButton et al. won't share the same css the buttons will remain different. Unless all button class names will be renamed. Is this what you propose with "adopt jquery-ui theming"?

-- ArthurClemens - 08 Sep 2011

Imho, we can't fully adopt jquery-ui yet today for technical reasons. Still their css naming conventions make a lot of sense to me. Foswiki's do as well. In the long run we need one single button class, not three as it is today: jqButton, foswikiButton, ui-button. Short term is: we have to support all three, by emmiting them all together as you proposed and/or by covering them all using css in a way they look the same. This inevitably means more css and more html. Hope is that we can reorganize these bits step by step with users not being aware of it.

-- MichaelDaum - 09 Sep 2011

ok. An intermediate step could be to organise the overriding styles in separate css files, each with styles according to the skin style/theme.

1. base-foswiki
2. base-jq
3. base-jquery-ui

-- ArthurClemens - 09 Sep 2011

First let's recap how things are right now:

• we have css coming with each of JQueryPlugin's submodules like pub/System/JQuery/plugin/foobar/jquery.foobar.css
• we have a couple of jquery-ui themes, now pluggable, with the foswiki theme being the new default. There's a base theme as well.
• we have a minimal set of base css in pub/System/SkinTemplates/base.css ...
• the rest of the css on top is part of the skin, starting at html reset, typography, forms, tables, grid, layout, colors

What would you like to change and how would you make use of it?

-- MichaelDaum - 09 Sep 2011

I am thinking for BaseSkin. That has to provide a good base in implementing base functionalities without implying a certain style, like the current base (TWiki 2003, a.k.a. no-skin) style does. It must be usable (by providing good defaults, for instance with a typographic baseline grid), must provide a good starting point for skin developers (without being too complex).

These functionalities are provided in layers. They can be called in or overridden.

Now we're talking about the base CSS. BaseSkin will either create a new base.css or provide the base.css to pub/SkinTemplates, that does not matter at this point.

With only the base css, a skin user must get a consistent user experience. Interface elements must look consistently. He will see forms with buttons styled with foswikiButton or with jqButton classes. Perhaps he sees content with ui-button classes.

This is done by loading CSS in the right order, or by adding namespace prefixes. For now I would try to solve this with loading order only, to keep the base skin simple.

I think skins should have the right to override previous styles. They override base styles and jquery themes, if any.

A lot of plugins have custom styles, most of mine actually. But in fact the plugins should only provide functionality, and give skins the possibility to style that functionality. If we are pragmatic, the plugin css should be reduced and/or templatized using custom tmpl per skin.

With that in mind, the order could be:

PLUGIN AND CONTRIB LAND

• 1. jqXxx CSS, loaded by JQuery BUTTON or TABPANE; and styles by or any other extension; this CSS should get minimized and 'handed over' (made available) to skins; the same goes for table, calendar, comment plugins.

BASE SKIN LAND

• 2. reset and base (no fancy foswikiXxx, but including default look and feel for interface elements like forms, buttons, tabs)
• 3. optional typographic and javascript CSS from BaseSkin

CUSTOM SKIN LAND

• 4. JQuery theme
• 5. selected skin

Note: skins do not have to override early loaded styles. But they may.

Let's now take an extreme example and say that we use jquery-mobile for a mobile Foswiki. We don't want to use any other skin, including BaseSkin. The site is probably broken because the topics do not use jquery-ui styles.
We could mimic it by copying those jquery styles for instance in FoswikiMobile and create foswiki translations, where possible. I don't think that will happen, because it is a lot of work, will be behind and never mind who will solve the bugs. And because of the tighter javascript integration (that expects those ui-classes) that just will be broken.

A time will come when we have a pluggable HtmlRenderer that emits css class names by theme. But not within the next 2 years.

A final side note: I don't like jquery themes in general, with their tiny glossy look. The css structure is complex and styles are hard to override, if you are not familiar with it. It doesn't fit in with other skins. But your theme looks very good. And jquery-mobile looks really good.

How to get out of this mess? I think we should go the jquery-ui way and phase out foswikiXxx classes.

That would mean:

1. Update topics, core and core extensions always emit additional jquery-ui class names, without removing foswikiXxx class names yet
2. Do the same with jqXxx classes
3. Some ui-like classes need to be invented, like ui-foswikitopic
4. In the medium term, continue to provide defaults for foswikXxx and jqXxx class names
   • These can be provided in separate CSS files to make swapping out easier
5. In the long term, deprecate and remove foswikiXxx classes

-- ArthurClemens - 09 Sep 2011

On the practical side: BaseSkin will style BUTTONs the same as foswikiButton, making this discussion obsolete (thanks to lesscss).

-- ArthurClemens - 21 Nov 2011

Commenting is disabled while not logged in