I am trying to make a horizontal nav that can contain multi-line content in each navigation element and have each item's height be the same.
Here is a partial solution that should explain what I'm after, using display:table.
Unfortunately display:table doesn't work in Internet Explorer 7 which (+html5 shiv) will be the primary browser for viewing the page (corporate and internal). Even here the problem is that the <a> only fills up as much space as the content, when I want it to be active everywhere inside the li (as if the <a> tag were wrapping the <li>, which is not allowed)
I want it to be as semantic as possible, and hopefully not use tables (though if that's the only way.. it's the only way). Is there any way to achieve this? (even in a table right now it's not quite working)
Is it an option to use jQuery?
You could solve it then this way: http://jsfiddle.net/nywYz/2/
Related
I have a bunch of divs in a webpage that need to be moved to completely different parent divs based on screen size.
At the moment I am repeating the divs and setting the display property to either none or block etc based on screen size.
First question is is there a better way to do this using html or css only?
Secondly does the display:none allow use of duplicate div id's or is that just plain bad coding?
thanks
You can use Flexbox's flex-flow to move elements and content around with HTML. I'm not sure about browser support though. A JavaScript solution would be better in this case.
As for your second question, duplicate IDs isn't a CSS problem, it's an HTML problem. It's not allowed whether you use CSS or not. So no, don't do it.
I have a HTML 5 drag and drop game that doesn't work in IE so I want to basically just show the answers in the form of an image. At the moment I'm using CSS to hide the game div in IE and display a div with using display: block; to show the image and hide it using display: none on browsers like Chrome.
Is this an ok way of switching content based on browser or is there another method I should be looking at? What is the correct way to do this?
The only draggable elements in IE are the <a> and <img> elements.
Some people just wrap their (text) content with <a> tags that go nowhere, as is seen in Remy Sharp's demo: http://html5demos.com/drag. This works just fine in IE9, and probably older versions of IE.
So the "correct" way to handle IE is to use those elements.
I've got myself multiple a tags floating on a page.
They have been styled in a unique way to center an image horizontally inside it, using a span and css. The a tag itself has fixed width and height.
I thought this was basic stuff, and my theme was causing the issue, but I've created a stripped down jsFiddle and I'm still getting the same problem when running the jsFiddle in IE 7.
The a tags are all click-able in every browser apart from IE7, why is this happening?
Can anyone explain? Thanks.
http://jsfiddle.net/motocomdigital/Qk9tu/6/ - Test click-able state in IE7, works fine everywhere else.
Don't worry about IE 6 - I'm not coding for this anymore.
On IE, a link element (<a></a>) with an empty attribute href doesn't display a link-cursor (hand).
Either put a # in your href attributes or add a cursor:pointer on a.home-module
It's the spans inside the a that cause the trouble...
You can achieve what you are trying to do with just CSS, but it requires a slightly different layout in your HTML and some extra CSS.
JSFiddle - http://jsfiddle.net/8E8um/2/
Note
In a.home-module I have added a transparent image. This is because IE7 will not assign an "empty" parameter (due to the negative text-indent) to the top level and would therefore still leave the link unclickable.
you should assign "#" to href attribute.
Try this: http://jsfiddle.net/Qk9tu/5/
Thanks to Jonathan Amend, the css is now fixed in iebug.html below.
It's hard to really explain this problem without looking at it in IE6 or IE7, but anyway if you have a look at the following pages on IE6 & 7 you'll see next to "send me a brochure" and "I would like more information on (tick one or more boxes)" the checkboxes and their labels have been mysteriously pushed or pulled down for some reason:
http://sonic.huntinternet.com/iebug.html
I've tried altering the margins and padding on all my elements to 0 yet this has no effect on IE6&7 - meaning I think it's a bug of some kind.. however I don't really have enough experience to know what bug to even look for so any kind of pointer would be nice.
FYI I've used a guide off the sitepoint website that suggested using nested lists, but really that shouldn't make any difference. Both the xhtml and css are valid according to w3c's validator.
Thanks for your help!
John.
Add *display: inline-block; to your .enquiry-form ol li. This is a common bug with how IE 6/7 clears list items (block elements by default) onto new lines.
For this, it's being pulled down because your floated label is two lines long in copy, so the OL is aligning it's top position to the top of the second line.
A solution that comes to mind here is to make the OL floated left as well. This will, of course, require that each LI has the clearfix styles on it (styles for clearfix can be found here: http://net.tutsplus.com/tutorials/html-css-techniques/css-fudamentals-containing-children/).
I'm working now on a page that has a column of boxes styled with sexy shadows and corners and whatnot using the example here. I have to admit, I don't fully understand how that CSS works, but it looks great.
Inside the topmost box is a text-type input used for searching. That search box is wired up to a YUI autocomplete widget.
Everything works fine in Firefox3 on Mac, FF2 on Windows, Safari on Mac. In IE7 on WinXP, the autocomplete suggestions render underneath the round-cornered boxes, making all but the first one unreadable (although you can still see enough peeking out between boxes that I'm comfortable IE7 really is getting more than one suggestion).
Where could I start looking to correct the problem?
Here's what success looks like in FF2 on WinXP:
And here's what failure looks like in IE7:
Jeremy,
Sorry for this being so late, but hopefully the answer will be of use to you in a future project.
The problem here is that IE creates a new stacking order anytime there is an element with position:relative, meaning that z-index itself is not the only controlling factor. You can read more about this here:
http://therealcrisp.xs4all.nl/meuk/IE-zindexbug.html
To solve the problem, if I'm understanding your problem correctly, apply position:relative to the container that wraps your whole autocomplete implementation (and then position:absolute to your results container). That should create an independent stacking order in IE for those elements that allows them to float over the other position:relative stacks that appear later in the page.
Regards,
Eric
The working solution I finally implemented was based on reading this explanation over and over again.
In the underlying HTML, all of the blue rounded corner elements are DIVs, and they're all siblings (all children of the same DIV).
The z-index of the autocomplete div itself (which is the great-great-grandchild of the rounded corner container div) can be arbitrarily high, and it won't fix this issue, because IE was essentially rendering the entire contents of the search box below the entire contents of the "Vital Stats" box, because both had default z-index, and Vital Stats was later in the HTML.
The trick was to give each of these sibling DIVs (the blue rounded corner containers) descending z-indexes, and mark all of them position:relative. So the blue div that contains the search box is z-index:60, the "Vital Stats" box is z-index:50, "Tags" is z-index:40, and so on.
So, more generally, find the common ancestor of both the element that is getting overlapped and the element that is overlapping. On the immediate children of the common ancestor, apply z-indexes in the order you want content to show up.
I'm not totally understanding the setup that's leading to the problem, but you might want to explore the useIFrame property of the YUI Autocomplete object -- it layers an iframe object beneath the autocomplete field, which allows the field to then float above the objects that are obscuring it in IE's buggy layout.
http://developer.yahoo.com/yui/docs/YAHOO.widget.AutoComplete.html#property_useIFrame
But the docs say that this matters in 5.5 < IE < 7, so this might not be the issue you're experiencing. So again, without totally understanding the setup you're working with, you might also want to try to experiment with various z-index values for the autocomplete field and the surrounding block-level elements.
Make sure the z-index of the auto-complete div is a larger number than the divs that constitute the rounded corner box. Microsoft puts the z-index of the top elements to 20000 or 100000 I believe. Might be wise to do the same.
I had a similar problem to this, I fixed it by basically just changing z-index for the different divs. Just setting higher number for each div in the order it should display.