New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

formatting issue with ui-field-contain class #6701

Closed
msewtz opened this Issue Nov 5, 2013 · 5 comments

Comments

Projects
None yet
4 participants
@msewtz

msewtz commented Nov 5, 2013

We’re using jQuery Mobile for the mobile development features we provide with Oracle Application Express. Our current release ships with jQuery Mobile 1.2. For our next release we’re currently working on upgrading to jQuery Mobile 1.4. One of the issues we’re encountering is with the changes related to field containers introduced in jQuery Mobile 1.4. We’ve already changed our code from using data-role="fieldcontain" to using the ui-field-contain class for our form item containers. However due to the way our framework works, we always render form items with an accompanying hidden item:

<div class="ui-field-contain" id="P3_JOB_CONTAINER">
<label for="P3_JOB">Job</label>
<input type="hidden" name="p_arg_names" value="3700375447394" />
<input type="text" id="P3_JOB" name="p_t03" class="text_field" value="" size="30" maxlength="9" />
</div>

It appears that the actual text item gets wrapped into another DIV container by jQuery Mobile, but the hidden field gets left out. As a result, the .ui-field-contain > label + [class_="ui-"] selector that applies style to the form fields does not work as they should because in our case [class_="ui-"] does not immediately follow the label . To resolve this issue, I added the following CSS overwrite to ensure we apply the style to any element with an ui- attribute within ui-field-contain, rather than only to the element directly following the label element:

.ui-field-contain [class*="ui-"] ,
.ui-field-contain .ui-controlgroup-controls {
float: left;
width: 78%;
margin: 0;
-webkit-box-sizing: border-box;
-moz-box-sizing: border-box;
-ms-box-sizing: border-box;
box-sizing: border-box;
}

I also moved the margin:0 into this class, as this was using the same CSS selector elsewhere. And lastly I had some issues with the divider border overlapping my form field, so I’m no longer drawing that by defining:

.ui-field-contain {
border-bottom: 0px solid rgba(0, 0, 0, 0.15);
}

It would be helpful if we could have the actual classes be a bit more flexible about the markup used for form items, so that in a scenario like ours the extra hidden field won’t break the logic.

@ghost ghost assigned jaspermdegroot Nov 11, 2013

@arschmitz

This comment has been minimized.

Show comment
Hide comment
@arschmitz

arschmitz Nov 19, 2013

Member

Thank you for reporting this issue however please see our contributing guidelines https://github.com/jquery/jquery-mobile/blob/master/CONTRIBUTING.md and create a simple JSBin test page which reproduces the issue. im going to close this as incomplete for now we will reopen once a test page is provided

Member

arschmitz commented Nov 19, 2013

Thank you for reporting this issue however please see our contributing guidelines https://github.com/jquery/jquery-mobile/blob/master/CONTRIBUTING.md and create a simple JSBin test page which reproduces the issue. im going to close this as incomplete for now we will reopen once a test page is provided

@arschmitz arschmitz closed this Nov 19, 2013

@jaspermdegroot

This comment has been minimized.

Show comment
Hide comment
@jaspermdegroot

jaspermdegroot Jan 28, 2014

Member

Although it's not a complete issue report I am going to reopen the ticket because I see the problem that the new selector can cause.

It was done this way to target all widgets with one selector [class*="ui-"] but avoid targeting elements inside widgets like buttons (ui-btn). We don't have a generic ui-widget class to target widget containers only. Looks like it's still better to use separate selectors for each form widget.

Member

jaspermdegroot commented Jan 28, 2014

Although it's not a complete issue report I am going to reopen the ticket because I see the problem that the new selector can cause.

It was done this way to target all widgets with one selector [class*="ui-"] but avoid targeting elements inside widgets like buttons (ui-btn). We don't have a generic ui-widget class to target widget containers only. Looks like it's still better to use separate selectors for each form widget.

@dpolivy

This comment has been minimized.

Show comment
Hide comment
@dpolivy

dpolivy Jan 29, 2014

I posted this over in my issue (7005), but have you tried changing the + in the selectors to a ~, which will apply to any subsequent matching siblings, and not just the /next/ sibling?

Also, would a fix for this be targeted for 1.4.1?

dpolivy commented Jan 29, 2014

I posted this over in my issue (7005), but have you tried changing the + in the selectors to a ~, which will apply to any subsequent matching siblings, and not just the /next/ sibling?

Also, would a fix for this be targeted for 1.4.1?

@jaspermdegroot

This comment has been minimized.

Show comment
Hide comment
@jaspermdegroot

jaspermdegroot Jan 29, 2014

Member

@dpolivy

I didn't think about using ~ when I wrote my previous comment. I was only thinking about reverting to how it was in 1.3 at that time. It seems like a good idea to use ~ and that would be something we can land in 1.4.1. Thanks!
As far as I know browser support for ~ is the same as for + but I will double check that. I will test with all form widgets and, if there are no issues, make the change.

Member

jaspermdegroot commented Jan 29, 2014

@dpolivy

I didn't think about using ~ when I wrote my previous comment. I was only thinking about reverting to how it was in 1.3 at that time. It seems like a good idea to use ~ and that would be something we can land in 1.4.1. Thanks!
As far as I know browser support for ~ is the same as for + but I will double check that. I will test with all form widgets and, if there are no issues, make the change.

@dpolivy

This comment has been minimized.

Show comment
Hide comment
@dpolivy

dpolivy Jan 29, 2014

@uGoMobi Awesome! I did a quick test with an input type="search" and verified that the clear button did NOT pick up the .ui-field-contain style, which is think was your original motivation for the selector change. And I think you're right on browser support. Looking forward to hearing more once you've had a chance to test it out.

dpolivy commented Jan 29, 2014

@uGoMobi Awesome! I did a quick test with an input type="search" and verified that the clear button did NOT pick up the .ui-field-contain style, which is think was your original motivation for the selector change. And I think you're right on browser support. Looking forward to hearing more once you've had a chance to test it out.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment