iFrame has fixed width of 300px, without any styling defining 300px - javascript

I'm using the iframe-resizer package to dynamically change the size of an iframe depending on content.
However, before even trying any dynamic resizing, I run into an issue with the basic iframe: it's always 300px in width. Whatever content I place inside the iframe, the width is always 300px. Will not move; overflow is hidden if I add something >300px and still takes up 300px if my content is smaller than that.
EDIT: To be clear, My problem is that I want to dynamically change the width of an iframe (cross-domain), but it always renders at 300px and will not change. I'm using the iframe-resizer package to successfully dynamically change the height, but that's nto working on the width.
In the parent site, I'm embedding the iframe as follows:
<script type="text/javascript"
src="https://cdn.jsdelivr.net/npm/iframe-resizer#4.2.11/js/iframeResizer.min.js">
</script>
<script type="text/javascript">
var i = new URLSearchParams(window.location.search).get("openWidget"); document.write('<iframe id="inlineFrameExample" title="Inline Frame Example" style="position: fixed; zIndex: 1000; bottom: 0; right: 0" frameBorder="0" scrolling="no" src="http://localhost:3001?openWidget=' + i + '"></iframe>');
window.iFrameResize({ log: true }, '#inlineFrameExample')
</script>
And the content in my for my framed site, I have the following elements and styling:
<div className="App" id="App2">
{openWidget && <div className="button">OK</div>}
{showMessage && <section>This is a message</section>}
<div>
<button className="button" onClick={() => setShowMessage(!showMessage)}>
Msg
</button>
<button className="button" onClick={() => setOpenWidget(!openWidget)}>
{openWidget ? "-" : "+"}
</button>
</div>
</div>
.App {
text-align: center;
float: right;
}
.container {
display: flex;
justify-content: flex-end;
float: right;
}
section {
background-color: mediumseagreen;
color: white;
width: 500px;
}
.button {
width: 100px;
height: 100px;
background-color: mediumseagreen;
color: white;
text-align: center;
float: right;
}
Note that there's nothing in there about width being 300px. There are other widths, but the iframe seems to ignore them and always set itself to 300px.
I also made two code sandboxes, and embedded one site in the other via an iframe. Unfortunately the iframe is hidden for some reason, but if you inspect and look for the iFrame with id="inlineFrameExample" (and not code sandbox's button iframe) you'll see it's 300px wide: https://exzts.csb.app/
The code for the parent site is here: https://codesandbox.io/s/eloquent-flower-exzts?file=/index.html
The code for the framed site is here: https://codesandbox.io/s/iframe-test-ss8fs
UPDATE: I also removed all css styling from both the parent site and the framed site. Still always stuck at 300px. I also viewed the CSS specs which says default will be default set to 300px under certain conditions, but I cannot figure out how to dissatisfy those conditions so that the 300px rule doesn't apply.
I want the iframe to resize based on width. The current set up works perfectly on height, and I understand there's something in the default specs for iframes that sets them to 300px if x conditions are met: w3.org/TR/CSS2/visudet.html#inline-replaced-width What I need is whatever styling/setting/attribute will disable this, so the width will act in the same way as the height (i.e. completely dynamic).

The iframe-resizer doesn't resize iframe width by default. You have to explicitly specify it using sizeWidth setting.
window.iFrameResize({
log: false,
sizeWidth: true,
checkOrigin: false,
widthCalculationMethod: "rightMostElement",
heightCalculationMethod: "lowestElement"
}, "#myFrame");
body { background-color: wheat;}
iframe { border: 3px dashed green; }
span { font-size: 1.5rem;}
<script type="text/javascript" src="https://cdn.jsdelivr.net/npm/iframe-resizer#4.2.11/js/iframeResizer.min.js"></script>
<div>Following iframe grows automatically!</div>
<iframe id="myFrame" scrolling="no" src="https://mvyom.csb.app/"></iframe>
<span>😵😜🤪</span>
The iframe content is animated so it affects iframe's width and height according to the specified width and height calculation methods. And the iframe-resizer updates dimensions on every animations start and end event.
Also, the iframe source is from codesandbox and the parent document is this StackOverflow answer page, so we need to set checkOrigin: false as well.
Note: Had to set log: false because the animations are happening very fast creating ton of logs in console.
You can provide your own size calculations form inside the iframe.ref:
<script>
window.iFrameResizer = {
widthCalculationMethod: function () {
return document.querySelector(".one").clientWidth;
}
};
</script>
In following demo the iframe resizes exactly to the width of green box.
window.iFrameResize({
log: false,
sizeWidth: true,
checkOrigin: false,
widthCalculationMethod: "rightMostElement",
heightCalculationMethod: "lowestElement"
}, "#myFrame");
body { background-color: wheat;}
iframe { border: 3px dashed green; }
span { font-size: 1.5rem;}
<script type="text/javascript" src="https://cdn.jsdelivr.net/npm/iframe-resizer#4.2.11/js/iframeResizer.min.js"></script>
<div>Following iframe grows automatically!</div>
<iframe id="myFrame" scrolling="no" src="https://mvyom.csb.app/custom.html"></iframe>
<span>😵😜🤪</span>
Refer implementation of custom.html for better understanding. You can implement similar method for heightCalculationMethod.

Not sure if I understand the question. I think you've made an App and a page. On the page you want to use an iframe to show your App and the iframe should be scaled by default to the size of the app. Did I get that right?
I think JavaScript might by your solution. Get the content from the iframe, check in the content for a class App en that's the width you want to use for your iframe.
const iframe = document.querySelector("#inlineFrameExample");
const iWindow = iframe.contentWindow;
const iDocument = iWindow.document;
const iElement = iDocument.querySelector(".App");
iframe.style.width = iElement.style.width;
A problem with this script is that it can only be executed after the content from the iframe was loaded. So make sure you wait for that with a timer,delay, promise, or something. If you don't want to show the resizing to your visitors make sure the iframe has visibilty: hidden and add visibilty: visible of the iframe to the end of the script above.

#crevulus, the inner content of iframe has no impact on the dimensions of it's parent iframe by design
Also, as far as I remember, 300x150px is the common default width and height applied by browsers to any «iframe» element faced in html code on parsing incoming html and building the DOM stages, when the dimentions have been not predefined explicitely
The thing is a browser requires the dimentions of any visible element (i.e. any element that takes space in page layout - for simplicity, let's say any element except those where «display» property has been set to «none») either to be strictly predeclared with «width» and «height» properties (via element attributes with the same names, via internal / external css rule or css rule applied to element directly thru «style» attribute - the way doesn't matter) or to be calculable thru initial (default) values defined in html / css standards (again, for simplicity, if «div» element has no dimentions set, but all the neighbours do, its width will be calculated by browser as all available horizontal space between the left and right neighbours of the element, i.e. the «div» will always have initial width, defined by standard, which equals 100%; similary, the height of this «div» will be calculated as sum of heights of all its internal elements) - the dimentions are strictly required because w/o concrete values for every visible element on page a browser won't be able to render the page content for the current viewport correctly
So, when a browser parses incoming html code and faces «iframe» elements with no predefined dimentions (via attributes, css et cetera), to allocate the space for the element in page layout and thus to be able to move on to parse / render the whole page, a browser assumes the dimentions of the «iframe» as common defaults, which, as I mentioned above, equals square figure 300x150px («recumbent skyscraper»)
To override this behaviour, you should predeclare in any convenient way initial values, which will be suitable for your case
<iframe id="frame1" width="100%" height="250px" />
or
<style>
#frame1 {
width: 100%;
height: 250px;
}
</style>
<iframe id="frame1" />
et cetera, and then, when a page is rendered, if needed, use JavaScript to tune the dimensions of this iframe accoring to the width and height of its content (or any other condition on your choice), like
var frame1 = document.getElementById('frame1')
var width1 = parseFloat(frame1.style.getPropertyValue('width')) | 0
var height1 = parseFloat(frame1.style.getPropertyValue('height')) | 0
/*
* some stuff to define the conditions for iframe dimentions tuning and
* to calculate new width and height and to assing calculated values
* to width1 and height1 variables respectively
*/
frame1.style.setProperty('width', width1 + 'px')
frame1.style.setProperty('height', height1 + 'px')
As a postscript I'd like to note the above is the working concept, 'cause a few month ago I've designed and developed the close scheme to force the iframe of TinyMCE editor, built in Magento 1.9.x admin backend, to keep editor's width always equal to the width of CMS page on site's frontend and to expand / shrink editor's height dynamically accoring to the height of CMS page content being edited
The goal was to simplify and optimise the working process for the content department by making CMS pages in Magento admin area always look in TinyMCE editor exactly the same as on site's frontend
Unfortunately, the whole 1st gen of Magento, up to the last 1.9.4.5 release, is supplied with unspeakable outdated release of TinyMCE editor - 3rd gen of TinyMCE, published in early 2014 even before html5 officially arrived, in comparison even with it's own current 5th gen (which, in turn, frankly, is much inferior to alternative modern lightweight apps of WYSIWYG class) for 2022 feels like the Stone Age, a clumsy craft developed with stone axe by cave dwellers, both in terms of stability and functionality
In other words, that TinyMCE is missing the lion's share of useful builtin APIs / plugings, including the modern one to maintain the editor's dimentions in nominally simplified way, so the only way to achieve the goal I've researched has been to utilize onInit and onChange events provided by TinyMCE3, and to maintain the whole routine with custom JavaScript handlers over the editor, applying the dimentions directly to iframes on the parent level in Magento admin page code, which Magento core utilizes as containers for TinyMCE3 instances
Anyway, the experiment has been successful, so please feel free to ask any additional practical questions or to request some tech details on routines

