I am dynamically adding HTML from another page and styling it for print. However, page-break-inside: avoid;, when applied to my elements (any of them), does not seem to be taken into account when printing even though it shows up in the styles. I am using Chrome 31 on Windows
Here is a jsFiddle of the simplified version of my program (WARNING: It brings up the print preview after 3 seconds. To stop this simply comment out the setInterval at the bottom), This is the version where page-break-inside:avoid doesn't have any effect in print preview
The usual "fix" I've found, adding position:relative to the element and its parent, does not work in my case. Prefixing it (as a couple people suggested) doesn't seem to work either
I know page-break-inside: avoid; works in Chrome 31 with dynamically placed elements because I tested it out in a pseudo-version (WARNING: this also opens up print preview), but after spending hours removing code, playing around with the styles, and researching on the topic (most the posts are very outdated) I couldn't seem to get my more complex version working the same way
Thanks in advance for any insight!
Change display property on your #fromTumblr ID from inline-block to block.
It seems logical that page break rules don't apply on inline elements and since that ID is for wrapper element that exceeds page size I guess thats the reason all your other rules are ignored.
Here's updated fiddle, tested on Chrome 31 and FF26 on Windows: http://jsfiddle.net/FSyT5/27/
Related
There are so many issues with contenteditable divs and deleting html and/or non content editable content inside editable divs.
Using an answer by the excellent Tim Down here: How to delete an HTML element inside a div with attribute contentEditable?
Using Tim's code, the entire text node gets deleted. I need this to work like any textarea would, deleting character by character and just making sure html elements can be backspaced as well.
I tried the following
else if(node){
var index = node.length-1;
if(index >= 0)
node.deleteData(index,1);
else
this.removeChild(node);
}
But this is obviously not going to work correctly. If I am at the end of the content, things work as expected. But if I place the cursor anywhere else, it's still deleting from the end.
I'm lost at this point, any help is very appreciated
http://jsfiddle.net/mstefanko/DvhGd/1/
After breaking down how google uses contenteditable divs in their google plus user tagging, I landed on a much more reasonable solution. Maybe it will help someone else out.
After adding 1 tag, you can already see a lot of differences in the html browser to browser.
In Google Chrome, a space is added with each tag. The button tag is used. And the chrome-only contenteditable="plaintext-only" is used.
When I backspace the space in chrome, a BR tag is then appended.
In Firefox the BR tag is added immediately with the first tag. No spaces are needed. And an input tag is used instead of the button tag.
The BR tag was the single greatest break-through I had while digging through this. Before adding this, there was a lot of quirky behavior with deleting tags, as well as focus issues.
In IE, more interesting changes were made. A span with contenteditable false is used for the tags here. No spaces or BR tags, but an empty text node.
With all of that, you don't have to copy google exactly.
The important parts:
If you're rendering HTML, do the following...
1. Chrome should use the button tag
2. Firefox/IE should use the input tag
For range/selection you generally want to treat things like tags as a single character. You can build this into your range/selection logic, but the behavior of the input/button tags is much more consistent, and way less code.
IE behaves better in IE7-8 using a span. Just from a UI standpoint. But if you don't care if your site is pretty in old versions of IE, the input has the correct behaviour in IE as well as firefox.
3. Chrome only, use the contenteditable="plaintext-only" attribute on your editable div.
Otherwise, a lot of weird issues happen not only when a user tries to paste rich-text, but also when deleting html elements sometimes the styles can get transferred to the div, I noted many strange issues with this.
4. If you need to set the caret position to the end of the div, set the end of the range before the BR.
for FireFox:
range.setEndBefore($(el).find('br')[0]);
I just spent an hour troubleshooting an issue I had were all my paragraph elements were shifted down.
This happened after I moved the design from jsfiddle.net to my web host.
I killed an hour before I finally realized I needed to insert
p{margin:0px;}
and all was well...well still off by 1px;
Questions:
Why did this error not occur in jsfiddle.net?
Why does FF CSS Debugger not let me know that there is a margin in there or where it came from. I don't know what is was set to but it was not 0px;
I'm trying to learn from "my mistakes" so I can know what to expect next time.
Web browsers set their own default values for rendering HTML elements. This includes margins, paddings, font sizes etc. When you create a HTML document with no CSS you can see lists, paragraphs and headings are formatted in a default way.
Debuggers tend to show the values that you have applied to the document in your CSS.
To get around these sorts of inconsistencies (browsers use different defaults) some people use a 'reset' CSS file that removes this behaviour by setting as much as possible to 0.
Take a look at http://meyerweb.com/eric/tools/css/reset/
I have this website, http://www.escuelita.info. Now I tried many times to make it work on IE 7 (possibly IE6 too didn't check) but for some reason the middle frame on the right doesn't show content.
If you compare it to Firefox or Chrome (or even IE8) it works ok.
I need to fix this but I'm not sure what's causing the problem..
Note
I checked with IE7 and the pages don't show content
(the main content DIV content_outer)..
The content shows below the sidebar. Either IE7 enters quirks mode or you trigger some sort of bug that causes IE7 to misbehave.
Double check your doctype, tags and most importantly, get rid of those nested tables. Nested tables are EVIL and I'd bet they're your culprit. Use CSS grids (here's one that's really good: http://www.1kbgrid.com/) instead.
Dunno if this solves your problem, hopefully so.
I fall into an IE bug that I don't find a way to solve
Here's the template http://codecanyon.net/item/tquery-dynamic-tables/full_screen_preview/89478
If you open with Firefox or Chrome, the table header shows correctly, no BLACK, if you use IE7 or IE8, it shows some black space. Why? I tried to change padding, margin... but that didn't work, the black space is still glued. How can I fix such bugs?
Please also, explain what tools, or methods can help fix this bug
Update: Bug Fixed!
The reason is that IE gives an arbitrary size/padding/margin to the img element when the src is undefined.
When the src attribute is defined dynamically through JavaScript, this doesn't correct it. It still undefined, so it doesn't solve the problem.
Solution: Fix a height/width for the image.
The sort image you have in the cells still takes up space - in this case, the space used by IE's default "invalid image" placeholder, because you left the src attribute empty. You can verify this using Developer Tools, and setting the height to 1 pixel.
The problem is that visibility: hidden doesn't mean "don't use any space" - it means "claim the space, but don't show anything there". Use display: none instead if you don't want it to take up any space.
You may still wonder "But why didn't I see this anywhere else?" Well, that's due to the other browsers handling the missing image differently.
One tool that can help is the IE Developer Toolbar, which wil let you look at individual elements and the CSS applied to them. Looking quickly at the real page, not the link you sent (because the IE toolbar can't go through IFRAMEs for some reason), the one thing that pops out is the TD and TH elements in your table head show hasLayout: -1. It's a custom IE property that causes all sorts of bugs. You can read about it here. A couple of quick fixes you can try: apply 'zoom: 1;' or 'position: relative;' to those elements to see if it goes way. That's not a fix, it's a hack, but it often works.
I've been racking my brain trying to figure this one out as it's been a problem on the past few sites I've worked on (though they haven't gone live yet) and rather than trying to rig up a solution I'd like to try and discover the root of the problem.
Here's the site in question: (URL removed)
Basically I coded this homepage out as plain HTML and then inserted JavaScript and Flash elements as I completed them over time. When I got to adding the Flash (using SWF Object), I noticed that it had pushed the elements beneath it down roughly 5px, and only in Firefox and Safari (Internet Explorer, oddly enough, isn't affected). Turning off Flash or disabling JavaScript, which also turns the Flash off, removes this extra padding.
Can someone enlighten me as to what is causing this issue? I don't notice any major JS or CSS errors (other than a few hacks for IE), so I'm stumped.
Try to add line-height:0; to the div around the flash-swf:
<div id="flashDiv" style="line-height:0;">
This worked for me.
Try removing the whitespace between the DIVs on the page, and try putting the swf object into its own DIV. That way you can control what the page looks like without loading the swf, and it won't affect the other elements when it loads.
Try explicitly setting the margin and padding of the object element to 0px
You're using SWFObject 2.0, which does things slightly differently than the SWFObject of old. The old one would plant the embed INSIDE of a target div. The new one seems to actually replace the entire target DIV with an object tag.
Something I don't like, which is why I still use the old SWFObject.
SWFObject inserts an <object> element. Some browsers treat <object> as an inline element, some treat it as a block-level element.
The fix is to use CSS to ensure that objects are always treated as block-level elements:
object { display: block; }
See the SWFObject FAQ on the subject.