I believe this to be a problem.
Take the following search-box example:
<div class="container-inline">
<div class="form-item form-type-textfield form-item-search-block-form">
<label for="edit-search-block-form--2" class="element-invisible">Search </label>
<input type="text" class="form-text" maxlength="128" size="15" value="" name="search_block_form" id="edit-search-block-form--2" title="Enter the terms you wish to search for.">
</div>
<div id="edit-actions" class="form-actions form-wrapper">
<input type="submit" class="form-submit" value="Search" name="op" id="edit-submit">
</div>
<input type="hidden" value="form-V2dWadKs3DZD50-WgvEgQKgWEkRS_zfttOOsZeqbcEU" name="form_build_id">
<input type="hidden" value="RozGGJ4Pg_kzwKdSXEdIMng-SOjgi1otZmk9oIW6s7I" name="form_token">
<input type="hidden" value="search_block_form" name="form_id">
</div>
The problem is that the divs and inputs nested inside the immediate children of the .container-inline will also lose all of their block structure. In particular I have seen browsers, such as Opera, collapse the entire search box and input button into nothing. (this can happen if the button is rethemed to show an image and no text).
The system.base.css has the following relevant lines:
.container-inline div,
.container-inline label {
display: inline;
}
I am suggesting to change it to the following:
.container-inline > div,
.container-inline > label {
display: inline;
}
This should have the same affect, but only work on immediate child elements instead of all nested elements.
Reference: http://www.w3.org/TR/2011/REC-CSS2-20110607/selector.html#child-selectors
| Comment | File | Size | Author |
|---|---|---|---|
| drupal-7.x-container-inline_divs-1.patch | 450 bytes | thekevinday |
Comments
Comment #1
TransitionKojo commentedComment #2
TransitionKojo commentedThis issue relates to an IE6 compatibility problem (IE6 lacking support for Child selectors). Although it's being committed to 8.x-dev, there is currently an issue in the queue to drop IE6 support from 8.x. (see http://drupal.org/node/308865).
It can be committed to 8.x-dev once IE6 support has been dropped in http://drupal.org/node/308865. For Drupal 7 it will need to have a different solution that retains IE6 support (i.e. not using the child selector). [Catch TOTALLY helped me with that last sentence.]
Comment #3
jacineBut... that's kinda what it's supposed to do. It isn't designed to deal with nested block elements. If you're theming a submit to use an background image, then declaring inline-block or block as the display is standard practice. It's also fairly simple to remove the
.container-inlineclass if it's not serving your needs. Using the child selector would make the instances where you need to override its contents require more specific selectors. So, we should really avoid that unless it's necessary.I've never seen or heard of this happening before. Can you provide a test case in JS Bin or jsFiddle that demonstrates this?
Comment #4
jacineTagging
Comment #6
sunLet's discuss this some more. I'd love to see brainstorming and experiments on the idea.
It makes sense to some extent, but direct children are not sufficient. If we can make this work in an intelligent and smart way, I'd be in favor.
Regarding experiments, those will need (plenty of) sample markup (also forms) somewhere. This could either happen in a testing module in core, or as a dedicated test case in http://drupal.org/project/design
Lastly, a backport is definitely not possible.
Comment #7
dobe commentedWhat if we just used "inline-block" instead of "inline" for this?
Ran into this issue using the chosen module and "Seven" administration theme.
Comment #8
thekevinday commentedOne of the things I have more recently got into a habit of doing is adding class names that tag my div as different from some other div.
The downside of this is there is a bit more noise in the HTML by having even more class names.
For example, I wanted a way to have a site dynamically change from HTML < 5 to HTML 5 with as little code changes as possible. So, when I generated by HTML5 tag, such as aside, I appended a class name of html_tag-aside. Then, I did some browser identification during the theme preprocess and decided whether or not to produce an HTML5 or non-HTML5 tag.
Now, doing this allows me to have the same CSS code without having to update anything or having extra many lines (which means it provides better CSS performance).
This concept can then be used for the case of nested tags.
Another problem with this is that this should require creating a new coding style that must be followed for consistency.
Comment #9
yesct commentedcorrecting the tag to the more common one.
Comment #17
bhumikavarshney commentedAs child-element css not supported by IE. So to have the same effect on the immediate div and label, we need to use identical classes.
The above code also contains identical classes so by using theme we can achieve the same layout in all the browsers.
We can try this to avoid cross browser issues:
.container-inline .form-item,
.container-inline label {
display: inline;
}
For label as of now in the above code only single label is there to apply on the css only on single label we need to give identical class.
Comment #22
tintoThis issue was has been reviewed and discussed as 'triage issue of the day' as part of the Bug Smash Initiative.
The consensus is that the solution(s) proposed in this thread could potentially break/change a lot of existing site UIs, so cure may at this point be worse than the illness. I would argue that this does not qualify as a bug, but as a design flaw.
For this reason, I am marking this issue as Closed (works as designed). (Although admittedly, the design could have been better.) If anyone disagrees, please feel free to reopen this issue and post your motivation for doing so in the comments.
Thank you!