The good news
If the page loaded by the iframe is on the same domain as yours, then you can easily find out the initial state by defining an onload attribute to the iframe and then access the contentWindow of the iframe and do some measurements and then apply them on your main page. But, as you said, the content of the iframe is from another origin. Bad luck, read on.
Some hope
Well, we know that you cannot directly access the content of the iframe. But, the content of the iframe may let you know when certain events happen. If the content inside the iframe does send messages, then you can addEventListener for message type events and specify the origin to be the site you are using inside the iframe. More info here: https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage
So, the site inside the iframe does some messaging? Maybe yes. But probably not. If it does not message you at the time of events of interest, then read on.
The bad news
Modern browsers do not allow you to directly run Javascript at other origins due to security reasons. One obvious example for this is that cookies can be read for a page and you absolutely do not want some third-party sites to mess with your cookies while you are doing a banking transactions or something of the like.
Some glimmer of hope
You may be able to somehow determine the current state of the iframes content. For example you may have access to API functions or something of the like that you can ask about your status. If those are leaking direct information about your situation inside the iframe (was the button clicked already, for instance?), then you may be able to poll such a source and see whenever a size changing event happens and if so your code could adapt your view accordingly. This way you would use another source of information to find out what is happening inside the iframe.
Sad but true
In general, the answer to your main question is NO. The explanation is that it is not allowed due to security reasons.
You may have some workarounds in your specific situation that may work out for you, but such workarounds are rarely available, most websites are working without providing supports for other websites that would like to use them in iframes. If the workarounds are not available for you, then you may want to reach out to the owner of the website shown in your iframe and see whether he/she is okay with providing support for this. Otherwise you will have to accept that the situation is beyond repair. Is it? If you are not satisfied yet, read on.
Desperation
If you really, really need to resolve this, then here's what you can do:
create a page in the same domain as your main page
from the browser's point of view both your main page and the page inside the iframe are using the very same domain, so they can reach each-other via Javascript
this new page will request the site to be shown in the iframe where the page of the other domain was shown previously (you don't create a further nested iframe, you just change its src)
and it will display it
but you add a little bit of Javascript, doing some measurements
and of course you adjust resource URLs accordingly, changing all relative URLs into absolute URLs
This might work, but it's very cumbersome and you will always need to adjust the given page whenever the site you are to use changes.

Related

Display dynamic html content like an epub/ebook, without converting html to epub format?

I want to create a responsive, mobile optimized reading experience similar to an epub/ebook reader, like the Kindle app, or iBooks, using dynamic html as the source.
Imagine a long article or blog post that requires a lot of vertical scrolling to read, especially on a small mobile device. What I would like to do is break the long page into multiple full-screen sections, allowing the user to use left/right navigation arrows and/or the swipe gesture to "page" through the article.
There are many JS libraries available that can create a "slide show" or "carrousel" of pre-defined slides (using divs or other container elements). But I want the text and html content to dynamically re-flow to fit any device viewport and still be readable... just like an epub/ebook user interface, like the Kindle app or iBooks. So, for the same article, there would be many more "pages" on a phone than there would be on a tablet or desktop viewport, and those "pages" would need to be dynamically created/adjusted if/when the viewport size changes (like switching from portrait to landscape on a mobile device).
Here is an example of a javascript .epub reader: epub.js
... notice the responsive behavior. When you resize your viewport, all the text re-flows to fit the available space, increasing or decreasing the total number of "pages". The problem is that epub.js requires an .epub file as its source.
What I want is the same user interface and functionality for an html page.
I have searched and searched for some kind of library that can do this out of the box, but haven't been able to find anything.
I realize that I could use a conversion script to convert my html page into an .epub file, and then use epub.js to render that file within the browser, but that seems very round-about and clunky. It would be so much better to mimic or simulate the .epub reader user experience with html as the direct source, rendering/mimicking a client side responsive ebook user experience.
Does anyone know if something like this already exists, or how I could go about building it myself?
The crucial functionality is the dynamic/responsive text-reflow. When the viewport dimensions are reduced, the text/content needs to reflow to the next "page" to avoid any need for vertical scrolling. I don't know how to do this efficiently. If I were to code it myself, I might use something like the jQuery Columnize plugin, setting all columns to width: 100vw; height: 100vh, so that each column is like a "page", and then figuring out how to create a swipe UI between those "pages".
Any help is much appreciated!
This becomes very difficult if the html page is complex, eg with precisely positioned elements or images. However if (as in the epub.js example) the content consists only of headings and paragraphs, it is achievable.
The basic idea is to progressively add content until just before the page overflows. By keeping track of where we start and stop adding content, clicking to the next page is a case of changing the page start to the previous page end (or vice versa if you're going back).
Process for reshaping content into pages
Let's assume you have all your content in one long string. Begin by splitting all the content into an array of words and tags. It's not as easy as splitting by whitespace as whitespace between < and > should be ignored (you want to keep classnames etc within each tag). Also tags should be separated as well, even if there is no whitespace between the tag and a word.
Next you need a function that checks if an element's contents overflow the element. This question has a copy-paste solution.
You need two variables, pageStart and pageEnd, to keep track of what indexes in the array are the beginning and end of the current page.
Beginning at the index in pageStart you add elements from the array as content to the page, checking after each add whether or not the contents overflow. When they do overflow you take the index you're up to, minus 1, as the index for pageEnd.
Keeping tags across page breaks
Now if all's ticketyboo then this should fill the page pretty well. When you want to go to the next page set your new pageStart as pageEnd + 1 and repeat the process. However there are some issues that you may want to fix.
Firstly, what happens if the page overflows in the middle of a paragraph? Strictly speaking the closing tag, </p>, is not required in HTML, so we don't need to worry about it. But what about the start of the next page? It will be missing an opening tag and that is a major problem. So we have make sure we check if the page's content begins with a tag, and if it doesn't then we get the closest opening tag prior to the current pageStart (just step back along the array from pageStart) and add it in before the rest of the content.
Secondly, as shown in the example, if a paragraph continues onto the next page, the last line of the current page is still justified. You need to check if pageEnd is in the middle of a paragraph and if so add syle="text-align-last:justify;" to the opening tag of that paragraph.
Example implementation
A pen showing all this in action is at https://codepen.io/anon/pen/ZMJMZZ
The HTML page contains all content in one long element. The content is taken directly from the container #page and reformed into pages, depending on the size of #page. I have't implemented justifying the last line if a page break occurs within a paragraph. Resize the #page element in the css and see how the content resizes itself - note that since the page size is fixed you'll have to use click forward and back to trigger a recalculation. Once you bind the page size to the window size, recalculating pages on the fly simply involves adding a resize event listener to the window that calls fillPage.
No doubt there are numerous bugs, indeed it will sometimes display things incorrectly (eg skipping or repeating words at the beginning or end of a page), but this should give you an idea of where to start.
Take a look at this repository on GitHub. Otherwise, you can create a one-page website with many sections, each one as high as the viewport, by using only CSS (demo):
.section { height: 100vh; }
or by using JavaScript, adding an anchor to each section to navigate between them, and applying a responsive unit (my demo) for the text of each section, to adapt it on resize... Something like this:
var curr_el_index = 0;
var els_length = $(".container").length;
$(".next_section").on("click", function(e) {
curr_el_index++;
if (curr_el_index >= els_length) {
curr_el_index = 0;
}
$("html, body").animate({
scrollTop: $(".container").eq(curr_el_index).offset().top
}, 300);
return false;
});
$(".previous_section").on("click", function(e) {
curr_el_index--;
if (curr_el_index < 0) {
curr_el_index = els_length - 1;
}
$("html, body").animate({
scrollTop: $(".container").eq(curr_el_index).offset().top
}, 300);
return false;
});
* {
border: 0;
margin: 0;
padding: 0;
box-sizing: border-box;
-moz-box-sizing: border-box;
-webkit-box-sizing: border-box;
}
body {
background-color: #1a1a1a;
}
section {
height: 100vh;
background-color: #eee;
border: 2px solid red;
font-size: 6vw;
}
<script src="https://ajax.googleapis.com/ajax/libs/jquery/2.1.1/jquery.min.js"></script>
<section class="container">Section 1 Previous Next</section>
<section class="container">Section 2 Previous Next</section>
<section class="container">Section 3 Previous Next</section>
<section class="container">Section 4 Previous Next</section>
<section class="container">Section 5 Previous Next</section>
EDIT #1
An idea of algorithm, that come from a my codepen, that uses the same jQuery plugin:
Create your reader layout, copying the whole text in it
Use this jQuery plugin to check the text inside the viewport (demo)
Count the number of characters/WORDS with "Onscreen" label in the
viewport (a references)
Split the whole text in a list containing as many characters/WORDS as
there are in the "Onscreen" label
Create a section for each element of the obtained list, filling each
section with the relative text; the number of elements of the list
gives you the number of pages (sections) of the whole text. You may
navigate between sections like above
On resize event, redo [2-5] algorithm steps
Cheers
The idea is to have a div that will contain the whole text (let's call this div #epub_container). Then, you will have a div with the same size of the page viewport (let's call it #displayer) and it will contain #epub_container.
#displayer will have css overflow:hidden. So when the site loads, it will only show the first page, because the rest of the #epub_container will be hidden.
Then you need a page navigator to increment/decrement the page number. When the page number changes, we will move the top offset of the #epub_container based on that.
This is the jQuery function:
function move_to_page() {
var height = window.innerHeight;
var width = window.innerWidth;
var $displayer = $('#displayer');
var offset = $displayer.offset();
$displayer.height(height - offset.top - 5);
var $epub = $('#epub_container');
var offset_top = offset.top - $displayer.height() * m_page;
$epub.offset({top: offset_top, left: offset.left});
}
JSFiddle
EDIT: call move_to_page() after the text reflow in order to recompute the pages.
I created a plugin that handles this perfectly. It has features like dark mode, font changing, line height adjustment, select chapter in a side nav menu, save and restore scrolling/reading position. You can find it for free on git hub at https://github.com/E-TechDev/Html-Book-Reader
Screenshots
Light Mode Dark Mode Side Nav Menu Change Font Adjust Paragraph
You can try CSS scroll snap points on text with columns
https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Scroll_Snap_Points
Somehow make the columns as wide as the viewport, and allow horizontal snapped scrolling.
Update
I mean to try to do the text flowing entirely using css. Pen:
https://codepen.io/ericc3141/pen/RYZEpr
body {
scroll-snap-type: mandatory;
scroll-snap-points-x: repeat(100%);
}
#columns-test {
height: 80vh;
columns: 90vw auto;
}
All you need is to insert a page break at the right places when you load the page. You can take the cue from here:
Dynamic Page-Break - Jquery
Here you can set the page height to your viewport height. You can handle the rest with javascript and css.

IE, and iframe.elementFromPoint not passing event

Update: Fiddle Demonstration -- http://jsfiddle.net/7tfbtso6/2/ -- Most of the settings work in chrome and firefox, but the only one that works in IE is Left-align: 105px. I do have overflow set to hidden on html and body, but this makes no difference. IE will not work if the element is not visible on screen. And overflow: visible on html and body give the effect of auto and no effect on the problem here.
My site uses two contentEditable divs.
#rInput is part of the document.
#rSyntax is part of an iframe under (z-index) #rInput.
In every browser I've tried so far, except IE (I'll get to that in a moment.), I'm able to determine what element is contained within the iframe using elementFromPoint().
In IE's case, this is only possible if they're not overlapping which isn't possible because a secondary purpose, as the name implies, is to provide syntax-highlighting.
The IE IFrame has to be visible, on screen, not obstructed by any objects. I've tried display: none;, visibility: hidden, and pushing it down in a div with overflow: hidden, but all of these attempts cause it not to work. I've also tried setting the height and width to small proportions.
If any of these could work, I could use two copies of rSyntax, one on top (z-index), hidden somehow, for mouse events and one for syntax highlighting.
Most of these solutions work in every browser but IE. The IE box simply demands that it be on top.
"Flickering" it with css (display, visibility, pointer-events) seems awfully hacky (and just plain awful). I haven't really tried to implement it because it seems like a last resort.
The problem is further complicated because I'm trying to capture clicks and mouseovers, for different purposes (clicks for finding content, mouseovers for tooltips--created with a div mimicking attr("title").
I've briefly tried placing the iframe on top (z-index) of the div, but there's no way to intercept the clicks and pass to the lower object because it runs in to the same problem.
Here's the script I'm using to get the objects, partly in case it's useful to anyone.
$(document).on("mousemove", "#rInput", function (e) {
$element = $(document.getElementById('frSyntax').contentDocument.elementFromPoint(e.pageX+$("#rInputContainer").scrollLeft()-10,e.pageY+$("#rInputContainer").scrollTop()-12));
if ($element.is("span") && $element.attr("title") && $element.attr("title").length) {
$("#syntip").text($element.attr("title"));
$("#syntip").css({"top": e.pageY+10, "left": e.pageX, "display": "inline-block"});
} else {
$("#syntip").hide();
}
});
I have considered transparency, and that works for this element, because it's small, but I use a similar setup with a large element that takes up more than 50% of the screen, there would be problems.
After many frustrating efforts, I concluded that pushing the top (z-index-wise) element offscreen was the only solution for IE/Edge. Flickering it with display: none causes some properties I needed, like width, to not be accurate.
Just make sure you push it farther than the element will ever be. My application is sidescrolling so I merely needed to place the css top to something like 2000.

Preparing the DOM for a Single Page Application

What I am trying to achieve appears to be simple. I am assuming that all content visible on a page, is a child or grandchild of the tag of a HTML page? This text for example must be related to Body.
And this is a tree structure basically starting (visually) with Body.
I want to make a Single Page Application with JavaScript. But I need to prepare the DOM and here is where I struggle.
How do I set up the body of the page so that:
There is no scroll bars
The Body is always filling the entire content area of the browser (if it does not already)
Break out of CSS box model (appendChild 10 times stacks those elements, not flows them)
Any children Divs from Body, also by default break out of the CSS box model too.
I have searched for each step individually but I do not use JQuery, and to be honest, I would prefer to get rid of CSS too all but for the most basic of tasks. I would just like to have a known viewable region and be responsible for its positioning, sizing and content with JS.
Or. If you are similar with Flash. I want to treat the Body as my Stage and use it like a Display List with NO_SCALE enabled. Meaning that when you resize, that should "invalidate" the layout (that is upto me as the developer).
I am not the first person in the world to ask for this. So if you could even point me in the right direction, I would appreciate it.
Try CSS based solution to the fullest, then move on with Javascript. Following would give you pretty much what you want
There is no scroll bars
The Body is always filling the entire content area of the browser (if it does not already)
html, body {
margin : 0px
padding : 0px;
border : 0px;
overflow : hidden;
position : absolute;
left : 0px;
top : 0px;
}
Break out of CSS box model (appendChild 10 times stacks those elements, not flows them)
Any children Divs from Body, also by default break out of the CSS box model too.
put this first
* {
position : absolute;
}

How to ensure CSS :hover is applied to dynamically added element

I have a script that adds full images dynamically over thumbnails when you hover over them. I've also given the full images a CSS :hover style to make them expand to a larger width (where normally they are constrained to the dimensions of the thumbnail). This works fine if the image loads quickly or is cached, but if the full image takes a long time to load and you don't move the mouse while it's loading, then once it does appear it will usually stay at the thumbnail width (the non-:hover style) until you move the mouse again. I get this behavior in all browsers that I've tried it in. I'm wondering if this is a bug, and if there's a way to fix or work around it.
It may be worth noting that I've also tried to do the same thing in Javascript with .on('mouseenter'), and encountered the same problem.
Due to the nature of the issue, it can be hard to reproduce, especially if you have a fast connection. I chose a largish photo from Wikipedia to demonstrate, but to make it work you might have to change it to something especially large or from a slow domain. Also note that you may have to clear the cache for successive retries.
If you still can't reproduce, you can add an artificial delay to the fullimage.load before the call to anchor.show().
HTML:
<img id="image" src="http://upload.wikimedia.org/wikipedia/commons/thumb/3/32/Cairo_International_Stadium.jpg/220px-Cairo_International_Stadium.jpg" />
CSS:
.kiyuras-image {
position: absolute;
top: 8px;
left: 8px;
max-width: 220px;
}
.kiyuras-image:hover {
max-width: 400px;
}
JS:
$(function () {
var fullimageurl = 'http://upload.wikimedia.org/wikipedia/commons/3/32/Cairo_International_Stadium.jpg';
var fullimage = $('<img/>')
.addClass('kiyuras-image')
.load(function () {
anchor.show();
});
var anchor = $('<a/>').hide().append(fullimage);
$('body').prepend(anchor);
$("#image").on('mouseenter', function () {
fullimage.attr('src',fullimageurl);
$(this).off('mouseenter');
});
});
JS Bin
Updated JS Bin with 1.5-second delay added (Hopefully makes issue clearer)
Again: Reproducing the issue involves clearing your cache of the large image, and then hovering over the original image to initial the loading of large image, then not moving your mouse while it's loading. Intended behavior is for the large image to properly take on the :hover pseudo-class when it eventually loads. Issue I see when it takes longer than ~0.75 secs to load is that it does not take on :hover until you jiggle the mouse a little.
Edit: See my comments on #LucaFagioli's answer for further details of my use case.
Edit, the sequel: I thought I already did this, but I just tried to reproduce the issue in Firefox and I couldn't. Perhaps this is a Chrome bug?
Most browsers update their hover states only when the cursor moves over an element by at least one pixel. When the cursor enters the thumbnail's img it gets hover applied and runs your mouseenter handler. If you keep your cursor still until the full-sized image loads, your old img (the thumbnail) will keep the hover state and the new one won't get it.
To get it working in these browsers, move the hover pseudo-class to a common parent element in the CSS; for example, enclose both imgs in a span.
If the selectors are correct, CSS will be applied to all elements, dynamic or otherwise. This includes all pseudo classes, and will change as attributes in the DOM change.
[Edit: while my explanation might be of interest, pozs' solution above is nicer, so I suggest using that if you can.]
The hover pseudo-class specification is quite relaxed concerning when it should be activated:
CSS does not define which elements may be in the above states,
or how the states are entered and left. Scripting may change
whether elements react to user events or not, and different
devices and UAs may have different ways of pointing to, or
activating elements.
In particular, it is not being activated when you update the visibility of the anchor element on load.
You can get around this fairly easily: copy the hover styles to a class, intercept the cursor moving over the element that it will eventually cover, and based on that add or remove your class from the element.
Demo: JS Bin (based on your delayed example).
Javascript:
$("#image")
.on('mouseenter', function () {
fullimage.attr('src',fullimageurl).toggleClass('mouseover', true);
$(this).off('mouseenter');
})
.mouseleave(function() {
fullimage.toggleClass('mouseover', false);
});
CSS:
.kiyuras-image:hover, .kiyuras-image.mouseover {
max-width: 400px;
}
TL;DR: You cannot rely on :hover applying to dynamically added elements underneath the cursor. However, there are workarounds available in both pure CSS and Javascript.
I'm upvoting both Jordan Gray and posz' answers, and I wish I could award them both the bounty. Jordan Gray addressed the issue re: the CSS specification in a somewhat conclusive way and offered (another) working fix that still allowed for :hover and other CSS effects like transitions, except on load. posz provided a solution that works even better and avoids Javascript for any of the hover events; I provide essentially the same solution here, but with a div instead of a span. I decided to award it to him, but I think Jordan's input was essential. I'm adding and accepting my own answer because I felt the need to elaborate more on all of this myself. (Edit: Changed, I accepted posz')
Jordan referenced the CSS2 spec; I will refer instead to CSS3. As far as I can tell, they don't differ on this point.
The pseudo-class in question is :hover, which refers to elements that the user has "designated with a pointing device." The exact definition of the behavior is deliberately left vague to allow for different kinds of interaction and media, which unfortunately means that the spec does not address questions like: "Should a new element that appears under the pointing device have this pseudo-class applied?" This is a hard question to answer. Which answer will align with user intent in a majority of cases? A dynamic change to a page the user is interacting with would normally be a result of ongoing user interaction or preparation for the same. Therefore, I would say yes, and most current browsers seem to agree. Normally, when you add an element under the cursor, :hover is immediately applied. You can see this here: The jsbin I originally posted. Note that if there's a delay in loading the larger image, you may have to refresh the page to get it to work, for reasons I'll go into.
Now, there's a similar case where the user activates the browser itself with the cursor held stationary over an element with a :hover rule; should it apply in that case? The mouse "hover" in this case was not a result of direct user interaction. But the pointing device is designating it, right? Besides, any movement of the mouse will certainly result in an unambiguous interaction. This is a harder question to answer, and browsers answer it in different ways. When you're activating them, Chrome and Firefox do not change :hover state until you move the mouse (Even if you activated them with a click!). Internet Explorer, on the other hand, updates :hover state as soon as it's activated. In fact, it updates it even when it's not active, as long as it's the first visible window under the mouse. You can see this yourself using the jsbin linked above.
Let's return to the first case, though, because that's where my current issue arises. In my case, the user hasn't moved the mouse for a significant length of time (over a second), and an element is added directly underneath the cursor. This could more easily be argued to be a case where user interaction is ambiguous, and where the pseudo-class should not be toggled. Personally, I think that it should still be applied. However, most browsers do not seem to agree with me. When you hover over the image for the first time and then do not move your mouse in this jsbin (Which is the one I posted in my question to demonstrate the issue, and, like the first one, has a straightforward :hover selector), the :hover class is not applied in current Chrome, Opera, and IE. (Safari also doesn't apply it, but interestingly, it does if you go on to press a key on the keyboard.) In Firefox, however, the :hover class is applied immediately. Since Chrome and Firefox were the only two I initially tested with, I thought this was a bug in Chrome. However, the spec is more or less completely silent on this point. Most implementations say nay; Firefox and I say aye.
Here are the relevant sections of the spec:
The :hover pseudo-class applies while the user designates an element with a pointing device, but does not necessarily activate it. For example, a visual user agent could apply this pseudo-class when the cursor (mouse pointer) hovers over a box generated by the element. User agents not that do not support interactive media do not have to support this pseudo-class. Some conforming user agents that support interactive media may not be able to support this pseudo-class (e.g., a pen device that does not detect hovering).
[...]
Selectors doesn't define if the parent of an element that is ‘:active’ or ‘:hover’ is also in that state.
[...]
Note: If the ‘:hover’ state applies to an element because its child is designated by a pointing device, then it's possible for ‘:hover’ to apply to an element that is not underneath the pointing device.
So! On to the workarounds! As several have zealously pointed out in this thread, Javascript and jQuery provide solutions for this as well, relying on the 'mouseover' and 'mouseenter' DOM events. I explored quite a few of those solutions myself, both before and after asking this question. However, these have their own issues, they have slightly different behavior, and they usually involve simply toggling a CSS class anyway. Besides, why use Javascript if it's not necessary?
I was interested in finding a solution that used :hover and nothing else, and this is it (jsbin). Instead of putting the :hover on the element being added, we instead put it on an existing element that contains that new element, and that takes up the same physical space; in this case, a div containing both the thumbnail and the new larger image (which, when not hovered, will be the same size as the div and thumbnail). This would seem to be fairly specific to my use case, but it could probably be accomplished in general using a positioned div with the same size as the new element.
Adding: After I finished composing this answer, pozs provided basically the same solution as above!
A compromise between this and one of the full-Javascript solutions is to have a one-time-use class that will effectively rely on Javascript/DOM hover events while adding the new element, and then remove all that and rely on :hover going forward. This is the solution Jordan Gray offered (Jsbin)
Both of these work in all the browsers I tried: Chrome, Firefox, Opera, Safari, and Internet Explorer.
From this part of your question: "This works fine if the image loads quickly or is cached, but if the full image takes a long time to load and you don't move the mouse while it's loading,"
Could it be worth while to "preload" all of the images first with JavaScript. This may allow all of the images to load successfully first, and it may be a little more user friendly for people with slower connections.
You could do something like that : http://jsfiddle.net/jR5Ba/5/
In summary, append a loading layout in front of your image, then append a div containing your large image with a .load() callback to remove your loading layer.
The fiddle above has not been simplified and cleaned up due to lack of time, but I can continue to work on it tomorrow if needed.
$imageContainer = $("#image-container");
$image = $('#image');
$imageContainer.on({
mouseenter: function (event) {
//Add a loading class
$imageContainer.addClass('loading');
$image.css('opacity',0.5);
//Insert div (for styling) containing large image
$(this).append('<div><img class="hidden large-image-container" id="'+this.id+'-large" src="'+fullimageurl+'" /></div>');
//Append large image load callback
$('#'+this.id+'-large').load(function() {
$imageContainer.removeClass('loading');
$image.css('opacity',1);
$(this).slideDown('slow');
//alert ("The image has loaded!");
});
},
mouseleave: function (event) {
//Remove loading class
$imageContainer.removeClass('loading');
//Remove div with large image
$('#'+this.id+'-large').remove();
$image.css('opacity',1);
}
});
EDIT
Here is a new version of the fiddle including the right size loading layer with an animation when the large picture is displayed : http://jsfiddle.net/jR5Ba/6/
Hope it will help
Don't let the IMG tag get added to the DOM until it has an image to download. That way the Load event won't fire until the image has been loaded. Here is the amended JS:
$(function () {
var fullimageurl = 'http://upload.wikimedia.org/wikipedia/commons/3/32/Cairo_International_Stadium.jpg';
var fullimage = $('<img/>')
.addClass('kiyuras-image')
.load(function () {
anchor.show(); // Only happens after IMG src has loaded
});
var anchor = $('<a/>').hide();
$('body').prepend(anchor);
$("#image").on('mouseenter', function () {
fullimage.attr('src',fullimageurl); // IMG has source
$(this).off('mouseenter');
anchor.append(fullimage); // Append IMG to DOM now.
});
});
I did that and it worked on Chrome (version 22.0.1229.94 m):
I changed the css as that:
.kiyuras-image{
position: absolute;
top: 8px;
left: 8px;
max-width: 400px;
}
.not-hovered{
max-width: 220px;
}
and the script this way:
$(function(){
var fullimageurl = 'http://upload.wikimedia.org/wikipedia/commons/3/32/Cairo_International_Stadium.jpg';
var fullimage = $('<img/>')
.addClass('kiyuras-image')
.load(function () {
anchor.show();
});
var anchor = $('<a/>').hide().append(fullimage);
$('body').prepend(anchor);
$('.kiyuras-image').on('mouseout',function(){
$(this).addClass('not-hovered');
});
$('.kiyuras-image').on('mouseover',function(){
$(this).removeClass('not-hovered');
});
$("#image").one('mouseover', function(){
fullimage.attr('src',fullimageurl);
});
});
Basically I think it's a Chrome bug in detecting/rendering the 'hover' status; in fact when I tried to simply change the css as:
.kiyuras-image{
position: absolute;
top: 8px;
left: 8px;
max-width: 400px;
}
.kiyuras-image:not(:hover) {
position: absolute;
top: 8px;
left: 8px;
max-width: 220px;
}
it still didn't worked.
PS: sorry for my english.
I'm not 100% sure why the :hover declaration is only triggered on slight mouse move. A possible reason could be that technically you may not really hover the element. Basically you're shoving the element under the cursor while it is loading (until the large image is completely loaded the A element has display: none and can therefore impossible be in the :hover state). At the same time, that doesn't explain the difference with smaller images though...
So, a workaround is to just use JavaScript and leave the :hover statement out of the equation. Just show the user the two different IMG elements depending on the hover state (toggles in JavaScript). As an extra advantage, the image doesn't have to be scaled up and down dynamically by the browser (visual glitch in Chrome).
See http://jsbin.com/ifitep/34/
UPDATE: By using JavaScript to add an .active class on the large image, it's entirely possible to keep using native CSS animations. See http://jsbin.com/ifitep/48

Set an element height via CSS or JavaScript/JQuery

This should be simple but nothing's working:
Question
How do you set the height of a webpage to be, lets say, exactly 4000 pixels—in such a way that scroll bars exist even when the page is blank?
Background
I'm new to JavaScript/JQuery but very experienced with similar technologies. I'm trying to do some fancy effects based on scrolling the page. To accomplish this methodically, as a first step I'm looking to make a "really tall" page. From there I will hide/display items based on the scroll height with pseudo-code along the lines of:
function onScrollEvent() {
var height = scroll height
var sectionIndex = Math.floor(height / MAX_SECTION_HEIGHT);
for each item in my array of graphics
if item index != sectionIndex then item.fadeOut else item.fadeIn
}
Once I have that working, I'll start creating the effects I want to see. The problem is, I can't make the stupid page "really tall."
Summary
When I set the height style property of the main-content div, it doesn't seem to trigger scroll bars unless there's actual content on the page. How do I make the page "permanently tall," so to speak? That is, I want the page to behave (scroll) as though it has 4000 pixels of content even if there's only one line of text on the page. Right now it behaves as though there's a call to:
height = Math.min(height of contents, height of div style)
Have you tried min-height for body, or html tags? min-height requires the element to be at least that height regardless of the content contained.
CSS
html, body{
min-height: 4000px;
}
Live Demo
Reference
Easy in CSS:
body
{
height: 4000px;
}
Example here.
This is the simplest way. min-height is not supported by all browsers. This is a specific height that you can set to the body tag (essentially the webpage itself) to make it really tall.
In your CSS add:
body
{
min-height: 4000px;
}
And you'll also need:
body
{
height: 4000px;
}
for internet explorer (via IE's conditional comments).
In Chrome 10, on OSX 10.6 -- this renders a complete blank page with scroll on the Y axis, hope this is how you meant:
http://pastie.org/1674432

Categories

Resources