Dialog Auto Width

[Scott González]

There are a few tickets about setting dialog's width option to 'auto' not working properly. I never intended for this to be a valid option. We do support height: 'auto', but I really don't know how width: 'auto' would even work.

Is width: 'auto' something we should consider supporting? If so, how would it work?

[Andrew Powell]

When I first started working with jQuery UI I had expected width: auto
to be something that would work out of the box. But the more I hacked
around with the source and the css for the dialog, the more I came to
realize that this simply would not work cross-browser (read: on IE).

What I ended up doing was a multi-fold approach:
- always use a fieldset for the wrapping dialog content container (the
target element for the plugin)
- set a default width in css for the fieldset wrapper, and position
the fieldset offscreen (-10000, -10000), but visible.
- override the width for the fieldset using classes applied in the
html at my whim.
- using a wrapper function, before applying the .dialog(...) plugin, I
measure the fieldset container and then pass the width to the plugin's
init. after the plugin init, I remove the absolute positioning and
top, left coords which forced the element offscreen.

Now, this doesn't really solve auto width, but it made it a no-brainer
to handle widths in the dialogs. In theory, a auto width type effect
could be gained by using max-width on the wrapping dialog container
element, but then we're left with IE6 which doesn't understand
max-width.

Dunno if that'll help, but that's how I overcame that width limitation.

2009/11/7 Scott González <scott.g...@gmail.com>:

[Richard D. Worth]

I also don't see anything we could for width: 'auto'

2009/11/7 Scott González <scott.g...@gmail.com>

[Andrew Powell]

Well, if 'auto' was set on init, the same round-about way I went about
solving that could be applied internally.

[Scott González]

On Sat, Nov 7, 2009 at 1:56 PM, Andrew Powell <pow...@gmail.com> wrote:

Well, if 'auto' was set on init, the same round-about way I went about
solving that could be applied internally.

I'm actually confused about your solution. It sounded like you were setting specific widths, you even said "this doesn't really solve auto width." Could you explain this a bit more?

Thanks.

[Andrew Powell]

Sure.

When I mentioned that it doesn't solve auto width, I was speaking
towards the css-based solution. It is a programmatic solution, though.

You're correct that I'm setting a specific width during init. It does
not allow for the dialog changing widths dynamically once the dialog
is initialized.

css:
fieldset { min-width: 400px; position: absolute; top: -10000px; left:
-10000px; } /* for ie6 just set width: 400px; */

html:
<fieldset>
....
</fieldset>

This allows for me to always have dialogs on my site at least 400px
wide, which happens to be the decided upon standard size for the
particular app this was designed for. One could do without that
particular css attribute, however. This also allows me to apply
another css class to the element in html to override the size if I
want to set it absolutely, and allows the fieldset to grow
horizontally based on the content - but before the dialog has been
init'd.

My wrapper function then measures the width and sets it within the
.dialog(...) init params.

So to reiterate, it allows for a semi-dynamic width *before* the
dialog is initialized. What this does, is take the thinking out of
having to set the width, or figure out what the width is - takes out
some busy work - and in apps with a large volume of dialog use, it's
nice to have.

Now I would assume that this is the most common use case for the
width: auto; setting, but then I've never had an alternate use for
width: auto. I'd just rather not have to think about figuring out and
setting the width explicitly each time I need to use the dialog.

2009/11/7 Scott González <scott.g...@gmail.com>:

[Scott González]

Thanks for explaining that. An official solution would have to work with someone dynamically changing the content, like height: 'auto' does. It seems like everyone agrees meeting that requirement wouldn't be possible cross-browser. I'll close the ticket tonight or tomorrow unless someone thinks we can actually implement this. If someone figures it out later we can always add it in.

[Andrew Powell]

Well really the only programmatic way of handling this, with those
requirements, would be to set the overflow to hidden and allow the
contents of the dialog to overflow, which would then have to be
monitored some way. There's a plugin out there that 'watches' styles
and widths and such, but the last time I played with it, it didn't
work very well.

That's a shame though that you're not willing to implement at least a
partial solution. Some is better than none.

2009/11/7 Scott González <scott.g...@gmail.com>:

[Scott González]

On Sat, Nov 7, 2009 at 5:40 PM, Andrew Powell <pow...@gmail.com> wrote:

That's a shame though that you're not willing to implement at least a
partial solution. Some is better than none.

Unfortunately implementing a partial solution means creating a bug, while stating that we don't support width: 'auto' means that our code functions exactly as we say it does. There's also nothing stopping someone from creating an extension for the dialog plugin that adds partial support for width: 'auto'.