Opened 13 years ago

Closed 12 years ago

Last modified 8 years ago

#1850 closed enhancement (invalid)

Dojo combobox style overide in CSS does not work for combo box items

Reported by: guest Owned by: bill
Priority: high Milestone: 0.9
Component: Dijit - Form Version: 0.4
Keywords: Cc:
Blocked By: Blocking:

Description

I have defined my class for combobox:

<select dojoType="ComboBox?" ... class="PersonageSelector?">...</select>

And after in CSS i'm trying to override:

.PersonageSelector? .dojoComboBoxItem {

padding-left: 12px; padding-top: 12px; margin: 0px;

}

But in browser, i see default dojo style.

In page source i can see that dojoPopupContainer appears after dojoComboBoxOuter div. And i think it's reason of issue.

Is this a well know problem? Any workaround?

Attachments (5)

combo-issue.JPG (4.1 KB) - added by guest 13 years ago.
combobox.patch (91.4 KB) - added by jbond@… 13 years ago.
This patch fixes it for me, the problem is with the Popup container appending the DOM node at the bottom of the document
combobox.2.patch (1.0 KB) - added by jbond@… 13 years ago.
This patch fixes it for me, the problem is with the Popup container appending the DOM node at the bottom of the document
combobox.3.patch (1.1 KB) - added by guest 13 years ago.
ok this should the proper patch
combobox.4.patch (3.5 KB) - added by Jonathan Bond-Caron 13 years ago.
New patch: alwaysVisible solution

Download all attachments as: .zip

Change History (17)

Changed 13 years ago by guest

Attachment: combo-issue.JPG added

Changed 13 years ago by jbond@…

Attachment: combobox.patch added

This patch fixes it for me, the problem is with the Popup container appending the DOM node at the bottom of the document

Changed 13 years ago by jbond@…

Attachment: combobox.2.patch added

This patch fixes it for me, the problem is with the Popup container appending the DOM node at the bottom of the document

Changed 13 years ago by guest

Attachment: combobox.3.patch added

ok this should the proper patch

comment:1 Changed 13 years ago by Jonathan Bond-Caron

Hmm, ok I hate submitting patches through this thing!

Anyways you should get the point from the patch...

Also the documentation is unclear:

open: function(/*Integer*/x, /*Integer*/y, /*DomNode?*/parent, /*Object*/explodeSrc, /*String?*/orient, /*Array?*/padding){

The parent is not a DomNode? but rather an html widget, at least that's how it seems to be called by other widgets... could make checks to be safe.

jon

comment:2 Changed 13 years ago by bill

Your patch attaches the popup to parent.domNode instead of document.body, but that won't work because of cutoff problems. (Imagine that the combobox is inside a <div style="height:100px; overflow: auto">. The drop down list will only be half visible on the screen. See the last test in test_layoutContainer.html for an example.)

Changed 13 years ago by Jonathan Bond-Caron

Attachment: combobox.4.patch added

New patch: alwaysVisible solution

comment:3 Changed 13 years ago by Jonathan Bond-Caron

Hi Bill,

Thanks for pointing that out, please review the new proposed patch.

We could argue on what the default behavior should be for the combobox (alwaysVisible: false or alwaysVisible:true) but I feel the expected & default behavior should be to append the popup inside the comboxbox container.

By properly documenting the problem, users could choose to set alwaysVisible:true (as I did in test_layoutContainer.html)

Let me know your thoughts, jon

comment:4 Changed 13 years ago by bill

Well, I don't want to add a new "alwaysVisible" flag to Combobox (and every other drop down widget) because that requires more code, and more testing each release (specifically, testing both alwaysVisible=true and alwaysVisible=false mode), and it doesn't really seem related to the CSS issue. Why not just have a dropDownClass attribute that sets the class on the drop down div?

comment:5 Changed 13 years ago by Jonathan Bond-Caron

Hi Bill,

Just read your article, Ajax and REST... good stuff. I would defineltly put more-responsive UIs at the top. It's all about providing quick feedback to the user based on his interaction with an application.

"Why not just have a dropDownClass attribute that sets the class on the drop down div"

There's probably another fix possible along those lines but it's another bad hack. I'll sum up the problem:

#blue .dojoComboBoxItemHighlight {

background-color:#000066;

}

#black .container .dojoComboBoxItemHighlight {

background-color:#000000;

}

<p>Blue style</p>

<div id="blue">

<input dojoType="Combobox" dataUrl="TestAutoComplete?.js" />

</div>

<p>Black highlight</p>

<div id="black">

<div class="container">

<input dojoType="Combobox" dataUrl="TestAutoComplete?.js" />

</div>

</div>

Now when I write this, I would expect that the Comboxbox markup would be contained where it is. But the Popup widget really applies a 'hack' by appending the node to the document body. So the CSS styling is lost. And as far I know, the popup widget is the only widget that breaks the markup consistency.

So if you really want to keep the popup node appended to the body, a proper fix would be get ALL classes from the popup's parent (until you reach the body tag or null) and recreate the markup.

i.e.

<div id="black">

<div class="container">

<dojo combobox markup here.... />

</div>

</div>

(append to the body) <div id="black">

<div class="container">

<the popup here.... />

</div>

</div>

Note that you end up having to duplicate the id, so really it's another bad hack. In my opinion, the following:

<div style='height:20px'><input dojoType="Combobox" dataUrl="TestAutoComplete?.js" /></div>

SHOULD hide the combobox popup, the CSS is rendered properly (but yes there's a cut-off). Dojo could provide an additional flag (i suggested alwaysVisible), to append the node to the body...

jon

comment:6 Changed 13 years ago by alex

Milestone: 0.5
Owner: changed from anonymous to alex
Priority: highnormal
Status: newassigned
Type: defectenhancement

the provided patch does not meet our style guidelines. scheduling this to be closed in 0.5 one way or the other.

comment:7 Changed 13 years ago by Jonathan Bond-Caron

Where can I find the style guidelines?

comment:9 Changed 12 years ago by Adam Peller

Component: GeneralDijit
Owner: changed from alex to bill
Status: assignednew

Jonathan, is this still an issue in 0.9?

comment:10 Changed 12 years ago by haysmark

In 0.9, ComboBox? uses the dijitMenu and dijitMenuItem classes for a consistent look across menus. If you want to change how your menus look you can simply make your own theme with your own dijitMenu and dijitMenuItem. You don't need to override the ComboBox? inline like that.

comment:11 Changed 12 years ago by bill

Resolution: invalid
Status: newclosed

comment:12 Changed 8 years ago by bill

Component: DijitDijit - Form
Note: See TracTickets for help on using tickets.