I use the following CSS styles to debug where my div and span outlines are (normally keep it commented):
div { outline: 1px dashed blue } span { outline: 1px dashed green }
While that shows the outer bounds of divs and spans and gives an idea of padding relative to the object/text inside, it does not help visualize where the margins assigned to the same style are. I understand the difference between padding and margins but I really need to be able to see the visual effect when building a page (too much detail, too little attention span).
Is there any way to add an outer rectangle to show where the margins are for a style?
I am not aware of any attribute that allows a border on the outside of margin as that goes against the purpose of what a margin is. W3's Box Model Explanation
While this was a great technique in early web development, I cannot recommend strongly enough taking a few minutes to install Firebug or to familiarize yourself with Chrome's Developer tools, or Safari's "Inspect" features, etc. You can just mouse over code and get far more data than hours of messing around with hand-made debug styling.
You'll love them!
Firebug especially allows mousing over code and it will highlight your main box, color coded padding and margin, etc. An invaluable tool - it's even better than Dreamweaver's built in visual outline tools.
You can use my new tool for this. You mouse over any element in your page and it will show you all parts of its layout (margin, border, padding, etc.).
HTML Box Visualizer - GitHub
As far as I know, there isn't. I would recommend either using Chrome's Dev tools or Firebug as previously mentioned. A nice perk you get with those tools, is the ability to manipulate the DOM on the fly. This makes testing out placement very quick and painless. Sometimes if I'm trying to place a div juuust right, I'll right-click the div, select inspect this element, and then look at the properties on the right-hand side. You can actually adjust these real-time and see the changes reflected in the page. A nice trick is that many of the properties allow you to use the up and down arrow keys to cycle through their values. This makes adjusting the margin-left or a margin-right value a cinch.
Related
I'd like to make a textarea float to the right, but that would show the resize:both; style that's default to textareas on the right side, while the resizing itself would expand the textarea to the left.
The HTML I'm using is simply:
<textarea style="float:right;"></textarea>
but it is much clearer to see what I mean by viewing this demo. As you can see, resizing the textarea will require you to drag to the right, while it will expand to the left. Is there a way for me to reposition the little indicator in the corner of the textarea to the left side?
As far as I know, that is not a feature that is exposed by the browsers at this time. It's a relatively new feature to HTML, as it is, and I don't think there are any semantic or programmatic hooks to that UI piece of textareas yet.
Your best bet, at this point then will be to fake it with drag-and-drop JS and pseudo-controls, and hide the native resize.
Actually, I stand (somewhat) corrected. According to a comment in this article (http://davidwalsh.name/textarea-resize), you can play around with the resize widget, but only in Safari at the time of that comment:
Greg March 11, 2013
In webkit you can play around with the scrollbar styling.
I used >
::-webkit-resizer{background-color:transparent;}
::-webkit-scrollbar-corner{background-color:rgba(0,0,0,0.2);}
to style the resizer on the textareas in one of my sites.
(Easier to read in the comments section there.)
I am designing a site for a new foundation, and I have set April 15 as my deadline for finishing it. It is ready except for editing the content and fine-tuning the design. In the fine-tuning, I am wrestling with an irksome little problem that I would like to ask someone to please help me solve. The problem is simply this: a division in the site's structure will not function as I would like for it to function unless it has a border around it. Never seen a thing so erratic before.
The problem appears to be related to how the elements interact in the layout. First, there is the html tag which holds the background image, a jpeg of a creek with some buildings on the far side and a green grove of grass created by a divisional tag (#greengrass) positioned at the bottom of the background image . div#greengrass is styled to extend downward as a content div, resting on top of it, lengthens. It is this #greengrass element that performs awkwardly unless there is a border laced around it.
Specifically, if its border is removed, it projects upward and covers the background image, even though positioned to start where the background image ends. Its upward projection, therefore, makes the entire page background green. But when it has a border, the background image of the creek shines through as bright as the sunny spring sun.
Thus, I have one question: Why does the absence or presence of the division's border affect its behavior? Here is the url to the test site for the foundation: http://postmaterial.org/tests/signin-ap.php. At top center, I've added a link that lets you toggle between the bordered and borderless div#greengrass effects. I have no clue as to the reason for the tag's behavior and would appreciate an explanation. Thanks.
To answer your question: "Why does the absence or presence of the division's border affect its behavior?" I agree with ichao (as his answer stated) that collapsing margins is the issue.
However, I think the solution is to keep only a border-top: 1px solid #009900 as it is only the top border that is needed to prevent the margin collapse. This will prevent the horizontal scroll bar from showing up.
without the border of #greengrass, the negative margin-top of its child collapses through (and pulls the entire construct out of sight, topwards), and in consequence, #greengrass is not pushed down enough by top anymore.
border prevents collapsing margins, as display:inline-block or display:table or float:left would in this case (overflow:hidden is not an option here). In old IE, any haslayout trigger like zoom:1 should do. I did not test it, though.
Ok I have a really weird CSS issue that I was wondering could anyone suggest an explanation for.
Steps to reproduce:
Open Chrome and navigate to http://www.mcwhinneys.com/media
The gallery of photos should be out of alignment, off to the right by about 50-70px
Open the Developer console in chrome
Expected Result:
i do this to inspect the css expecting to see why the images are off to the side, fixing the css and moving on.
Actual Results:
The gallery of images pops into alignment when the developer tools open.
Anyone know why this might happen? It seems as if the css is fine when I inspect it but it definitely doesn't render correctly until the console has been opened.
Well, the actual cause for the wrong layout is the combination of text-align: center on your ngg-gallery-thumbnail-box (I'll call that box from now on) with position: absolute + display: inline-block on the inner ngg-gallery-thumbnail (I'll call that thumb).
It goes like this:
We apply text-align: center to box. This will cause it to center its inline children. It does this (conceptually) by placing each child's left edge at the current "text cursor" position (which, importantly, starts out at box's center), then moving it towards the left to "recenter" it. This is - also importantly - box's "job".
We declare the thumb as inline-block. This will (among other things) cause it to follow text-align of its parent, meaning that - at this point in time - it's centered.
We then declare thumb position: absolute. This will take it out of the flow, positioning its left edge at the same point where it originally would be - because we're not specifying left/right.
The "naive" interpretation of this would be that it's still at the center of box, and everything would be fine, but we get a "side effect"...
Because we took thumb out of the flow, box no longer has any inline content, meaning its text cursor is at the center, and it doesn't need to center anything. Its "job" is done.
But since thumb is inline-block, it's original position is still based on box's text cursor position (the center), meaning that when we make it position: absolute, its left edge will be placed at that center. It's not horizontally centered inside box, because from box's point of view, there are no children in its flow that need centering.
This is halfways to a chicken and egg problem, so Chrome seems to get confused when it does a re-render of the page for the console.
This explanation may also be a bit confused, but you can see the result here - and even in this simple example, Chrome's console will do a reflow when you try to inspect it. In this example it even seems to enough to resize the window without opening the console (v17.0.963.56):
http://jsfiddle.net/h66Gj/
As far as I'm aware, the way it renders it first, is the way it's "meant to be" (last I checked, the W3C recommendations were vague about it, but at least Firefox agrees with the pre-inspect render).
There are many ways to get around it, my favorite being to only use text-align: center to center... text, and try to use e.g. margin: auto to center other content.
It's really hard to tell, but it looks like it might be something to do with the interaction between the styling of the elements with class ngg-gallery-thumbnail. I would try tweaking/simplifying that. Do you need the display:inline-block setting there, for example?
I have a Chrome extension with a browser action that is trying to imitate the visual style of a different app. Part of this style is a header and footer that extend to the edges of the app. The problem is that the browser action popup contains a small margin and rounded border by default that appears to be hard coded to display as white space.
It would be nice if there was some way to either remove this margin or force my content to be able to extend all the way to the edges. Does anyone know of a way to do this? (I highly suspect that there's nothing to be done, but it never hurts to ask, right?)
Oh, and for the record, negative margins get you nowhere in this case. :(
From my experience in developing the extensions as well as using them. There isn't a way to get rid of that small border.
The best experience I've seen is matching the rounded corners with a border-radius: 5px
You can't remove the 1px white margin but you can remove the 8px margin you have to add body{margin:0px !important;} to your css then you can add a border-radius as suggested by Ryan
My page, it keeps on getting different menu width when i zoom in and out. It is fine in IE, and no one else. I did not spot any fixed positioning, this seems to be using relative position.
have tried playing and disabling all CSS property to my menu bar through google chrome inspect element.
turn this from none to auto: " -webkit-text-size-adjust: auto "
Tried to use em ex px for my font-szie and padding. I am juiced out of ideas, save me internet!!!
www.magentek.com
Try zooming out, you will find press room gets pushed down. I got this SimplyBiz theme from wpcrunchy. It seems even the paid version have this problem too. The CSS and html is way too large to post, too much bloated codes, i think is sufficient to just use chrome inspect element.
I took a look at the site, and my opinion is that the css and js that make up the menu functionality are creating a 6th menu element. That would explain why an extra little tab is hanging off the end there. Since it doesn't have any content, the browsers are all handling the whitespace a little differently.
Did you by any chance modify the menu to take it from 6 elements to 5?