Inconsistent border widths on pseudo-elements because of translate3d -- but why? - html

(I've tried searching for this but can't seem to describe it correctly--if this answer exits, please point me in the right direction!)
I'm playing around with some css rules. I wanted to make a specific, secondary 2px-wide border on a pseudo-element appear around nav anchors in the header, which open a modal and blur an absolutely-positioned background image div #bg, which sits as such:
<body>
<div id="#bg"></div>
<header id="global-header">
<nav>...</nav>
</header>
</body>
Since I wanted to transition the blur effect, I added translate3d(0,0,0) to #bg, which smoothed the fps by galvanizing the GPU for hardware accelerated processing of CSS. It worked! ...Until I noticed that the vertical (left & right) borders for the links had inconsistent widths across the nav. They were each set at 2px, but every other one looked 1.5(??)px wide. It took me a minute to narrow down why, which ultimately was because of the translate3d transformation. I took screenshots, but I centered and moved the pseudo-elements with border-left: 2px below the header (the effect persisted), and I removed the background image itself so the effect would be easier to see. Here they are:
Inconsistent 2px calculation (with translate3d(0,0,0) on #bg)
Consistent widths (without translate3d transform on #bg)
And for reference, here's the code for the left-bordered pseudo-elements:
#global-header nav ul li a:before {
content: '';
position: absolute;
display: block;
top: 100%;
left: 50%;
height: 100%;
width: 0;
border-left: 2px solid gray;
background-color: transparent;
}
I know that translate3d creates as well as solves a possible host of issues from my searches--but why is this happening? Does it have anything to do with "subpixel calculations"? And why would these calculations render inconsistently throughout the page with hardware acceleration, on something I would assume is hard to mess up?
Edit: So, even without translate3d, the problem-lines flicker to a smaller width when the blur transitions (seen in the code from screenshots) are triggered, and I can reproduce the original issue without translate3d if I add backface-visibility: hidden to the pseudo-element itself. This could hint at general pixel rounding issues, with specific properties as triggers only being a symptom.

After further fiddling, answering my own question: This is not caused caused by hardware acceleration, which was my revised suspicion. Though the use of these effects showcased the problem in my particular case, I was able to recreate a version of my issue without them.
By removing transform3d from the #bg element:
#bg {
.
.
.
/* transform: translate3d(0,0,0); */
}
And, without the backface-visibility property as well, I added some width to the pseudo-element in order to see what these borders would normally look like:
#global-header nav ul li a:before {
content: '';
position: absolute;
display: block;
/* top: 100%; */
/* left: 50%; */
height: 72px;
width: 1px;
border: 2px solid black;
/* backface-visibility: hidden; */
/* border-left: 2px solid black; */
background-color: transparent;
/* transition: height .2s ease; */
}
Duh: I should have expected the result, since earlier I had tried to use the element itself (by making it 1-2px wide and coloring it) instead of border-left, which at the time seemed to fix the issue. Of course, when I did it this time using the above css, the base problem reappeared.
Though I still don't know why the aforementioned properties showcased the problem with border-left as well, addressing this might be too sporadic/situation-dependent to field here, and likely still has more to do with browser rendering than anything else.
Anyway, my question was why transform3d caused this effect, and the answer is, at least in this case, it didn't--it just made it more obvious.

Related

Is it possible to not trigger :hover on ::before or ::after?

