Suppose you have iframe elements in your page and you try to inspect its content. When you select a particular element within iframe content document, IE developer tools draws blue border around it, but with every nested iframe it adds additional 2 pixels offset.
You can see an example of this in this image below where I've manually added background to html and body elements making them visible in JSFiddle. I then selected body element within the iframe and as you can see indicator is offset by 2 pixels right and down.
If there was an additional iframe within this one, additional 2 pixels would be added getting to 4 pixels etc.
Is it possible to avoid this selected element indicator offset in Internet Explorer Developer Tools?
Note: Every time I have to use Internet Explorer a bit of me dies inside. If I have to use it along with developer tools a larger chunk of my life goes bananas.
Related
Is there a way so I can see my entire page while having the inspect/dev tools open in google chrome, as it is it is only displaying the far left two inches of the page which isnt particularly helpful when trying to view aspects on the other side?
I am trying to see the entire chart. I have tried to enlarge/shrink screen size and increase % and adjust to fit but it still only manipulates the two inch strip visible here instead of the entire chart.
I saw a viz in the company's repository, and I wish to replicate one of the feature.
The viz is consist of several pages with an introductory page. The introductory page contained a lot of information with a scrollable canvas, while other detail page had a fixed-to-window way of presenting data, showing each segment in one screen without the overall scroll bar.
What I want to know is how to only make one or part of the pages in the dxp file able to enable the scroll bar (larger canvas height), while the rest having the fit-to screen way of displaying the viz. Any approach will be appreciated.
PS:
The Document Property→General→Visualization area size→Custom size method changes the canvas size of all visualization table. Which is not able to fulfill this feature, as this property changes the canvas size of all pages in the dxp file, which is not what I expected.
sounds like they used a Text Area but it's hard to tell without seeing the document.
you can insert a Text Area the same way you do a visualization (via the toolbar or the main menu). you can then right click the Text Area to edit it either with the WYSIWYG editor or in raw HTML. Text Areas will show scrollbars to match the length of your content.
I am using FullPage JS to display a few sections. On the desktop, it works perfectly.
However, Some sections have quite an amount of content. On smartphones, part of the content of these sections is covered. Put another way, I am only able to see part of the content of these sections when I scroll (I already used media queries to reduce content display on smartphones, but these sections do have more content than what a full screen can display on smartphones).
I need the usual FullPage JS to work for me on the desktop. However, can I disable full screen display on smartphones and simply display a list of sections as a long page on smartphones? Did anyone do this before?
fullpage.js provides options for it such as responsiveWidth and responsiveHeight that will turn off auto scrolling under a given value in px.
Combine those with the class fp-auto-height-responsive and you'll get what you want.
All of this is detailed in the docs.
Responsive auto height sections
A responsive auto height can be applied by using the class fp-auto-height-responsive. This way sections will be full height until the responsive mode gets fired.
responsiveWidth: (default 0) A normal scroll (autoScrolling:false) will be used under the defined width in pixels. A class fp-responsive is added to the body tag in case the user wants to use it for his own responsive CSS. For example, if set to 900, whenever the browser's width is less than 900 the plugin will scroll like a normal site.
responsiveHeight: (default 0) A normal scroll (autoScrolling:false) will be used under the defined height in pixels. A class fp-responsive is added to the body tag in case the user wants to use it for his own responsive CSS. For example, if set to 900, whenever the browser's height is less than 900 the plugin will scroll like a normal site.
Background
I have a standard three column layout where the first column is floated left, and the third column is floated right. The first column needs a full-height background.
This layout is for a template, so any of the three columns could have the longest content.
I can't change markup source order, so display:table solutions are not possible.
I can't add any DOM nodes.
The layout is centered with a minimum and maximum width, so I can't attach a vertically-repeating background image to the page with the built-in background color.
It needs to look OK in IE7, but IE8+ needs support.
Solution
To achieve the full-height left column, I created a pseudo-element on colLeft. That pseudo-element has fixed-positioning set to the viewport bottom, 100% height, and placed behind the left column. This solution is awesome because:
IE8+ supports pseudo-elements.
The pseudo-element is attached to the left column, so if the template doesn't have a left column, the background naturally isn't there.
By not setting a left or right attribute, the fixed-positioned pseudo-element stays with the left column (good for the centered layout).
Here's an example on CodePen.
(Make sure that the Document Mode is following the Browser Mode when viewing CodePens in IE).
Problem
In IE8 the full-height left column background only extends down to the initial viewport bottom (the fold).
I created another test with a new leftColBg node instead of the pseudo-element. This works as expected in IE8, meaning that the fixed positioning should work.
Here is the best explanation that I can find on IE8 and generated content: Why does a filter gradient on a pseudo element not work in IE8?
I think IE8 is incorrectly positioning the generated content, because it's not an "object" that contains content. Can anybody better explain this IE8 bug? Is there a fix?
For some reason a basic unstyled DIV element has extra height tacked onto the bottom when it contains a VIDEO element (and possibly other elements - I haven't tested with many types).
<div><video src="my_movie.ogv"></video></div>
I have the above line of code in a barebones base HTML file. With Firefox or Safari/Chrome's (if I use an .mp4 file instead of course) DOM inspectors on I see that the computed height of the DIV element is anywhere from 2-5 pixels more than the height of the VIDEO element.
This doesn't seem like expected and intentional behavior. If I put a P element in there instead of a VIDEO element, for example, the DIV doesn't have any of the extra height.
Does anyone know why the browsers are rendering this configuration of DOM elements in this way?
If your markup is as above and there are no special styles applied to it, then the behavior you see is required by the CSS box model; the space is the size of the font's descent, because the bottom of the video is placed by default on the baseline, not at the bottom of the text. In particular, see https://bugzilla.mozilla.org/show_bug.cgi?id=22274#c55 for an explanation in spec terms and https://bugzilla.mozilla.org/show_bug.cgi?id=22274#c37 for how to get rid of the space if you want to. You could also set line-height on the block to 0 to get rid of the space; which approach you take should depend on your other design constraints.