When I try to resize the input box, I get overlap by the Similar Questions box. Obviously this isn't very useful.
Maybe a way to disable it automagically when I resize or finding a new geometry for it?
3 Answers
+1. I don't think there is a reason why the edit box can have an opaque background and a higher (if not the highest) z-index.
Also, people who don't format their code so that the horizontal scrollbar isn't needed should be punched in the face.
-
1
To my knowledge, this is exclusively a browser 'feature': I'll assume you're using Chrome?
Regardless, this is not a bug with any particular bearing on SO, it is a bigger issue than that. I'd perhaps recommend researching into this topic in an area where there is an active community, or support for your specific browser.
answered Jun 23, 2011 at 13:53
-
-
1Site's without cross-browser support's are known as Site's with bugs so im sory to Disappoint you Mr.Disappointment Commented Jan 4, 2012 at 13:33
This is now status-completed, sort of, but not in the way you wanted. There's a good reason that the standard defaults resizing to be turned off; unfortunately, some browsers ignore this. Vertical resizing of the editor is okay, but that's already possible via the TextAreaResizer plugin which works in all browsers. As far as horizontal resizing goes, I agree with Andy E.'s comments on your question.
For freely resizable text areas to be considered supported, everything else has to take this possibility into consideration. But when we say we want the editor to have a width of 660 pixels, we mean it, since the rest of the page is styled under that assumption.
The fact that both Firefox and Chrome default this to "on" for text areas is wrong and thus broken. So textarea { resize: none } is now part of the CSS reset.
answered Jan 11, 2012 at 10:01
-
2I have to disagree. For me that's an awesome feature, but also for me it's logical that the design gets broken if I resize something with external means. ... Great, that now means I have to look up on how to make the browser completely ignore that setting? Commented Jan 12, 2012 at 7:50
-
@Bobby It's not really an "external means"; it's part of the CSS standard. If this was e.g. some browser addon that does this, we could ignore it; it would be just like changing CSS via Firebug, which is obviously not supported by us. But the resizing is part of the standard, and Firefox and Chrome chose the wrong default value. So just like other issues where browsers are broken, we have to make sure that we're somewhat cross-browser compatible. Commented Jan 12, 2012 at 7:56
-
Oh, I didn't know it was in the CSS3 standard that way. I never saw it as part of the page itself, so I never expected it to work with the side, and if stuff got broken I just accepted that. That it is in the standard changes that, of course. Though I'd like to tell you that it is nonsense to disable it completely (because it sucks for me, I was using that extensively and didn't care for the broken layout), I can completely understand that point. Commented Jan 12, 2012 at 8:10
-
1Agreed, for the most part. We probably wouldn't have touched it if there had been no complaints. Anyway, as I said in that answer, we have no problem with specifically enabling it in spots where it makes sense and doesn't cause issues. We just default to off, like the W3C intended. Commented Jan 12, 2012 at 8:26
resize:none;styling to the<textarea>. That would certainly solve your problem :-)