I'm trying to make a custom tooltip implementation in CSS, which is working pretty decently, but I'm running into a problem. Currently, hovering over the tooltip still keeps the tooltip opened, even though I'm not hovering over the original element itself.
Of course I've tried something like ::before:hover {display:none;}, but that doesn't work because pseudo-elements don't get pseudo-classes applied to them.
My next thought was to simply make the tooltip not "take up" any space. Using negative margin-bottom allows other stuff to take up space in an element as if the element is not there. However, the :hover pseudo-class apparently still applies then.
Here's a demo of what I'd like to do. I'd like to have the tooltip of the following demo not persist any hovering state. Note that moving the tooltip-text higher above the element is not a working solution, because moving the cursor upwards faster than a snail's pace will cause some pixels to be skipped, which means the tooltip 'catches' the cursor and persists the :hover on the element.
[data-tooltip] {
position: relative;
cursor: default;
}
[data-tooltip]:hover::before {
content: attr(data-tooltip);
position: absolute;
top: -2px;
transform: translateY(-100%);
background: white;
border: 1px solid black;
}
<p>Spacer text</p>
<div data-tooltip="Example tooltip">Hover over me for a tooltip text</div>
As you can see, if you move your cursor over the div, the tooltip will appear, and if you slowly move your cursor up, the tooltip will disappear. If you move your cursor upwards slightly faster, however, it'll skip the 1-pixel gap, and keep the cursor hovering over the div.
Now I'm looking for some styles to apply to [data-tooltip]::before so that the cursor's hover events are not triggered on it (or at least, not at the location you see the tooltip; if I can hide it somewhere at [-1000, -1000] that's fine as well)
So basically, my question is, is it possible to apply css to an element so that :hover does not apply to (part of) an element? I'd love to hear ideas or suggestions.
Not sure if that's what you're looking for, but regarding the first question (red div, blue on hover), you could shorten the divs height and use border-bottom for making up for the lost height:
div {
width: 100px;
height: 50px; /* instead of 100px */
background: red;
margin-bottom: -50px;
position: relative;
z-index: 1;
border-bottom: 50px solid red; /* adds 50px to divs apparent height, but ignored at hover */
}
After looking around the internet for a while I finally found a solution that works flawlessly. I didn't really know about this before, but apparently there's a pointer-events style that does exactly what I want. Its accepted values outside of SVG are auto and none, but luckily the latter prevents all hover-events from triggering on the ::before pseudo-element.
Here's a demo:
[data-tooltip] {
position: relative;
cursor: default;
}
[data-tooltip]:hover::before {
/*** this style prevents persistence of the tooltip when hovering over it ***/
pointer-events: none;
/* the rest is just the styles used in the question */
content: attr(data-tooltip);
position: absolute;
top: 0; /* changed from -2px to 0 so the effect is more clearly shown */
transform: translateY(-100%);
background: white;
border: 1px solid black;
}
<p>Spacer text</p>
<div data-tooltip="Example tooltip">Hover over me for a tooltip text</div>

Difference in browser rendering/positioning for CSS triangle vs unicode

I'm showing a triangle next to some text inside of a container with display:flex. The text's width is not known at design time. The browser will calculate the width needed for it upon rendering. I've provided code below which highlights my scenario.
The issue I'm encountering:
On initial render .triangle-two's position is not correctly determined. The browser appears to not know the width of .text quite yet and so it incorrectly positions .triangle-two until a second rendering pass occurs. Just a moment after rendering .triangle-two shifts to its correct position.
By contrast, .triangle-one does not exhibit this issue at all. I presume that this is because .triangle-one is rendered as text, and thus in the same pass as .text where as .triangle-two is rendered at a different point-in-time making it ineligible for the proper positioning.
Of note, if I apply justify-content: flex-end to .container then this issue does not occur because .triangle-two is positioned first and then .text. So, it's a non-issue when going the other direction.
Is this a common problem? Are there any more elegant solutions?
Note: I'm unable to reproduce the issue with my example provided, but I'm unsure why. I feel confident that this example highlights my issue, but perhaps it's also dependent on page initialization.
* {
box-sizing: border-box;
}
.container {
height: 48px;
display: flex;
flex: 1;
align-items: center;
padding: 8px;
}
.text {
overflow: hidden;
text-overflow: ellipsis;
white-space: nowrap;
}
.triangle-one {
transform: scale(1, .5);
}
.triangle-two {
border-left: 6px solid transparent;
border-right: 6px solid transparent;
border-top: 6px solid;
}
<div class='container'>
<div class='text'>
Dynamic text
</div>
<div class='triangle-one'>▼</div>
<div class='triangle-two'></div>
</div>
Ended up figuring this out the next day.
The issue is that I have no text on the page on initial load and then append a bunch of views to the page which have text on them. I'm also using a custom font face.
Since there's no text on the page on initial load - the font face isn't loaded when the views are appended. So, the text shifts around once its font loads causing its shape to change. Then, the triangle next to it needs to reposition.

Firefox vs Chrome padding

I have a control that I am trying to highlight when it is selected. I'm achieving this using padding on a div and some positioning so that it surrounds the control. The problem I'm encountering is that the padding on the highlighter div renders differently in chrome and in firefox. Everything I've read says that they render the same so this shouldn't be a problem.
Chrome:
Firefox:
Here's a fiddle that has the problem on it:
http://jsfiddle.net/5fuGB/1/
.control{
position: absolute;
width: 100px;
height: 20px;
top: 30px;
left: 300px;
z-index: 1;
}
.highlighter{
background-color: orange;
position: absolute;
width: 100%;
height:100%;
left: -2px;
top: -2px;
padding-right: 8px;
padding-bottom: 10px;
z-index: -1;
}
input{
width: 100%;
height: 100%;
}
My Chrome Version:
Version 31.0.1650.63 m on Windows 7
My Firefox Version:
25.0 on Windows 7
Thanks for any help you guys can offer.
I believe the difference you are seeing is a difference which comes from the user agent stylesheet, browsers have their own default stylesheets which they use to render things like input elements. In your case it is probably a difference in the padding applied to the input element. You should specifically set eg: padding: 0px; or padding: 1px; on the input element, and then work out how to get it to look right for an input with the specified fixed padding. This will then override the styles set by the user agent style sheet.
Update
I moved to my Windows PC to have a go at fixing it. One way to fix this using one of the vendor specific prefixes from the answer linked in the comments is to add -moz-padding-end: 6px; to .highlighter to compensate for the differences in padding between browsers.
Here's a jsFiddle which fixes your issue, a footnote tho, I can already tell you that this probably won't fix it on Chrome for OSX, which was also rendering things the Firefox way.
Another way to fix this is by adding -moz-padding-start: 1px; -moz-padding-end: 1px; to input, but doing so somehow changes the bottom padding as well, which makes things look not as pretty in Firefox as with the other fix.
I'd go about it differently. Instead of using an extra div, I'd recommend using a combination of border-color and box-shadow on the input's :focus state to achieve the effect you're going for.
Check out this modified fiddle: http://jsfiddle.net/5fuGB/2/
Just experienced the same issue with my code, and fixed it too. The trick is if you use display: inline-block then line-height makes sense. Try it when debugging your code.
You're doing a little more than what's necessary. To get a highlight around that input you can use :focus
So it would be something like this:
CSS
input {
border: 1px solid white;
}
input:focus {
border: 1px solid orange;
}
That will give the input a white "invisible" border so it doesn't move the input when you click into it. It will simply change the border color to orange to get that highlight effect you're looking for.
EDIT
Just saw your comment. I dont have the rep to comment so I'll just add on to this.
If you aren't using the inputs as actual inputs, then I would just make them divs. Inputs render differently by default so that would mess with consistency across browsers.
I'd also recommend experimenting with those divs within one another and making the most outside div relative.
Outside Div <------ position:relative;
Middle Div <------- position: absolute;
Inner div <-------- position: absolute;
Also, if you need a selected state but don't want or are hindered by inputs then I'd recommend jQuery for modifying the css based on user interaction.

Custom CSS image hover-states

I've run in to a bit of a problem. I have a menu list where I custom made some image hover states for list items. This worked perfectly fine until I needed to change the menu items (list item text length, etc). I have to go back and re-make all of the images each time something changes.
Here are some images of what I'm trying to accomplish:
Basically the hover adds a red background and a duplicate of that red region rotated ~2 degrees and is lighter colored. Would it be possible to do this via CSS with :after and transform: rotate()? If not, what would be a nice way of accomplishing this effect for varying word lengths?
Thanks ahead of time!
Tre
This can easily be done with transform as you say. You'll need to have two elements in each button though, one for the text and one for the skewed background:
<div class="menu-button">
<div class="text">Screenings</div>
<div class="hover-bg"></div>
</div>
And style the .hover-bg class something like this:
#menu .menu-button:hover .hover-bg
{
z-index: 1;
position: absolute;
top: 0px;
left: 0px;
width: 100%;
height: 100%;
background-color: rgba(220, 50, 50, 0.4);
transform: rotate(2deg) scale(1.05, 1);
transform-origin: center right;
}​
Here's an example on JSFiddle
Here's an example where I had some fun with transitions. Due to lazyness I only bothered to make it work in Webkit, meaning Chrome and Webkit.
Note that for cross-browser compatibility you'll need the vendor specific property prefixes (-webkit-, -moz-, etc)
this can be done in pure CSS (not even 3).
On hover have a tilted background image, position it a few pixel to the left and top and add background color.
Because of the background color, you will see only a part of the image:
<div class="text">Screenings</div>
.text {
color: #000;
margin-left: 5px;/*to make room for the hover image */
padding: 4px;
}
.text:hover {
background: #900 url(tiltedimage.png) no-repeat -5px -5px;
color: #fff;
}
This will point you to the solution.

How can I style a part of a single character with overlays using a dynamic width?

Question
Can I style just a part of a single character?
Meaning
CSS attributes cannot be assigned to parts of characters. But if you want to style only a certain section of a character, there is no standardized way to do that.
Example
Is it possible to style an "X" which is half-way red and then black?
Not working code
<div class="content">
X
</div>
.content {
position: relative;
font-size: 50px;
color: black;
}
.content:after {
content: 'X';
color: red;
width: 50%;
position: absolute;
overflow: hidden;
}
Demo on jsFiddle
Purpose
My intention is styling the Font Awesome icon-star symbol. If I have an overlay with dynamic width, shouldn't it be possible to create an exact visualization of scores?
While playing around with a demo fiddle, i figured it out myself and wanted to share my solution. It's quite simple.
First things first: The DEMO
To partly style a single character, you need extra markup for your content. Basically, you need to duplicate it:
<​div class="content">
<span class="overlay">X</span>
X
</div>
Using pseudo-elements like :after or :before would be nicer, but i didn't found a way to do that.
The overlay needs to be positioned absolutely to the content element:
​.content {
display: inline-block;
position: relative;
color: black;
}
​.overlay {
width: 50%;
position: absolute;
color: red;
overflow: hidden;
}​
Do not forget overflow: hidden; in order to cut off the remaing part of the "X".
You can use any width instead of 50% which makes this approach very flexible. You can even use a custom height, other CSS attributes or a combination of multiple attributes.
Extended DEMO
Great work on your solution. I’ve got a version that uses :after (instead of duplicating the content in the HTML) working in Chrome 19.
http://jsfiddle.net/v5xzJ/4/
Basically:
Set position:relative on .content
Position :after absolutely
Set :after to overflow:hidden
Adjust the width, height, text-indent and line-height of :after to hide bits of it.
I’m not sure if it’ll work well cross-browser though — the em values will probably work out a bit differently. (Obviously it definitely won’t work in IE 7 or below.)
In addition, you end up having to duplicate the content in your CSS file instead of the HTML, which might not be optimal depending on the situation.