Some strange bug I came accross today when creating a generic button class to style everything from divs to inputs. It seems that most browsers use a different box model when it comes down to input[type=submit].
Most modern browsers (ie9+, ff, chrome, etc) use the content-box box model for all inputs except submit which uses border-box if im not mistaken.
Basically, if I set a height of 100 and padding of 10 all around, the height of all inputs except submit would be 120 where as the height of submit would be 100.
This is easily fixed using box-sizing and its browser prefixes. But my problem is with IE6/7 which do the same thing but do not support box-sizing...
so now all my inputs display full height except for submit which is cut in half. What options do i have to force content-box or another fix apart from conditional comments?
IE's old "broken" box model is essentially content-box. In IE>5 the document needs to be in quirks mode for IE to use it. You can trigger quirks mode by doing one of the following (according to wikipedia):
When the document type declaration is absent or incomplete;
When an HTML 3 or earlier document is encountered
When an HTML 4.0 Transitional or Frameset document type declaration is used and a
system identifier (URI) is not present
When an SGML comment or other
unrecognized content appears before the document type declaration
When there are errors anywhere in the document
Now of course, this probably makes more trouble than it's worth because it would make everything use the IE box model (content-box). I could see this being useful, but if your layout wasn't built this way, it's probably too much work to go back and change it.
I did some searching around and didn't find anything that would enable the old box model on certain elements, and not others.
Having dealt with IE6/7 in the past, there's really no way to get around it's buggy behavior without using something like conditional comments or css hacks. It's rendering engine is just fundamentally broken compared to other browsers. Trying to get it to behave without any hacks is just asking for headaches.
The only other thing I can think of is to surround each form element with a span or div, and use them to help size your form elements. This also sucks, but it has the advantage of at least working in every browser.
Related
I am using <p> tag for inserting Arabic text into the html page, and giving the CSS property text-align: justify; with particular width and height in pixels.
With this, there would be the paragraph including inconsistent space between the paragraph words; how can we use the same with proper word-stretching (with proper tatweel/kashida) inside the word?
I have tried it with the text-justify: kashida CSS property, but it's only working with IE, not for any other browser! As per the image shows, it is clear that the text-justify: kashida is not supported by Mozilla, and other browsers expect the IE.
How can I get the same behaviour in all browsers, to display the same as Internet Explorer?
Unfortunately seems kashida is dropped from CSS3 text and deferred for CSS4 text, so if you want justify your text with Kashida, you should try porting harfbuzz-old adding kashida algorithm (that its algorithm is removed from newer generation of harfbuzz, ref) which is based on a Microsoft specification that is archived here. Here is Microsoft's kashida insertion priority table that you should try to implement somehow:
ّAdding Kashida («ـ») for text styling on HTML itself is not a good idea (because if user copy the text it will contains added Kashidas and it will make problem for browsers find-in-page) however as current webkitbug/blinkbug (Safari/Chrome) versions do not support joining cursive script characters (like Arabic/Persian) during inline (pseudo)elements there seems there is not any chance you get this type of justification without inserting Kashida (or you should handle oncopy event by your own that has its own problems).
It is also interesting that Microsoft is extended IE Kashida justification implementation to support more interesting things like text-kashida-space (configure ratio of kashida to white space expansion while text justifying). Seems we must wait another decade to these get implemented across all major browsers.
The text-justify property was implemented in IE, and it is not part of any completed CSS specification. It exists in the Working Draft CSS Text Module Level 3, but even there, it is marked as being at risk: “The following features are at risk and may be cut from the spec during its CR period if there are no (correct) implementations: [...] the ‘text-justify’ property, particularly its ‘kashida’ value”.
From the authoring perspective, the best you can do is to hope that other browsers will catch up. The styling requested is relatively complicated and probably not anything you can imitate with JavaScript in the same sense as you can “polyfill” CSS properties
I'm putting together a page, and am really struggling with backgrounds across browsers.
The page uses a number of alpha-blended backgrounds, box shadows and border-radii and it is composited almost entirely using inline styles (essentially there are few/no CSS classes used).
IE9 is my primary browser, and in it, the page looks great. However, on Chrome (and I'm told Firefox), most of my alpha-blended backgrounds render either not-at-all (transparent), or as solid colors! I'm using Standards Mode with an HTML5 !DOCTYPE declaration, so it's not as though I'm leveraging IE quirks or anything!
Clearly on IE versions before 9, the backgrounds (and other things are problematic). But I'm not concerned with supporting ancient software, and those users get a browsing experience that they deserve.
The common refrain for years has been that "transparency on IE sucks!", so I was comfortable in expecting that if I got it to work adequately on IE (typically the worst platform), then the others would just fall in line, but here I am struggling in the opposite direction! I'm using the standard "rgba(r,g,b,a);" directive on the "background-Color" attribute so I'm not using any radical DirectX filters or other magic, nevertheless, on (NOT Internet Explorer 9+) browsers, I'm getting some non-alpha-blended results (sometimes it works, sometimes it doesn't).
The site can be previewed at: https://net-xpert.com/ -- All of the pull-down menus are supposed to have translucent backgrounds, and so too the hovering link-bar at the bottom of the page. Also if you go to the "Ask us a Question" page, the dialog there should have tinted backgrounds on all of the input fields...
Oh, lastly, I am ENTIRELY LOATHE to implement ANY b/s, browser/platform-specific, 'experimental' style-codes! Anything in CSS2/3 is fine, but I simply REFUSE to use any kind of "-browser-some-quirky-CSSAttribute" styles! (I wish more developers would do this too! -- then browser manufacturers would be under greater pressure to adopt these STANDARDS and our lives would be SO MUCH EASIER, but I digress...)
Anyway, any insight on a standards-compliant solution would be greatly appreciated (even if it's just a communal acknowledgement that "ya, Chrome et al is currently not implementing this correctly...", at least then I'll know there's nothing to be done about it...)
Thanks!
Well, this is a very late answer, but maybe this'll still be of use to you (your site still seems to be up and running).
I have a should-work-for-you solution, assuming that you can modify one of your stylesheets. As to WHY you've encountered this problem ..? I can only speculate, because I don't know how to recreate your exact configuration.
The fix;
div[id^=mainMenuOverDiv] {
background-color: rgba(128,128,128,0.9) !important;
}
I'm not a fan of using !important unecessarily, and you may be able to remove that by using greater specificity. I've tested this in Firefox, though and it seems to work - obviously, you'll want to substitute the actual rgba(x,x,x,x) values with your own.
You seem to be using some JavaScript (I'm assuming) which randomizes the DIV ID every time you hover over the menu - but the beginning remains consistent (i.e. one time it will be #mainMenuOverDivjkhasdfsd89f9f9sdfl3l4l34lfdbvbc, then the next, it'll be #mainMenuOverDivLSDklsdkmlzxncbzmxnc90234xcvassf). Using the 'starts with' CSS selector (as provided in the example), you can still isolate the menu despite this potential spanner in the works.
It's interesting (and probably insightful) that this even works, given that inline CSS usually can't be overridden.
As for why this is happening, one possibility is that some JavaScript generated code is not correctly porting over to the non-IE browsers. Alternatively, if you're using it anywhere, code minification may also break some functionality (and vary between browsers) - many minification plugins need to be tweaked for individual setups to ensure that everything continues to work fine as one size does not necessarily fit all. For example, you might find that on one site you can minify everything except the JavaScript, while on another site, JavaScript is fine, but you can't minify inline CSS, etc. Google Analytics code sometimes falls victim to this.
So to my eye, the issue possibly isn't to do with IE/Chrome/Firefox or Safari - transparency is working fine on all of them - I think it's most likely the way your code is being manipulated or delivered to the browser.
Hope that helps in some way. Let me know if you can't use an external stylesheet and I'll try to find an alternative.
I think this is a bug with Mozilla (Firefox) up through the present 17.0.1. Hopefully folks have work arounds.
See the example http://jsfiddle.net/dd3pQ/
The CSS3 property scale3d scales the elements in a page, but ignores the OPTION elements of the SELECT drop down list. As you can see, they are rendered to the left of where they should be, in the page they would have originally been if not scaled.
We need to use scale3d in our app, but we also need drop down lists. Is this possible with Mozilla right now?
The dropdown is rendered by the operating system, and the OS doesn't give browsers hooks to style it.
Because form elements are limited by the OS capabilities, CSS doesn't require browsers to style them at all (they are "replaced elements" in CSS terminology, like contents of <img>). So, technically, that's not a bug.
HTML5 allows for links to be wrapped around block elements (one or several), but how exactly will it render in older browsers? Let's say to go as far back as IE6.
I haven't found full details yet (but there are some examples).
The markup would be as follows:
<a href="http://example.com">
<section>
<h3>Heading</h3>
<p>Text</p>
</section>
</a>
Also, would the most semantic way to make it compatible in older browsers be to wrap the links inside each block element separately? I've seen suggestions to replace the block elements with span, but that'd make it inline and alter the meaning of headings.
I've noticed that even modern browsers (e.g. Safari on iOS 6) do weird things. For example, try clicking on the image in this JSFiddle from your mobile brwoser — even though it shares the link with the caption below, the caption doesn't get highlighted for me. Furthermore, when clicking the caption, the image nor caption get highlighted.
As far as I know, the behavior is generally the same as modern browsers. Everything in the sample markup given will turn into a single hyperlink. This is regardless of whether or not you include the HTML5 shiv for older IEs to recognize the new semantic elements.
This is probably because there's nothing in HTML that says a specific starting tag should automatically close an unclosed <a> tag — the end tag is required to denote the end of a hyperlink.
And yes, that's how I'd do it to preserve semantics if I want to conform to an older HTML doctype. It's not required for HTML5 conformance though, since it works based on the assumption that even older browsers already behave this way (backward compatibility and everything).
Relaxing the content model for a in HTML5 is based on observations on actual browser behavior: the original syntactic requirements were not really enforced. This can be expected to go as far as you can get. (I tested this on IE 6 and Firefox 3.)
So there is no need for compatibility. But it would surely not be “semantic” to split a link element. Two links are semantically different from one link, for any reasonable semantics for “semantic”. It would also be a usability problem, especially when using the keyboard to move between links.
The visual rendering is a different issue. It is not clear at all, from the HTML5 drafts or from practical considerations, how a link should be rendered, in its different states, when it may contain just about anything. This may have been a key reason behind the old syntactic requirement. Browsers do not render such links consistently. This applies at least to underlining. There can be functional differences, too; e.g., on some browsers, the area on the right of the heading text is not clickable, i.e. only the text is “active”, whereas other browsers make the entire area of the element (which is by default the entire available width for a heading) “active”.
So the basic issue, if you wish to use such a link, is to consider how you intend to have it rendered and how to do that in CSS in a manner that works reasonably cross-browser.
It's always been a pain to me working with form elements and css. Besides using flash, is there anyway to to customize a scrollbar in a <textarea>, I'm aware of jscrollpane, but from what I've seen it only works on divs, and I'm not jquery savvy enough to tinker around in there.
I'm also aware of this example, but it only works in IE, and, so I've read only in quirks mode.
scrollbar-3dlight-color:black;
scrollbar-arrow-color:black;
scrollbar-track-color:black;
scrollbar-darkshadow-color:gray;
scrollbar-face-color:orange;
scrollbar-highlight-color:gold;
scrollbar-shadow-color:brown}