Opened 11 years ago

Closed 11 years ago

#7973 closed defect (worksforme)

Ability to consistently override Dijit style on creation

Reported by: ptwobrussell Owned by:
Priority: high Milestone: tbd
Component: Dijit Version: 1.2.0
Keywords: Cc: Adam Peller, nonken
Blocked By: Blocking:

Description

It dawned on me that you can't arbitrarily override Dijit style on creation in a couple of different ways, so I'm filing this ticket to either reconcile my own misunderstanding so that we can update the docs, or to determine if there are legitimate issues with the architecture that we should consider for 1.3 or beyond.

Suppose you want to create DateTextBox? and give it some style. You can do this by applying a class you have defined like so:

new dijit.form.DateTextBox?({class : "foo"}, someNode);

What is interesting though is that it turns out that the class you applied isn't the *last* class in the final class string. The final class string that is derived ends up being something like this:

"dijit dijitReset dijitInlineTable dijitLeft foo dijitTextBox"

It would seem to me that if you passed in that class named foo, that it should be the last class in the string, which would allow you to arbitrarily override any other style you chose to.

Also, and this might better be logged as a separate ticket but I'll include it here for the time being since it's highly related, you can't pass arbitrary style to override specific things as far as I can tell (maybe some dijits incidentally allow this but others do not) i.e. for the scenario

new dijit.form.DateTextBox?({style : "some style string"}, someNode);

it doesn't appear that the style string you pass in gets carried over into the dijit.

If you had passed in a node reference and were instantiating from markup, the same issue appears to be the case in that the style you applied to the node doesn't get automatically carried over. I know that Adam wrote the "attributeMap" code, but I'm not sure what it's current limitations might be. Maybe it would be good to flesh that out and more clearly document it if what I'm pointing out here is an "acceptable limitation".

Change History (4)

comment:1 Changed 11 years ago by Adam Peller

Cc: Adam Peller added

comment:2 Changed 11 years ago by nonken

Cc: nonken added

comment:3 Changed 11 years ago by bill

The order of terms in the class attribute has no effect on anything, so it doesn't matter what order they are. (The only "order" that matters with CSS is the order that CSS rules appear in the CSS file.)

As for specifying style, I think this works in general, can you provide an exact test case of what isn't working for setting style?

Note that the implementation was quite tricky... consider for example

<input dojoType="dijit.form.ComboBox" style="padding: 1em; margin: 1em;">

To implement that, the padding needs to be applied to the inner <input> node and the margin needs to be applied to the outer <div> node.

comment:4 Changed 11 years ago by bill

Resolution: worksforme
Status: newclosed

I'm closing this one; AFAIK it's working already. But please provide an example of what you think is broken.

Note: See TracTickets for help on using tickets.