I've looked around but not found a solution to this issue. Using the following CSS
border: double 1px #999;
outline: solid 4px #EAEAEA;
I was able to create a simple double border around a DIV quite easily. In HTML4. Then I switched the Document type to <!DOCTYPE html>, at which point the bottom outline was offset by about 5px. Curiously, only the bottom outline because the other 3 sides of the are still flush with the border.
Am I missing something about border outlines in HTML5? I should stress that it looks perfect in HTML4.
It may be quirks mode box-model issue (if you've used an incomplete Transitional DOCTYPE which doesn't enable "standards mode"). Without proper DOCTYPE you get emulation of IE5 bugs, including an "old" box-model.
The behavior you get with <!DOCTYPE html> is considered correct by the CSS spec.
Ideally you should reduce dimensions of the element by border width to compensate.
Alternatively (if you're using sizes in % for example), switch box-model to the one you expect (works in IE8+):
div {box-sizing: border-box;}
Note that it affects border only. The outline will be outside the box regardless, and it's not going to influence layout. You can reserve room for the outline using equivalent margin.
Related
I have a div, which has it's border property set to:
border: 1px solid #3a87ad;
When I inspect this div in my browser (using Firefox 60.0.1), the computed values for the border are 0.6 px. This wouldn't be an issue alone, but I am using multiple numbers of these divs in a plugin, which places them one below the other, and when it calculates the top position of each div, it uses exact values. After 3-4 divs placed, I can see a tiny white line (the extra white-space from the borders), that starts adding up on the screen.
Unfortunatly, I can't provide a fiddle, as the code is too large, but I am hoping someone else also experienced simmilar issues, and knows a solution.
What I already tried, is refreshing my zoom settings in the browser, but that didn't help either, viewing on 100% zoom, the problem still persists.
Thanks!
I think your code is overridden by some other CSS you use in your Plugin
Check it Carefully
and try border: 1px solid #3a87ad!important;
I hope it works
I've got two inputs, styled primarily by Zurb's Foundation framework. They're in a .row.collapse and each in a .medium-6.columns (these columns are 50% width, floated left, no margins). The inputs themselves are 100% wide within their containers. It's all pretty simple, and the Inspector and jQuery.css are all returning what I'd expect them to. But there's a border issue. Here's the gist of the CSS:
input {
border: 1px solid #dddddd;
&.first {
border-right-width: 0;
}
}
This is to have the effect of collapsing the middle border. But for some reason, this border-right-width: 0 is throwing Webkit (Chrome and Safari but not Firefox) off. The inspector shows 1px border, and the proper border-color. The white input background lines up properly with the second input (that is, there's room for the border), but there's no gray border. Maybe it's rendering transparent?
If I open this up on a retina display, it renders normally - proper borders on both. If I zoom in, the borders show up when it hits the "small" media query (mobile device sizes). But I can't make this border show up on a non-retina, desktop display in Chrome.
Here's how it looks in Chrome:
And here's how it looks in Firefox:
To double-check, I used the Web Inspector to apply a simple border to the first element. It showed up fine (looked like the Firefox screenshot). Adding border-right-width: 0 reintroduced the problem. It seems clear that that's the issue. But I don't know why?
It seems like border-radius may play into this as well? The Firefox screenshot above shows a double-border in the middle, despite the Inspector showing 0 right border. If I uncheck border-radius, in Firefox, it fixes that issue.
These properties should all be independent of one another. Why are they affecting each other?
Edit
Trying to recreate in codepen. Unsuccessful so far, but it looks like it has something to do with transform - these inputs are in a container that is set with the following
position: absolute;
top: 50%;
left: 50%;
#include transform(translate(-50%,-50%));
This has the effect of vertically and horizontally centering the element no matter the width or height in modern browsers. When I turn off transform the border shows up as it should. As I understand, transform accesses the GPU? Or it can? It seems quite possible that this is what's throwing it off. If you look at the screenshot, there are strange border artifacts (like, a partial, interior border on the right side of the left element) that I can't explain.
Edit 2
It's got to be transform - changing the border-color to red makes this clear: the border is being rendered at a sub-pixel level and then, for some reason, cut off in a funky way. You can see a vague pink border around the left input:
This may or may not help and without the fiddle, it's difficult to recreate; but I wanted to share something I've recently encountered with webkit browsers and Foundation.
By default, Foundation attaches a right float on the last column in each row or horizontal block...
foundation.css
[class*="column"] + [class*="column"]:last-child {
float: right; }
99% of the time this is never an issue, unless you have a very small border between columns. Webkit browsers calculate percentages strangely at times.
You mentioned your columns were floated left, but just in case this is still an issue; overriding the above pseudo class to float the last-child column left may help.
Hey guys I am having a small issue with an assignment. I have to create this page and it looks great in Chrome but every div cell renders one pixel smaller in Firefox, I believe it has something to do with border width. Is there a work around or something I am doing wrong?
I am using a CSS reset, and I have declared my doc type.
Should I have just built this page using tables instead? Sorry no link to published code, also when I place the code in the code block it still displays the HTML.
https://docs.google.com/file/d/0B8uifJLGRXapcHF1VzRNNGo1b2M/edit?pli=1
Thanks in advance.
Try using CSS outline that will also work. An outline is a line that is drawn around elements (outside the borders) to make the element "stand out".
However, the outline property is different from the border property.
The outline is not a part of an element's dimensions; the element's total width and height is not affected by the width of the outline.
ie.
.example {outline: 1px solid pink;}
Try using the box-sizing property in CSS to fix this problem. box-sizing:border-box; will render the border and padding inside the actual width and height of the element. For a better description check this http://css-tricks.com/box-sizing/
I have an issue that terrorizes me in my sleep, unrelentingly . If you have an attainable solution and care to share it, please do; I'd like to have a normal night of sleep again.
On my latest project, there are multiple times when I will need to have 4 or 5 elements floated next to one another. Each element must be sized using percentages (%) but must also have border-right: 1px solid #000.
Once upon a time, I would normally size each element with percentages, then create a child element that would have all of the styling properties that the parent probably should have had, including the border-right. This solution isn't ideal, however, because it involves a lot of unnecessary markup.
A co-worker then directed me to another solution. When an element has a width that is sized using %s, and also needs to have border-right: 1px solid #000, apply margin-right: -1px as an offset. And while it works, it created another issue for me (which is why we're here, together, in union).
When zooming out in any of the major browsers (ctrl mousescroll, ctrl -), the floated elements that have been the focus-of-discussion tend to dance around a bit; the last element toggles between breaking to the next line and then snapping back. Please refer to the image below:
The reason this should be addressed is because the scope of the project has the potential of serving people from many different demographics (especially those who may need to scroll in, or out for that matter, to make the text larger or smaller). A very broad project, indeed.
How can I reach my goal highlighted in the example above?
How can I have 4 or 5 or more (or less) bordered elements floated next to one another, sized proportionally using %s, WITHOUT them breaking form?
You can use the experimental box model CSS3 declaration to have the borders detract from the elements width instead of adding on to it. This should prevent the problem. Quirksmode has a nice write up on it. It is supported by IE8/9 and current versions of webkit, opera and ff.
li {
-webkit-box-sizing: border-box;
-moz-box-sizing: border-box;
box-sizing: border-box;
}
The basic issue here, I think, is that you're 'misusing' the width property - width is supposed to control inner boxes, not the size of outer boxes. That is, your borders are supposed to be added on to your boxes, not included in the calculated width.
The result is that you don't have many choices beyond either:
Using Javascript to do some fancy recalculation,
Seeing if you can trigger quirks mode and use the IE5 box model (NOT a good idea),
Replacing borders several background images in lots of stacked divs (not nice), or,
Floating 20% width containers, then putting width:auto divs (not width:100%) with borders in the parent floats.
I know solution 4 sounds horrible, and means non-semantic markup, but it's a common kludge and one that other developers will probably understand (too) well.
This may sound horrible, but why not use a background image to create the border?
.box_20_percent {
width:20%;
float:left;
padding:0;
background-image:url([one_pixel_colored_image]);
background-repeat:repeat-y;
background-position:right
}
This should leave the "border" out of the resize calculation altogether.
If you declare the border-width and negative margin in ems instead of pixels, there is no wrapping/jumping. I realize this may be cold comfort since it would compromise your design somewhat, but it works!
I am trying to create a layout where the vertical spacing between divs is pixel perfect. So far I've ruled out almost all the big grid systems (960.gs, Blueprint), because they have no solution at all for the vertical spacings. With them, the only way to set vertical spacing between divs is to use body { line-height } attribute and manipulate the div spacing using that. I wouldn't call that a solution, as it ruins your template, depends on font-family, and doesn't let you use different spacings for different divs.
The only grid system I found which has proper support for vertical spacing is Golden Grid, which doesn't use body { line-height }, but has it's own .clear { height: 5px } for vertical spacing.
My problem is that no matter how I try, I couldn't make spacing work in HTML5. I am talking about vertically arranged images without gap between them. In XHTML transitional mode, everything works perfecly, the images align perfectly, but when in HTML5 mode, they have a vertical gap between them. The gap is 2px in Chrome and 2-3 px in Firefox, alternating between lines. I think it's the case with every grid system when used in HTML5 mode. I don't know what's the best way to write this code in plain HTML5, so I just tried grid systems. The vertical gap is present in 960.gs, Blueprint too.
A solution I found out might be to set body { line-height: 0 } and define line-height in every single typographic tag. But I don't understand why such a bad hack would be required for such a simple case: vertically arranged images. Why are browsers different in HTML5 mode than in XHTML Transitional mode?
Here, I have the same page, nothing changed, just the doctype. The XHTML one is pixel perfect in every browser, the HTML5 one has the gap and is different from browser to browser.
What is the best way to make the HTML5 example work like the XHTML transitional one?
UPDATE: thirtydot answered the problem, if I include img { display: block; } the HTML5 version behaves exactly the same as the XHTML Transitional. Thank you thirtydot!
But before closing this thread, can someone explain to me why is it that:
Why do all browsers behave differently in HTML5 mode and all have different vertical gaps between img elements, when not specified as display: block. Have a look in a browser comparing site for the html5 link above, it will be different from browser to browser. They have gaps between 2 to 4 px.
Why does XHTML Transitional not need this hack
Why does XHTML Strict produce a vertical gap too
Is it safe to use img { display: block; } in a reset.css sheet?
Why do all browsers behave differently in HTML5 mode and all have different vertical gaps between img elements, when not specified as display: block?
First of all, browsers do not have a "HTML5 mode". What they have are three modes "Quirks", "Limited Quirks" (aka Almost Standards) and "Standards" mode. There is only one difference between "Limited Quirks" and "Standards" modes and that relates to the way in which a line-height and baseline is established for the line box of which the <img> sits. In "Limited Quirks" mode, if there is no rendered text content on the line, then no baseline is established and the <img> sits on the bottom of the line box.
In "Standards" mode, the line box always contains the space for the descenders of characters like g, p and y below the baseline, even if there are no real characters in that line box.The gap you see is the distance between the baseline and the bottom of the line box which is the space for those descenders. For a thorough description, see http://msdn.microsoft.com/en-us/library/ff405794%28v=vs.85%29
The remedy, then, is either to stop <img> being treated as an inline element { display:block; } or to override the vertical alignment of the <img> { vertical-align:bottom; }. Either will work.
Why does XHTML Transitional not need this hack
Using the XHTML Transitional doctype places the browser into "Limited Quirks" mode. Had you used XHTML Strict, or a full HTML4 Strict doctype, you would have seen the same gaps as you see with the HTML5 doctype as each of these places the browser in "Standards" mode.
Why does XHTML Strict produce a vertical gap too
See above.
Is it safe to use img { display: block; } in a reset.css sheet?
Of course, but there will probably be times when you'll want <img> to be treated as an inline element. In those cases, you'll need to add CSS in the appropriate places to achieve that.
I feel like this can't be the answer you're looking for. It's too short:
Add to the CSS of your HTML5 page: img { display: block }.
Testing in Firefox and Chrome, doing that gets pixel perfect identical rendering between your two pages.
The vertical-align: baseline is causing the gap at the bottom of your images.
In Strict doctypes, images are inline elements and behave like text. Aligning inline elements at the baseline causes them to leave room for text descenders even if there is not any text.
Adding img { vertical-align: bottom } to your reset stylesheet will fix the problem.
Try this code:
<html>
<head>
<style>
div, span { border:1px dotted; height:100px; width:100px; }
</style>
</head>
<body>
<span>100px</span>
<div>100px</div>
</body>
</html>
When you consider that <img> is an inline element like <span>...I think most of your questions are answered.
Without the width/height attributes, your dependent on each browsers rendering engine to being identical (they're not). So pixel perfect won't work until you tell the browsers how many pixels to use.