See this link - why are the multiline textboxes draggable?
Is this Firefox bug? It just spoils the design like anything.
Even the same in happening is Stackoverflow's textbox. I am using Firefox 5.0
Thanks in advance:)
Edit:
See these photos of SO itself:
This is a feature that's been included since Firefox 4. However, you can switch it off by including resize: none in the css of the given Textarea(s).
That's something happening since some time now even on Chrome and maybe other browsers too. I think it's to allow a better experience for the users who need to type text in the textarea, so I definitely think it's not a bug.
But it indeed can mess up your website layout. You have to use some CSS to fix it, like
#yourtextarea {
width: /* fixed width here */
height: /* fixed height here */
}
In case the above doesn't work, you may also think about use min-width, max-width, and the height equivalents.
I won't mess up with this anyway, since it's a browser feature and so it's something useful for the users.
Why are the multiline textboxes draggable?
They aren't. Dragging just selects the text inside them. They can be resized though, which is great as it lets users make textboxes bigger so they can see more of their text if they have typed a lot.
Is this Firefox bug?
No, it is a feature. I think Chrome got it first.
Related
This code works fine in Chrome and Firefox. But in Safari, the drag handle won't work if there is padding beyond 11px.
Is this a bug in Safari, or is there something silly I'm missing?
<style>
textarea {
padding: 11px 16px;
}
</style>
<textarea>Stuff goes here. Does my drag handle work?</textarea>
I ran into the same problem yesterday, and have unfortunately not been able to find a direct solution to this problem.
As an alternative, you can ditch the resize handle entirely, and look into making your text area auto-resizable. Personally, I feel like this makes for a better design anyways. You completely avoid the problems of the resize handle, and your users get the additional space they need for their text, without having to mess around with a tiny handle themselves.
This post has some good examples on how this can be achieved.
The issue I'm having is options in a select box flow over the edge of the page (hiding the scroll bar). I'm trying to restrict the width of the options using CSS. Please say if there is a better way...
This worked fine in IE8, but not in IE9. Seems okay in Firefox as well. Chrome ignores it as well, but makes sure the options don't overflow off the page (like IE9).
I know the non-resizing of these was a bug that was fixed for IE9, but it is necessary (sometimes) to set a width limit.
http://jsfiddle.net/jdb1991/Vt8Bd/
Browsers implement select elements differently, often using built-in routines that are more or less immune to CSS. It is not even clear what you, or others using very long option texts, would like to happen—truncation, line-wrapping, horizontal scrolling, or what?
The problem is best avoided by using concise option texts. They are supposed to be visible names for alternatives, not novels. If very long names are really a necessity, use a set of radio button instead of select.
I always have a problem when making webpages using input or select boxes in CSS because the focus is mostly making it for FireFox and IE, but for some reason the text inside text boxes/form input objects are usually never properly aligned (line-height).
I'm wondering if there is a common routine for making input boxes look like they do in FireFox and IE, in Safari, because they usually look horrible once you add a touch of CSS to the element. Trying to balance out the line-height on each browser usually never works out perfectly, is there something i'm missing to make the inputs in all browsers look the same once you style it? (mostly talking about the line-height of the inner text inside the input box).
ie. Is using em instead of px a better for cross browser compatibility?
What helps a lot is using some kind of boilerplate starting point, that resets all browsers to the same base CSS (for so far possible). Specifically I've enjoyed HTML5Reset, you could just take the CSS reset file and see if it helps you.
This problem appears on every bit of text, no matter if it is table,div or something else
As you can see on every right side of text elements, 1-2 pixels is missing. Adding of padding never helps
Any suggestions please?
You could try to following fix for webkit browsers.
Replace the button span with your text class..
#media screen and (-webkit-min-device-pixel-ratio:0) { /* Safari and
Google Chrome only - fix margins */ your classname { margin-top: –1px;
} }
Have you set the viewport meta tag to specify its width and zoom scale? Maybe that would help? It's documented in the Apple dev docs
You could try using -webkit-font-size-adjust.
Look here for more info on it:
http://webdesignernotebook.com/css/the-little-known-font-size-adjust-css3-property/
This is happening probably because of
Inherited CSS property
If CSS does not seem to fixed it, check html doctype. Some tags although in rare cases do not work with certain doc types.
use !important attribute in CSS to enforce a certain rule be applied which discards all others.
try to set display: inline-block and a negative text-indent to <span> elements (embedded inside a webkit-only media query)
I have tried to deal with this problem for a month. Here what I have tried and found out. But I could not get actual solution;
I have followed up this thread, unfortunately nothing worked.
Tried several simple html documents with most possible doctypes,css,font-size,font-styles reset ..etc did not worked.
I discovered; when using with a remote url, it seems work fine, rendering is ok. When using embedded html pages, causing the problem.
In Titanium issue list; I have found out that, they represented as a Webkit bug.
https://jira.appcelerator.org/browse/TIDESK-136
Solution might be upgrading webkit version but Titanium has a lot functionality over webkit. So upgrading would not be an easy task.
My solution to this problem in TideSDK in windows was to do the following on the font in question:
font-weight: 600;
Maybe not the best solution for your application, (maybe you don't want to add any space or weight to the font since it seems you may have a much larger table of data to display) , but acceptable by my client.
I'm trying to make a custom checkbox, so I made something like that : http://jsfiddle.net/wQdUn/2/
The problem is that, on WebKit based browsers, the checkbox is toggled only when clicking on the content of the <span>, not on the box itself, while in Firefox I get the behavior I expect.
So I have two questions:
Which one is the right behavior (i.e. the one conform to specifications)?
How do I get the result I want in both browsers (and others...)?
Thanks.
Not sure about the first question, but if you make the span an inline block too, it'll work as you expect in WebKit browsers. See http://jsfiddle.net/wQdUn/5
For those who come to this topic form google:
Safari 6.0.4(8536.29.13) still got this problem, you need to set inline-block on pseudo-element to make click work.
Chrome switched to Blink as it's rendering engine, so this problem didn't happen on chrome any more(26.0.1410.65).