[dojo-contributors] dijit: removing id attributes in favor of widgetid

Owen Williams owen at smartsoul.com
Fri Aug 31 17:37:34 EDT 2007

I think Tom's request is reasonable, perhaps it's just an oversight  
that some widgets put the ID on the outer element, and some do not?   
Seems like something we should standardize, as Tom's right that  
styling without this will be an effing pain.

Oe must be the change we wish to see in the world.   -- Mohandas K.  

On Aug 30, 2007, at 6:09 PM, peter e higgins wrote:

> I won't chime in like I know the reason, but the behavior is  
> intended, yes.
> Some widgets with templates set id="${id}" on the first element in the
> template, which provides the CSS access you are looking for, but  
> others do
> not.
> the part in:
> http://trac.dojotoolkit.org/attachment/ticket/4063/presentation.patch
> that patches dijit/_Widget.js seems like it would fix what you are  
> trying to
> do.
> On Friday 31 August 2007 12:53, Tom Trenka wrote:
>> Hi guys,
>> So in doing a lot of porting work from 0.4 to 0.9 with Dijit,  
>> we've run
>> across a number of problems (many of them not Dijit-related), but  
>> there's
>> one that stands out that seems like a deliberate choice.   
>> Basically, it
>> seems that Dijit will take something like this:
>> <div dojoType="dijit.Menu" id="myMenu"></div>
>> ...and in the process of rendering, will change it to this:
>> <table dojoType="dijit.Menu" widgetid="myMenu"></table>
>> We haven't had any real issues with node swapping (i.e. the div ->  
>> table
>> here), but not having the original ID available is causing us major
>> headaches, particularly when we run into a situation where we need  
>> to be
>> able to define styles on very specific elements within a single  
>> instance of
>> a Dijit.  In several places in this application, I've been forced  
>> to pull
>> something like this:
>> dojo.query("*[widgetid='myMenu']").forEach(function(node){ ...do
>> something... };
>> ...in order to get access to help style internal structures (this
>> particular example came from trying a method of creating custom  
>> icons on
>> tree nodes with dijit.Tree, but you get the idea).  In particular,  
>> I've run
>> across a situation where we have a dijit.Menu that needs to  
>> stretch to fill
>> the pane that it's placed in, and then be able to set widths on the
>> individual cells that are created.  To do this, I had to pull  
>> something
>> like the following:
>> dijit.byId("myMenu").domNode.style.width="100%";
>> var rows=dijit.byId("myMenu").domNode.tBodies[0].rows;
>> for(var i=0; i<rows.length; i++){
>>     rows[i].cells[0].style.width="16px";  // icon cell
>>     rows[i].cells[1].style.width="90%";  // label cell, stretch to  
>> fill
>>     rows[i].cells[2].style.width="16px"; // arrow cell, regardless if
>> there's an arrow or not.
>> }
>> This works ok for our situation because we only have one level of  
>> items
>> (i.e. no submenus), but it would have been a lot more intuitive to  
>> pull
>> this in CSS for the overall width and the label:
>> table#myMenu{ width:100%; }
>> table#myMenu tbody tr td.dijitMenuLabelItem{ width:90%; }
>> ...but then we have no access to style the width of either the  
>> icon cell or
>> the arrow one (inspecting the HTML shows both only have  
>> "dijitReset" as
>> class names).
>> My question (after all that) is this:  is there a reason why Dijit  
>> shifts a
>> user-defined id to widgetid?  To give an example (along the lines  
>> above) of
>> why this can be a bad thing, imagine what I'd have to do to make  
>> the above
>> CSS work correctly:
>> table[widgetid='myMenu]{ width:100%; }
>> table[widgetid='myMenu] tbody tr td.dijitMenuLabelItem{ width:90%; }
>> ...which will (of course) not work in Internet Explorer at all.
>> Thoughts?  Answers?
>> Thanks--
>> trt
> _______________________________________________
> dojo-contributors mailing list
> dojo-contributors at dojotoolkit.org
> http://dojotoolkit.org/mailman/listinfo/dojo-contributors

More information about the dojo-contributors mailing list