Response title
This is preview!
Move this topic
Add { padding: 0.5em 1em; } to .ui-widget-header CSS
in Developing jQuery UI
•
12 years ago
Please add something like { padding: 0.5em 1em; } to "ui-widget-header" CSS class to make widget headers look consistent with other headers and buttons.
1
Replies(4)
The themeroller will help you in making a good template for your widgets. It's all up to you to modify it for your special needs after you download it. There are some settings that you can't control when "rolling" it.
The thing is that any rolled theme would work for me right out of the box if it were not for this little omission. After all, other headings, e.g. those for Accordion, Dialog, Tabs, etc., all have some predefined padding which, as you rightly pointed out, I can't control when "rolling" a theme, but which I can easily change later. Why not add the header for Widget to this privileged group of headers looking nicely right from the start? Besides, widget header already has a pre-set font weight and color, so, again, why not preset padding as well?
Leave a comment on Chrazy's reply
I completely understand why you'd expect it to work this way but the CSS framework is set up a bit differently so let me explain a bit about the mechanics. We basically have a handful of theme classes that are meant to generically describe the role of an element in a UI and these are re-used across all our widgets. These are: header (ui-widget-header), content clock (ui-widget-content) and clickable button (ui-state-default, -hover, active) -- there are others, but these are the important ones. Each of these classes are carefully coded to be "theme only" meaning they only set colors and background images, never structural styles like padding, margin, dimensions, etc.
In a particular widget like tabs, we add two types of classes to elements: theme classes (ui-widget-header) and widget-specific classes (like "ui-tabs-nav") that are used to define the structural styles of the elements like padding. Combined together, these provide all the formatting needed in a concise way. Using multiple, re-usable semantic classes like this follows an object oriented css approach and it underpins the whole framework.
This clean separation of theme styles vs. widget structural styles is important because if we set padding, margins and dimensions in the theme classes, we'd need to keep track of all the overrides we'd need to make at the widget level and it could get messy in a hurry. By keeping theme classes lightweight and focused only on colors and texture, it makes it easier to code the widget styles without conflict.
In your case, if you wanted to follow jQuery UI's class conventions, you'd assign two classes on your header: a structural style (my-header) and a theme class that maps to it's role (ui-widget-header). We namespace all our official UI widget classes with ui- but you can use whatever you want for these widget classes. Add both classes you your heading markup, write your structural styles for the heading against the "my-heading" class and you're good to go. To maintain TR support, never specify colors or background images in these structural styles or you'll override the theme.
This is just an odd case where the widget name "header", is a bit too close to our theme lever "ui-widget-header" so it's confusing. We're working on an expanded CSS framework now and may re-think our naming conventions to make this clearer. If you take a look at the docs and read through the first part of the TR generated theme CSS this will hopefully be clearer:
BTW - font family and size is set by the "ui-widget" class, not at a theme lever or widget level. We typically add this class to the outer parent wrapper of a widget so all the elements inside inherit the theme's font settings. You could add this class to your header if there isn't a parent container that needs the font formatting. All the classes are designed to be modular and stackable.
Hope this helps!
Cheers,
Todd
Thank you for an extensive explanation, Todd.
Oh, and one more thing which is somewhat off-topic here: it would be nice to have some CSS classes similar to "ui-corner-..." which would define border presence for each side of any box, so that by adding/removing those classes we would be able to switch individual border sides on/off. This way one could put several widgets side-by-side or on top of one another and make them share a common border. How about that?
Yes, I like this approach too. What I don't like is a necessity to somehow calculate structural parameters of the widget header while they could well have been put in some predefined class in the framework. Maybe we should add something like "ui-widget-header-dimensions" (or name it any other appropriate way) which will hold all necessary parameters, so that if added to the header it would make it look consistently with other widget headers. Is that feasible?This clean separation of theme styles vs. widget structural styles is important because if we set padding, margins and dimensions in the theme classes, we'd need to keep track of all the overrides we'd need to make at the widget level and it could get messy in a hurry.
I've already done something to that effect, but I'm worried about a probable necessity to change parameters of that structural class in future in case if you change something in jQuery UI widgets, to make my own widgets look consistent with them again. Is there any guarantee that "standard" widget headers will stay the same size in future and throughout all themes? I'd like to have a simple way to make all headers consistent.In your case, if you wanted to follow jQuery UI's class conventions, you'd assign two classes on your header: a structural style (my-header) and a theme class that maps to it's role (ui-widget-header).
Yes, but above I mentioned font weight and color which both are defined in the "ui-widget-header" class.BTW - font family and size is set by the "ui-widget" class, not at a theme lever or widget level.
Oh, and one more thing which is somewhat off-topic here: it would be nice to have some CSS classes similar to "ui-corner-..." which would define border presence for each side of any box, so that by adding/removing those classes we would be able to switch individual border sides on/off. This way one could put several widgets side-by-side or on top of one another and make them share a common border. How about that?
Leave a comment on fg.todd's reply
Change topic type
Link this topic
Provide the permalink of a topic that is related to this topic
Reply to mansarda's problem
Statistics
- 4 Replies
- 7106 Views
- 0 Followers