I'm having a problem with multiple text-shadows and negative letter-spacing in Webkit where the last few pixels of the shadow on the last letter are cut off.
Well, only certain letters.
Look at this demo in Chrome or Safari (it works as expected in Firefox and Opera as far as I can tell.)
I know I could use -webkit-text-stroke in addition, but that leads to this problem:
Any ideas? Thanks.
Yes, I'd say it's a drawing bug. It appears webkit lets the box around the letter crop the shadow when you start using negative letter spacing.
I found it easier to see the problem by increasing the size and doing display: inline to get a collapsed box around the letter.
http://jsfiddle.net/tMeuB/3/
Firefox
As of version 7.0.1
Notice how the shadow stays as the negative letter spacing increases from left to right.
Safari
As of version 5.1.1 (7534.51.22)
Same test. See how the shadow gets cropped as letter spacing increases. In frame 3 you can almost see how the algorithm calculates it. I'd guess the amount of clipping = glyph width - glyph box width.
I found a solution, sort of.
Here is another demo.
If you drop a in after the cropped letter, it fixes it. But that's not ideal.
I tried using a similar technique with an :after pseudo element, but it doesn't work.
Fortunately enough for me, the text I'm trying to apply this style to is a pseudo element, so it was easy to throw a \00A0 in the content:''.
Related
see demo: http://jsbin.com/evesey/41/edit
Each letter is in a span element, and the whole sentence is overlapping an input field, to show the difference. this is only caused in Firefox and only when the spans are set to inline-block. They must be inline-block. I tried to play with the letter-spacing but it isn't a good solution when the text changes to something else.
Is there a way for this to be fixed? I'm afraid this might just be an unsolvable bug in Firefox rendering inline-blocks...
Ok, after DEEP investigation, I have learned that Firefox applied Kernnig on the input field, but not on the separate letters in the spans while Chrome does not apply any kerning at all, thus, rendering a perfect text match. I see this is a Chrome bug then, not kerning by default is not so wise IMHO.
I've managed to remove the forced kerning in a "hacky" way, by adding a zero-width-space character \u200b after every character that is printed into the input field.
Update:
seems the kerning is still happening with the above trick, only less "kerned". this is not good.
I have a ul with lis inside that I'm using as a tab list. The lis have an image and some text inside of them. For some reason, in chrome, the text doesn't appear on the same line as the image, but wraps to the next line.
I can't understand why this would happen, shouldn't the li expand to give enough space to fit both the image and the text? This problem doesn't happen on Firefox or IE. Testing with Chrome 22, Firefox 16 and IE 9 on Windows 7.
See this fiddle to see the markup (extracted from a longer page - also not the real icons).
It sounds similar to this problem, but the nowrap trick didn't work for me.
Update: I just realized I had a different zoom level set, 144%. At some zoom levels the issue happens, and others it does not. I guess it might have something to do with the ems for some sizes, and px for others? I still don't get why this would happen though, shouldn't it still get the proper amount of room?
Set a minimum width on the header. You also have the issue if you reduce the browser size. Figure out how small it can go before it starts to stack and set the min-width on the header to that size, that fixes it if the browser is zoomed too.
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.
This question already has an answer here:
Chrome using wrong border color on left on tall objects with border-radius set
(1 answer)
Closed last month.
Alright, well I have searched and searched on google, stackoverflow, other sites for an issue regarding how webkit handles the combination of border-radius, border width and color applied to a box, with one side having both a thicker border and different border-color.
I have been testing and testing both in the project I'm currently working on and in JSfiddle.
I have created a JSfiddle with multiple test cases in it exemplifying what styles do and do not affect this bug. http://jsfiddle.net/kGST9/4/
You will see that most of the boxes have a strip of red in the centers of the top and bottom borders. You'll also notice that on the different test cases the width of the strip of red varies depending from what I've found, on the width of the left border and the width of the box. I believe it truly doesn't matter what side the thicker border is on and will behave the same. This only occurs in webkit, both the latest releases of Safari 5 and Chrome 16, and I'm assuming this goes to all versions of webkit that supports border radius.
Firefox does not display this issue.
I have not even been able to find anyone talking about this bug in a forum or blogpost, and do not believe to be the only to have this problem. lol
Just for reference, I've also attempted adding other none border related styles, such as position, display, overflow, background-clip, and their various values, with none of them helping.
So help me get down to the bottom of this if you will.
Regards,
CSSDevMonkey
Very strange indeed. I've found after toying with it that whether or not the bug shows up (and how severe it is) is tied to a combination of the ratio of the box's overall width and height as well as the size of the border radius. I can get the problem to go away (in all but one case) by increasing the border radius to 20px. Also, reducing the width of every div to 200px seems to fix the issue.
Definitely looks like a bug. Not sure what a direct fix would be other than playing with varying width/height ratios, border-radii, or border widths. You've probably already done a good amount of this.
I just stumbled across this post and have a similar bug with border radius and different width to height ratios of the divs. I'm not using different sized borders, but different colors.
If I have a border radius and border-color: red blue blue red, the left border gets a strip of blue in it depending on the size. Only in Web-Kit browsers it seems, and I cant seem to find any work around. I guess its a bug, unless you have found a solution.
Put up my own jsfiddle with my issue.
http://jsfiddle.net/6xUNr/
I have discovered a strange bug in Firefox 4.0.1 (It also happend in Opera 11.5) so I've created this example to show the problem:
http://jsfiddle.net/whYC7/
If viewed in safari everything looks fine, but when I open it in Firefox or Opera the image inside the div with a negative margin still takes up space in the div underneath.
Does anyone know of a way to fix this?
This is the correct rendering per the CSS spec. The negative margin means that the top of the red div is higher than it would be otherwise, but once you determine where its top is the position of the text just depends on the intersection of the float and the div. See http://www.w3.org/TR/CSS21/visuren.html#floats the paragraph starting "A line box is next to a float".
You may want to file a bug on WebKit here.
I have ran into this issues as well in FF and IE9...an absolute positioned div does not seem to recognize negative margins, though using top:100px instead of margin-top:-100px does seem to work in FF 12 and ie9
A fix that could work in most cases is to make your div's position absolute and then to use top/left/right/bottom to control position