CSS files are not necessarily themes related, to be more agnostic rename "themes" into "css" about delite

[wkeese]

Which files aren't theme related?

Note that as we split each widget's CSS into widget specific directories,
there won't be much left in themes/.

[cjolif]

Actually there maybe none right now but at least @dmandrioli have a candidate for a non theme related one. I let him elaborate. And this is a non-widget specific CSS and so even when the CSS for the various widgets will be split out into their own directories (#14) we will still need that common place which might be better named css than theme?

[wkeese]

OK. It's just strange because I used to have such CSS in dijit.css but I
got rid of it, rolling it into the claro .less files. I consider it an
improvement.

[dmandrioli]

I plan to have a CSS file such as dui/css/defaultapp.css which would contain some useful global CSS for typical app development. This CSS would be optional for users, depending on their needs.

Here is the content of this file:

html, body {
height: 100%;
margin: 0;
}

*{
box-sizing: border-box;
}

[cjolif]

@wkeese I guess the difference is what @dmandrioli mentioned would be optional and loaded only when the user request it while the theme things are automatically loaded as soon as the corresponding widget / theme is loaded. Maybe this could still be in theme after all but this would need to be duplicated in all themes and the user might have more trouble finding it inside all the themes .css files than at root place.

[wkeese]

First of all, I don't care if you rename the themes directory.

As for the file you are suggesting, it sounds like dojo.css, albeit the
height: 100% is a twist. I mention this because originally dojo.css was
included from Claro, but there was a lot of opposition, a lot of people
upset. So eventually, we made it opt in, ie to be included manually.

My other observations is that general page CSS could also vary by the
theme. For example, doesn't bootstrap have general page CSS setting fonts
etc.?

It seems like general page CSS should be opt in but theme specific.

[sbrunot]

Speaking of "generic" CSS classes that are not related to themes, what are we going to do about the dojo mobile dom buttoms (css under dojox/mobile/themes/common/domButtons) ? Are we going to release them as CSS files, are we going to release them "wrapped" into a domButton widget ? Something else ?

[wkeese]

Not sure what happens with those domButtons classes. It seems strange to me to have predefined classes for specific colors.

One other note on themes/ vs. css/: Some of the widgets' theme-specific directories will contain more than just CSS. They will have custom icons (implemented as custom fonts or sprites). So while it might make sense to have a generic css/ directory for non-theme-specific CSS files, I think it makes sense for each widget to have a themes/ directory:

Button/
    themes/
        android/
        ios/
        ...
    nls/
    ...

Either that, or just have the theme directories directly under the widget directory, i.e.

Button/
    android/
    ios/
    ...
    nls/
    ...

PS: Well, I'm optimistically assuming that the icons will vary by theme. Perhaps we don't have the manpower for that.

[cjolif]

You are right that theming is actually potentially more than CSS. So let's keep "themes" naming for each widget. Now as you said we might still have a css top level directory for things like what @dmandrioli is proposing. I propose we close this issue and create that css directory when/if needed.

For domButtons I propose @sbrunot you create a different issue as this sounds a bit orthogonal discussion to me. My take is that as we want CSS to be premium citizen there is not requirement to wrap them into a widget to bring them into deliteful but we can discuss this.

@wkeese the purpose of the dom buttons is more than changing colors, this was to replace PNG icons by lighter alternatives for mobile (in several colors indeed). See http://www.ibm.com/developerworks/mobile/library/mo-dojo-mobile-performance/index.html.