Just wondering if when i display a div as hidden does the information gete loaded then hidden or does it get loaded when it is shown? can't remember the ters but it's like display="none" or something.
Thanks
This question is similar to yours. Does display:none keep elements from loading?
The part that relates to your question is this ->
Nope. display: none will only prevent the element from being
displayed; it will be loaded nevertheless.
You can watch this happen in the element inspector of your choice
(e.g. in Firebug or IE8's dev tools).
The best way is probably to create the Video element using JavaScript
afterwards, or - if you want a fail-safe solution in case JS is turned
off - you could use an iframe that loads the video if the user clicks
a link.
Hope that helps!
It still gets loaded into the DOM, but the browser doesn't show it since there is a hint to hide it.
Just use a DOM inspector like IE deveopler tools to inspect it, and you will see it with display:none
There are couple of CSS styles that you can use to hide the information from being displayed.
display: none and visibility: hidden
Both of them will actually load the DOM content but does not display them.visibility: hidden takes the space required for that DOM element accordingly in the layout eventhough it does not display the element. But display: none considers that the element is not present in the DOM and does not occupy any space in DOM corresponding to that element.
Please see this: http://jsfiddle.net/JSWorld/ADSmc/
Related
In a HTML page, an element can be repositioned for lots of reasons - style changes (margin, padding, height, etc) to the element, insertion or removal of other elements, or style changes to other elements.
I need to ensure that a jQuery dialog is always positioned next to an anchor, so if the anchor moves so will the dialog. However, I do not control the page that the dialog is displaying on (I inject some JS dynamically). I thought that I could observe changes to the offsetTop property of the element (and all it's parent elements) with a MutationObserver, but offsetTop changes do not seem to raise mutation events.
Can someone confirm that offsetTop changes will not raise a mutation event, or show me how I can watch the offset top?
Alternatively, if there is some other technique to ensure that a dialog stays with it's anchor, I'm all ears - but please be aware of the constraint that I don't control the page itself, only the dialog :)
FIDDLE:
In the following fiddle, clicking the "Margin" button modifies the margin-top of the anchor element, causing the style attribute to change, this triggering a reposition. However, clicking the other buttons does not cause a reposition, even though the offsetTop attribute has changed. I need the other two buttons to cause the position() function to be called.
http://jsfiddle.net/ustmssx7/2/
CONSTRAINTS
I do not control the HTML or the Javascript - my JS get's injected into someone else's page, so I am very limited in what I can do.
FALLBACK
My fallback solution is to poll the window.anchor.offsetTop every 100ms or so, and reposition if it changes. However, polling sucks, so if I can react to events instead that would be much better.
offsetTop cannot be observed with MutationObserver because only HTML structure changes can be observed. So any HTML data visible in the actual HTML of the page.
For your example, what you actually want is to observe the entire structure of the page, since any number of things can affect the position of the popup, and on any change to the page at all, you'll need to re-position your popup. Keep in mind though that there are still ways to modify the rendering state of the page without modifying the HTML of the page, like CSS animations and hover effects and such. Those would not be solvable with this type of solution.
Trying to do some front end design work and I needed to do some debugging/testing of my css.
I know with most browser dev tools, I can click on an elements and get a full style trace.
But what I want to do is the reverse.
I know the selector and I wish to find all elements that are associated with it (simple ctrl+f not working out)
How would I go about this?
You can surely do this in the normal Javascript console with document.querySelectorAll.
So if you want to find all the elements that match body div.heading h1, do
document.querySelectorAll('body div.heading h1');
The browser console will show the elements it has found. Most also highlight them in the page when you mouseover the listing in the console.
I'm running into something really weird with my HTML/CSS.
When I reload the page sometimes one of my elements ends up positioned where it's supposed to be (centered vertically) and sometimes it ends up out of the viewport (something like 700px above the top of the page).
That the page acts differently on different page loads is only half of the weirdness. If I remove body's height: 100% property and re-add it in the web inspector everything magically fixes itself. (body is this element's direct parent.)
My instinct tells me that the answer to the first part of the weirdness is that there's some race condition going on causing things to happen in a different order randomly. But I'm not sure what that might be or why it's affecting things.
What could cause removing and re-adding an identical CSS attribute from an element to cause the page layout to change?
I can't reproduce in a jsfiddle unfortunately but here's a gif of this in action:
Edit: A new piece of the puzzle. I've discovered that this only happens in Chrome and appears to happen only if the page is loaded with an empty hash on the URL.
http://myurl.com works
http://myurl.com/#foo works
http://myurl.com/# intermittently has issues
There was a workaround to trigger a re-flow posted by #Huangism below but there are some caveats (some complications with timing when exactly to trigger a re-flow and also triggering a re-flow on a working page causes a flash of the content).
I think this is a weird bug with chrome, try this
After the content is shown, using jquery - hide the div that contains that content, check it's height and show it
Assuming $el is your jquery div element
$el.hide().height();
$el.show();
Try it and see if it fixes the issue or not
Try setting the height using js or jquery.
It looks like when you reload the page your CSS attributes are set to your body tag via style="" and then quickly removed. Its likely something in your js
Good grief this is hacky. Would still love an explanation for exactly what's going on and the proper way to deal with it but...
After figuring out that somehow an empty hash being appended to the URL was part of the issue an acceptable workaround seems to be completely removing an empty hash if present by using the html5 history API.
My code looks something like this:
// when the page is ready...
$(function() {
// if the url ends with a "#" (and the browser supports it...)
if(window.location.href && window.location.href.indexOf('#') == window.location.href.length - 1 && window.history) {
// clear the darn empty hash using the html5 history API
window.history.replaceState({}, '', './');
}
});
I've got some specific iframe elements that I want to be able to hide from the JAWS frame list (insert + f9). There are other iframes that are very important so just having a user ignore iframes isn't going to work.
Is it possible to do this?
Edit: I should mention why. There is a user option that changes whether specific types of windows open in a new window or open in an iframe on the page, even if the option is set to open in a new window the iframe is still there but the src is set to a blank html file. In that case I(or if it's set to load in the iframe but it isn't at the moment) the content of the iframe is useless to the user and I'd rather hide it from them. I'd rather not make major changes to the code if I can avoid it.
You should be able to hide it with CSS (visibility: hidden or display: none) or with aria-hidden="true".
I was delighted to discover that Android 2.2 supports the position:fixed CSS selector. I've built a simple proof-of concept, here:
http://kentbrewster.com/android-scroller/scroller.html
... which works like a charm. When I attempt to add an INPUT tag to my header, however, I hit trouble. On focus, every device I've tried so far clones the INPUT tag, gives it an infinite Z-index, and repaints it on top of the old tag. The clone is in roughly the right position, but most of its parent's CSS (including, of course, position:fixed) is ignored. The cloned INPUT tag is the wrong size and shape, and when I scroll the body of the page, it scrolls up and off the screen.
Once it's off screen, hilarity ensues. Sometimes the device will force the scrolling part of the body back down so the cloned blank is back in view; sometimes the keyboard goes away even though the visible box seems to remain in focus; sometimes the keyboard cannot be dismissed even though the INPUT blank is clearly blurred. Here's an example you can run on your Android 2.2 device to see what's happening:
http://kentbrewster.com/android-input-style-bug/
Styling input:focus has not done the trick for me yet, nor have many different brute-force attempts to listen for focus() and blur() with JavaScript and do the right thing with focus and the keyboard.
Thanks very much for your help,
--Kent
This will probably not be resolved until Android switches to using Chrome for its WebView. The current Android browser creates an Android TextView on top of the page when an HTML input field is focussed. Apparently they don't style or position it correctly. You can see it go more wrong on pages that use contentEditable.
The current Chrome-for-Android implements the WebKit IME interface, so input fields are drawn by WebKit (and lose some of the niceties of the Android TextView on ICS) and shouldn't have issues like this.
The solution is to add:
input {
-webkit-user-modify: read-write-plaintext-only;
-webkit-tap-highlight-color: rgba(255,255,255,0);
}
in your css.
You might be able to solve it by using a bug in Android: http://code.google.com/p/android/issues/detail?id=14295.
That is, don't display the input field right away. Instead, display an overlay div which listens on click and hides itself and shows the hidden input, and give the input focus. This somehow prevents Android from using the wierd input that gets placed on top of everything, and is instead using the browsers input field which you can style any way you want.
As you'll note in the bug raport though, this doesn't work with input[type="number"]...