Odd behavior with width property and box-sizing: border-box on jqxInput

[tmcneillParticipant]

I’ve found a weird, probably unintended interaction when using the width property and setting the box-sizing css property to border-box on a jqxInput widget.

Here’s a jsfiddle demonstrating the interaction: http://jsfiddle.net/wu0p5x9z/13/

In each of the four examples, a div element with a fixed width has a text input element inside it. In the third example, there is an inner div wrapper between the outer div and the input element. When initializing the jqxInput widget, the width is specified as ‘100%’. The input elements of all but the third example spill over their containing div element. (On Firefox, for some reason, the third example exhibits this behavior as well.) If you inspect the misbehaving input elements, you’ll see that the width is incorrectly set at 108%. If you adjust the border width or padding (but not the margin), you’ll notice this 108% changes as well. From what I can tell, the border width and padding on either side are being calculated in pixels (in this case 1 + 3 + 3 + 1 = 8) and then added to the numeric value of the width (100 + 8 = 108). If the width declaration is changed from a percent to a flat value (say, 200), the same calculation seems to occur (changing the width to 208px). Increasing the padding from 3px to 5px will result in the calculated width being 112%. This is just plain weird.

It seems as though what’s happening is that the widget code is attempting to force the input tag to behave as though it has the box-sizing: content-box property. Except it doesn’t account for margins, and it doesn’t translate flat pixel values properly to a percentage. I can’t think of a good reason to force that behavior for the widget in the first place either. But I can’t come up with any other explanation as to why it behaves that way.

If you remove the padding and border width from the stylesheet and add them in via javascript after the jqxInput widget is initialized, everything behaves correctly.

I’m not sure why the third example works (except in Firefox). The structure of elements is the same as in the fourth example. The only difference is that the input element and the inner div wrapper are added to the DOM after the jqxInput widget is initialized. Possibly a potential quirk with the different javascript engines.

Potential workarounds for others that run into the same problem.
* Remove any padding or border width on the input element
* Remove the box-sizing: border-box property on the input element
* Don’t use the width property on the widget and instead set the width in the stylesheet

The last option is probably the best. But this is an issue that should be fixed at some point.

[ChristopherParticipant]

Hi tmcneill,

The reason for the abnormal behavior is because you set the “box-sizing: border-box;”. You shouldn’t set it because the widget already has a “box-sizing” property assigned.

Best Regards,
Christopher

jQWidgets Team
http://www.jqwidgets.com

[tmcneillParticipant]

That seems a lot like a “it’s-not-a-bug-it’s-a-feature” explanation. Arbitrary style rules are now off-limits? Is this documented anywhere?

The problem isn’t even with the CSS though. Setting both width and box-sizing in CSS works just fine. The problem is that under certain circumstances, the width property set on the widget is translated incorrectly and unintuitively to CSS.

I mean, no reasonable person would assume that by setting width: '100%' when initializing the widget and setting box-sizing: border-box; border-width: 2px; padding: 4px; in the stylesheet, the resulting width would be 112%. Intuitively, the width would be 100%, because that’s what was specified. Or at the very least, it should convert pixel to width values. But the current behavior of adding values together and ignoring units makes absolutely no sense. And the fact that margin size, while affecting the overall box size, aren’t compensated for while padding and border size are is just confusing.

I’d be fine with a response along the lines of, “Hrm, this is odd behavior. We’ll look into fixing it. But for now, here’s a workaround.” Or maybe, “Yes, that’s unintuitive, but it’s not going to change. That behavior is documented [here].” But I have a hard time swallowing an answer that is basically brushing off a problem as obvious as directly adding two values with different units. You can’t add pixel values to pecentage values to em values without converting their units first. That’s what the problem is here.

[ChristopherParticipant]

Hi tmcneill,

Thank you for your feedback. We will consider improving it in the future.

Best Regards,
Christopher

jQWidgets Team
http://www.jqwidgets.com

[Author]

Posts