Fix Dojo-Enabled Field Sizes Part 2: Type-Ahead Fields

Type-Ahead fields are activated by dojo after the page loads and the post-processing causes them ignore some theme, custom CSS, and inline settings. This can cause inconsistency in your form UI. This post demonstrates how to fix the field height and width for type ahead fields, so they better match the rest of your form.

My previous post showed how to fix these settings on date picker fields.

As I mentioned in the previous post, even field width settings in the properties panel are ignored.

This screen shot shows a form with a type-ahead field, then 3 regular fields, then a date picker. You can see that the field sizes are different for the type-ahead field and the date picker.


Reviewing the Generated Source

We can fix them with dojo code after the form loads (and the dojo-enabled activation happens), but we need to understand what is generated.

This is the source of the type-ahead field that’s passed to the browser (note that it even includes the inline ‘size’ attribute that I set while trying to size the field):

<span id="view:_id1:_id6"></span>
<input class="xspInputFieldEditBox" id="view:_id1:location1" type="text" name="view:_id1:location1" size="50" />

But this is what the source ends up being after dojo processes the field to activate the type-ahead field:

<span id="view:_id1:_id6" dojotype="" jsid="view__id1__id6" mode="partial"></span>
<div aria-labelledby="view:_id1:location1_label" widgetid="view:_id1:location1" role="combobox" class="dijit dijitReset dijitInlineTable dijitLeft xspInputFieldEditBox dijitTextBox" id="widget_view:_id1:location1" 
dojoattachevent="onmouseenter:_onMouse,onmouseleave:_onMouse,onmousedown:_onMouse" dojoattachpoint="comboNode" wairole="combobox" tabindex="-1">
<div style="overflow:hidden;">
<div role="presentation" class="dijitReset dijitRight dijitButtonNode dijitArrowButton dijitDownArrowButton" 
dojoattachpoint="downArrowNode" wairole="presentation" dojoattachevent="onmousedown:_onArrowMouseDown,onmouseup:_onMouse,onmouseenter:_onMouse,onmouseleave:_onMouse">
<div class="dijitArrowButtonInner"> </div><div class="dijitArrowButtonChar">▼</div></div>
<div class="dijitReset dijitValidationIcon"><br></div>
<div class="dijitReset dijitValidationIconText">Χ</div>
<div class="dijitReset dijitInputField"><input aria-invalid="false" value="" tabindex="0" id="view:_id1:location1" aria-autocomplete="list" aria-haspopup="true" role="textbox" name="view:_id1:location1" autocomplete="off" class="dijitReset" dojoattachevent="onkeypress:_onKeyPress,compositionend" dojoattachpoint="textbox,focusNode" wairole="textbox" waistate="haspopup-true,autocomplete-list" type="text"></div></div></div>

Fixing the field size

The logic for this one is a bit more complicated than the date picker, because there isn’t a unique class that’s applied to the field. The unique object to locate is the span tag with the dojotype attribute of (line 01). We then need to set the size on the subsequent div (line 02) and the field will size itself to fill the div.

We can get a handle to that div with the CSS ‘adjacent sibling’ selector: +

dojo.query('SPAN[dojotype=""] + DIV').style({

Note: This logic assumes that you want all of your type-ahead fields to be the same size. If you need to set some at different sizes, you can add unique classes to fields and target them separately with a few additional lines of code.


8 responses to “Fix Dojo-Enabled Field Sizes Part 2: Type-Ahead Fields”

  1. Joacim Boive (@jBoive) says :

    It’s bad form to keep styling in JavaScript, why not set it using CSS?

    You should be able to use the same selector you have in your Dojo query:

    span[dojotype=””] + DIV{
    height: 17px;
    width: 200px;

    I haven’t tested the above, because I roll my own type-aheads but I use the same approach to fix width differences between Dojo dropdowns and input-fields.

    No JavaScript means better performance and since you keep your styling in your CSS, easier to maintain.

    • Brad Balassaitis says :

      Thanks for your feedback.

      I agree that styling with CSS is always preferable, but in this case, the CSS styles aren’t effective. (I just re-tested it to be sure.) I believe it’s because the dojo is processing the type ahead fields after the page loads, so it disregards any CSS that would have otherwise applied.

      • Fredrik Stöckel says :

        And it’s not a classic CSS specificity matter?

        That is that the default/dojo css selector(s) weight overrides the one that Joacim wrote above? if so you might be able to add !important to your style-attributes to make them apply?

      • Brad Balassaitis says :

        Thanks for your feedback.

        I tried it again, but, unfortunately, adding !important didn’t work, either. It appears that the post-processing of these components causes them to not pick up CSS that should otherwise work.

      • Fredrik Stöckel says :

        Hmmm strange. I tried with the following and it seems to work on my very simplified xpage:

        span[dojotype=””] + DIV{
        height: 20px !important;
        width: 200px !important;

      • Brad Balassaitis says :

        That’s interesting. I tried it again with a brand new page and stylesheet and it’s not taking effect for me. I’m testing with an 8.5.2 server with IE9, Firefox, and Chrome.

        I did notice that the field height seems to be closer to normal in Chrome and Firefox by default. The difference is more exaggerated in IE.

      • Fredrik Stöckel says :

        Funny 🙂 Here’s my simple test page:

        I was able to change height et al to a very large height (200px) just to ensure that it worked.

        Can the difference be because my css (in the test page) is written inline and therefor “closer” to the markup and selector in the external stylesheet is loaded before the dojo css?

      • Brad Balassaitis says :

        That’s great — I see it working with your test page and even working the page-level styles removed and replaced with a reference to a style sheet!

        I’ll have to look to see what else might be getting in the way on my larger pages, but I’m glad to know that it does work with CSS!

        Thank you for following up.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: