On my homepage and a few others, Internet Explorer and Edge are placing my read more links next to tables that use display: block value. The table and the links are in separate divs. It seems that the Microsoft browsers are confusing block with inline-block.
Anyone had this problem? Are there alternatives that function in IE and Edge?
http://tenbooksamonth.com/
From what I can see such behavior is some-how caused by the word-wrap property in you responsive.css file. If you turn it off, site looks fine.
Before
After
p.s. Not sure what are actual display modes for the divs, as they are positioned thru some grid framework.
Related
I want to create a left border on a div but only on 50% of the div. I have created the following code which works in everything else than IE.
I run IE11 atm and i have tried other versions as well which shows the same error.
Here is a Fiddle:http://jsfiddle.net/0ffmrxpz/16/
If you remove the "display:table-cell" it will work in IE. But because of my end-design I can't remove or change this display. If I do so i break the entire design setup.
This is a known interop-issue between Internet Explorer and other browsers. We have actually already began shipping changes to the underlying engine to better-render this use-case.
Below is a side-by-side of Internet Explorer 11, and our streamable in-development version on http://remote.modern.ie, also available in our Windows 10 preview:
The primary culprit here is the use of display: table-cell; other than that, pseudo elements, borders, and everything else will work as expected in Internet Explorer. It's only when you use properties designed for tabular data as a layout-mechanism that you currently face this issue.
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 have a page which appears just fine in FireFox / Chrome / Opera / Safari, but appears incorrectly in Internet Explorer. A quick search reveals many issues with DIVs in IE, but none of the items appeared to address this issue.
The issue is that DIV appear to expand to the entire width of the browser, in Internet Explorer; this behavior is not replicated in any of the others.
Code is here: http://pastebin.com/c46uB7GP
CSS is here: http://pastebin.com/TXWWM2Qu
IE rendered image is here: http://imgur.com/Pciv5
Chrome rendered image is here: http://imgur.com/8kwd4
Any help would be welcome in resolving this discrepancy.
Thanks,
R
You have no layout width/height specification in your current code.
Put the content inside an enclosing div that has a width specified in pixels.
It's also better practice to identify your divs with classes (or IDs, if there is only one of them) and define the actual CSS in the CSS file and not in the HTML. This way you can separate presentation from markup, so that you could send the same HTML to, say, a mobile device, but with a different CSS file for that device.
I have this small testcase: http://jsfiddle.net/sV8js/
You can see that in Chrome (tested on win7 11.0.696.68) the first 2 links right border is "cut off" and is not shown. FF and IE 7/8/9 seem to show it OK.
Browsershots: http://browsershots.org/http://top3skills.com/1.html
Also "buggy" on Safari (so it's webkit related?)
Anyone knows what's the problem with this approach or how to solve this?
(or if I should report a bug to chrome) Any workaround that doesn't affect other browsers?
Also, my testcase is different from Right border not displaying on google chrome but maybe it's the same bug?
Updated: I don't want to use inline-block as IE7 doesn't support it and I'm finding this bug because I'm removing the inline-block I previously had there :) Also this is dynamic so it's not easy to add after each link because some links can break to a new line, others don't... so I'm trying first to get the "right way" and then resort to more "tricky" ways.
You have set the containing DIV at a fixed width of 250px. This is cutting off the edges. Also, you should add display:inline-block; to your CSS link class. This will make your link a block element while keeping it inline. It will also apply the padding you have asigned properly.
See updated link here http://jsfiddle.net/sV8js/12/
Dan
Try giving those links a display: inline-block or display: block property, as links are inline elements.
you need to add display: block to .referencesSkills
http://betawww.helpcurenow.org/media/press/
You'll see I have used spans within an anchor, with the span.hover-description set to display:none; by default, and on a:hover that span is set to display block and absolutely positioned to create a tool-tip effect when hovering over the name and email of the "For Immediate Release" contact names.
Everything looks as desired in Firefox, but Chrome reveals my unknown blunder somewhere.
Any help on what's the problem that is causing Chrome to not display like Firefox?
Incidentally, Explorer shows the tool tip as expected, although I'm getting a funky bottom margin issue below the names, and Safari has the same issue as Chrome (must be a webkit rendering setting that I need to accommodate for).
OK, I figured it out. Since I'm using a pretty complex nesting structure to accomplish the CSS tool-tips, I overlooked the fact that I had actually nested a p tag within a p, and of course that is a no-no.
Firefox is really friendly to a lot of validation errors, but Chrome and Safari seem to be much more strict.
In the end I changed the p's to span elements and all is well across browsers.