You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Oct 8, 2021. It is now read-only.
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:
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:
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:
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.
The text was updated successfully, but these errors were encountered:
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
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.
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?
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.
@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.
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.
The text was updated successfully, but these errors were encountered: