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)
Tracking
()
RESOLVED
FIXED
M18
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.
Assignee | ||
Updated•25 years ago
|
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
Assignee | ||
Updated•25 years ago
|
Whiteboard: 2 days, 4/28 → 2 days, 5/4
Comment 1•25 years ago
|
||
No time for this in this release cycle, moving to M30, putting on helpwanted
radar.
Comment 2•24 years ago
|
||
Mass-moving all M20-M30 XPToolkit bugs to Future
Target Milestone: M30 → Future
Assignee | ||
Comment 3•24 years ago
|
||
Pulling this back. I think it's needed to properly solve 21890, which has been
marked nsbeta3+.
Nominating for nsbeta3.
Comment 4•24 years ago
|
||
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.
Assignee | ||
Comment 5•24 years ago
|
||
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.
Comment 6•24 years ago
|
||
Adding nsbeta3 keyword to bugs which already have nsbeta3 status markings so
the queries don't get all screwed up.
Keywords: nsbeta3
Assignee | ||
Comment 7•24 years ago
|
||
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.
Description
•