Closed Bug 35957 Opened 25 years ago Closed 24 years ago

[feature] XBL widgets must be able to include CSS

Categories

(Core :: XBL, defect, P3)

Other
Other
defect

Tracking

()

RESOLVED FIXED

People

(Reporter: sjoerd, Assigned: hyatt)

Details

(Whiteboard: nsbeta3)

"Dave Hyatt" <hyatt@netscape.com> wrote in message news:38F792F2.8F7EF54F@netscape.com... > Right now, you can't include CSS directly in an XBL file. The problem > is this. > > (1) The new widget is bound into some other document. What do you do > with the CSS file? Add it in to the other document? > (2) If you do put it in the other document, how do you handle the fact > that the widget should be skinnable over in the other document? e.g., > if the binding CSS file goes on the end, it would come after the > document's skin CSS file, and any rules wanting to skin the widget would > have to be !important in order to override. > (3) You have to keep the CSS from being put into the other document more > than once. > (4) It seems wrong that the CSS should be allowed to apply to anything > other than the bound elements and their anonymous content. This is > horrifically complicated, however, since there's no notion of stylesheet > scoping, i.e., this stylesheet only affects a subset of a DOM tree. I think stylesheet scoping needs to be hacked in. How I think it should work: - XBL must be able to supply style information - This information must only apply to the XBL widget - It is the problem of an XBL designer that the style he supplies, can only be changed by the page writer using !important. A good XBL stylesheet should only insert 'display' and 'visibility' styles, and maybe some margins/padding. For the other style, the XML designer should document which elements and classes are used. It should work just like an IFRAME that inherits the style from the parent document. (in Internet Explorer 5.5 IFRAMES and HTC widgets use completely the same technology) For example, a calender widget should not have to include style. It should have different classes for weekdayheader boxes and day boxes. If it doesn't look good by default, maybe Mozilla should define some default classes that widgets can use. Like 'gridheader' and 'gridcell' which will by default look like something like Excel. These classes should be well documented, so they can be reused.
Status: NEW → ASSIGNED
Summary: XBL widgets must be able to include CSS → [feature] XBL widgets must be able to include CSS
Whiteboard: 2 days, 4/28
Target Milestone: --- → M16
Whiteboard: 2 days, 4/28 → 2 days, 5/4
No time for this in this release cycle, moving to M30, putting on helpwanted radar.
Keywords: helpwanted
Whiteboard: 2 days, 5/4 → 2 days
Target Milestone: M16 → M30
Mass-moving all M20-M30 XPToolkit bugs to Future
Target Milestone: M30 → Future
Pulling this back. I think it's needed to properly solve 21890, which has been marked nsbeta3+. Nominating for nsbeta3.
Keywords: helpwanted
Whiteboard: 2 days → nsbeta3
Target Milestone: Future → M18
There is a confusion. Bug 21890, which is on my list, was approved nsbeta3+ during our last bug triage session with a certain solution in mind which has nothing to do with the feature described here. The 2 problems are independent but there may be other reasons that I don't know of to implement the present feature.
There are, although none are nsbeta3+. So if the plan is to do something else to solve 21890 then this doesn't need to be nsbeta3+. IMO this is a good way to solve 21890 though. We should chat about it.
Adding nsbeta3 keyword to bugs which already have nsbeta3 status markings so the queries don't get all screwed up.
Keywords: nsbeta3
Fixed.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.