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.
Related
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.
I am using a WebView inside one of my programs and there is a <select> tag inside the HTML page I'm rendering. I would like to add icons to the <option> elements it contains, like this:
(The shadow effect is not there, so it can be easy to miss out that this is a dropdown list; but it is.)
Is that possible? All my efforts to style <option> tags or put images in them so far have failed.
Since it's not ever going to be displayed by another rendering engine, I only need it to work with the WebKit. I'm also fine with a solution that involves WebView trickery and that would never work in a browser, although it would be kinda neat if it did work in a browser too.
This is not possible in webkit browsers using just css at this point in time. It is possible in Firefox, but not webkit.
You will need to use javascript to replace the select box with stylable elements.
The following post answers this:
How to add a images in select list
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.
I have built a custom context menu but have found annoyingly that when I right click on my site in firefox text and images just seem to randomly get selected.
The link below is a basic html dump of the page that is having issues. You can see that when you right click it in Firefox, certain elements are highlighted. Very annoying! This must be a purely html markup problem in Firefox as there is absolutely no CSS or JS on this page.
Example Here:
http://pastehtml.com/view/1e16jup.html
Love to hear your thoughts/suggestions...
There are a lot of errors in this page have a look at the validator result here.
Maybe it gives firefox a lot of problem rendering the page properly.
Close all the <meta> and <img> tags, <script> must have proper type attributes, tags like <h1> shouldn't be placed inside of <a>, <p> neither.
I'm assuming you mean the HTML5 contextMenu? Because this is not implented in any browser.
A bit of quick investigation seems to demonstrate that the header+footer elements have this behaviour. Also, lists appear to have it as well. This is because those elements have a certain semantic use and this behaviour seems consistent with those semantic uses. Check out the specification to see how these elements are intended to be used.
I'm firing blind but I'd suspect you can override this with -moz-user-select - but this is going contrary to the Firefox user experience. I wouldn't recommend it at all.
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}