Opera seems to add some weird vertical spaces between certain document elements when using contenteditable together with twitter bootstrap.
JSFiddle examples:
Contenteditable not enabled vs Contenteditable enabled - note that in the first example, the rows have no vertical spacing between them, but in the second, they do.
Tested in Opera 11.61 on Linux and 11.62 on Windows. In any other browser I tested, the rows had no vertical spacing between them in either of the fiddles.
I tried removing bootstrap and adding the css it applies manually, but that did not trigger the margin. However, when inspecting the DOM, I found some weird <::before> and <::after> tags that I suspect to be related (screenshot).
What does the bootstrap css do to make this happen, and what is the best approach to avoid it?
Nixing these selectors removes the spacing:
.row:before,.row:after{display:table;content:"";}
.row:after{clear:both;}
No idea what it controls, or why you need it. Looks to be some sort of clearfix type thing, but I don't know. http://jsfiddle.net/wUuSn/2/
Related
I'm developing a Meteor app with Bootstrap 3 package already installed and trying in making a buttons navigation.
I've noticed that buttons have space in between but, even if i've inspected, i was not able to discover any margin style property to make it possible.
How is that possible? Where did these margins come from?
You can see and inspect the buttons even in the official Bootstrap 3 Doc http://getbootstrap.com/css/#buttons
The issue comes from the CSS property display:inline block which forces white-space between inline elements. It is not an HTML specific issue. See this post from CSS-Tricks for more information: http://css-tricks.com/fighting-the-space-between-inline-block-elements/.
A workaround fix is to modify the HTML, which #Dan posted, but this forces you to break standard HTML formatting and a developer down the road could space things out and break your solution.
A few CSS fixes are to use floats instead of display:inline-block. You can also add negative margins on your buttons to remove that space.
It's not margin, it's actual spaces in the HTML.
If you place the buttons on a single line in your code there won't be any spacing.
See this bootply demo for an example of buttons with no spacing. Also refer to this question How to remove the space between inline-block elements? for more information.
I am trying to simply style my select box so the text is centre aligned. It works in Firefox but not in Safari or Chrome. When inspecting the element in Chrome it says the text is centred, however this is not the case. Can anybody see why it is not centred in Chrome and Safari?
http://georgewoolfe.com/yogurtline1.html
It will not work. Your best best is to use a plugin. E.g select menu :http://filamentgroup.com/lab/jquery_ui_selectmenu_an_aria_accessible_plugin_for_styling_a_html_select/
That actually replaces the select with a span but retains select functionality.
Well, styling tag is really hard. You have to test different browsers and OS, and hardly you will reach an uniform result.
http://bavotasan.com/2011/style-select-box-using-only-css/
I suggest you to use some alternative component or js replacement that emulate selects behaviour, if you want to style it in an easier way.
http://cssglobe.com/custom-styling-of-the-select-elements/
There's no totally cross browser way of centering the test of a <select> element using just css. Some browsers allow you to do it and some don't.
If you really have to have it centered then I would suggest that you look into using an alternative component like Select2 or Chosen.
Using the line-height property in a contenteditable div causes the caret to be shifted down once you move it to the second line. This is more apparent with some custom web-fonts but also happens with standard fonts like Arial. Is there a workaround for this behaviour?
This shows the caret on the first line
Caret on the second line shifted down
A demo of the behaviour can be found: http://jsfiddle.net/sGgVR/
Edit: The browser used for testing Safari 6.0.1 and Chrome 22.0.1229.94
Don't see any elegant solution for this. When line-height is less than a font-size, lines overlap and cursor's top part is cut-off by top text-box.
Maybe :first-line pseudo-element will help somehow, though, give it a try. But I couldn't get a good use of it here.
Another kinky way is to break multi-line texts onto several different elements using JS. Each with contentEditable of course. And then creating new elements on line-breaks, merging on backspace or delete. But this solution seems like way overcomplicated.
I'm using css gradients and padding to simulate buttons around an anchor tag. The problem I am running into is that firefox seems to make the button 3 pixels larger. 1 pixel on top and 2 on bottom. This seems to happen with not only the example i posted but everywhere on the page where i use the padding. I put up and example at http://wemw.net/example.php. In firefox the button top and bottom line up perfectly with the search box, but in chrome as i said its off by 1 pixel on top and 2 on bottom. I am using the w3 transitional(tried strict as well) doctype and a css reset. In the reset all anchor tags are set to padding: 0, so I'm confused as to why this extra padding is being added. Is there a workaround to this or is it just something you have to deal with when working with gecko and webkit browsers?
EDIT: So I logged over to windows and it is appearing the same in both browsers now. I'm assuming it is OS specific problems? Since no where near as many people use linux I'm going to change the padding to make it work, but in the interest of consistency can anyone offer a solution for cross-os cross-browser solutions? I do not own a mac and cannot easily test it there, but if windows/linux can have problems with the same versions of the same browsers is it safe to assume mac could also have issues i am unaware of?
It's not the padding on the anchor tag, it's the size of the text box that is inconsistent. <input> elements always caused such problems for me too, and I always found it extremely tedious to align them together nicely (you haven't yet seen it in IE8, have you?). I think that the easiest cross-browser solution here would be to remove the border from the text box and use a background image instead (or better yet, a background image on the element containing the text box) properly aligned with the button.
I'm experimenting within a Wordpress framework, trying to get blog post titles to appear in a large square block, with line breaks appearing mid-word if necessary to maintain the shape.
Using the word-wrap and (apparently) word-break CSS properties, I got the look I wanted... in Safari/Chrome. Firefox 7 refuses to break the words apart. IE does slightly better than FF, but its line breaks seem way more arbitrary (also, IE isn't really a priority at this point). Mainly I'm trying to figure out why word-wrap and/or word-break wouldn't be working in this instance in FF.
I'm not using tables.
word-break seems to be the active CSS property here. When I removed it and tested the page in Safari/Chrome, the lines stopped breaking mid-word.
I don't think any automatically applied Wordpress classes (hentry, format-standard, etc.) are playing a role, but correct me if I'm wrong. Other than the styling shown in the jsfiddle link, the other CSS is standard Twenty Eleven WP theme.
A live example: (simplified but accurate HTML/CSS): http://jsfiddle.net/3U4Xc/1/
Any input is appreciated.
It doesn't work because Firefox 7 doesn't support word-break.
On a side note which won't solve your problem white-space: -moz-pre-wrap; will not work in Firefox 7 either. It should be white-space: pre-wrap;
Since your div is using text-align:justify, you wont get any further. Also, white-space in your code may be simplified to white-space:pre; However, text-align on one side, versus pre-formatted on the other don't make friends. Not too sure about that word-break thing, HTML5, I suppose. What exactly are you trying to achieve? Something /not/ breaking, or breaking, where you want the split? Mind me, but screen sizes and user settings have always been notorious for screwing any static positioning.