Can't find anything on the topic, no idea if this is something old or new.
Basically, given an input[text] with adjacent div for a label which has any color besides pure black/white -- when selected (and caret is flickering inside) input somehow affects surrounding elements and visually dims them. Like some kind of filter is applied? Like a shadow or a blur or something, but it affects the entire parent' render stack no matter how far elements are from the input distance wise. TLDR: everything visually below the input is affected.
I tried checking computed props on labels and found nothing. CSSOM does not changes for them in any way.
You can try codepen, or any other sandbox.
The code is very simple:
<html style="color: #ffffff; background-color: #1e1e1e">
<head></head>
<body>
<div>
<input type="text" />
<div style="color: #f54562">Error 1</div>
<div style="color: #f54562">Error 2</div>
</div>
</body>
</html>;
I made a gif here:
Moving input into an absolute position helps isolating the effect, but obviously working with inputs like that would be very tiresome.
Checked on 2 different machines.
Reproducible in Chrome: Version 107.0.5304.107 (Official Build) (64-bit);
Edge also;
Works fine in Firefox;
So, some kind of bug or known quirk?
Related
I am trying to change the background color of a div using ng-repeat. The color I am trying to pull from the object in the loop. Whenever I do this however it sets my style property equal to blank.
Here is the code that I am using:
<div ng-repeat="channel in channelObjects">
<div class="mediumTile" style="background-color:#{{channel.Color}}">
Channel Color: {{channel.color}}
</div>
</div>
This displays my mediumTile object with the correct channel color displayed. By the style is set to nothing once the page loads
This is what the page displays:
<div class="mediumTile" style="">
Channel Color: 123456
</div>
Am I doing something wrong?
You should use ng-style instead of style, using style with interpolation will cause some browsers to strip the values off (invalid style attribute with the presence of {{ etc..) before even angular has a chance to process it. This happens specifically in IE (not sure which browser you tested this).
<div class="mediumTile" ng-style="{'background-color':'#' + channel.color}">
Also mind the casing as well, color.
Plnkr
What I'm trying to do is remove the drop down arrow from a select with this CSS:
.Gender:first-child::-ms-expand {
display: none;
}
The select element is disabled and its content is set programmatically. It is still a select because of our "unique" roll-your-own binding approach that would be a huge overhaul to replace/update.
Basically I have a section to input basic information for a dynamic number of people. The first instance is always the Primary instance and it's data comes from another section of the page so it's disabled here and bound to the values in that other form. Every other entry after it is editable. The idea was to remove the drop down arrow from the first selects because they're read only. I know that even though the drop down arrow is missing that the select continues to work but I still want it to be there for every other select that isn't disabled.
I know it works in a simplified JSFiddle but in my site ALL selects that have those classes are hiding their drop down arrow. What can I look for in my site that would circumvent the :first-child pseudo class? Why could it possibly work in the fiddle but not in the actual site?
Everything I'm reading says to check your doctype. Mine is <!DOCTYPE html public "-//W3C//DTD HTML 4.0 Transitional//en">. Nobody that I found ever explicitly says the exact doctype to use, so this may not be 100% correct.
Also, this only needs to work in IE10, it's an internal web app that'll never be run anywhere else.
The single most common cause of every instance of a specific element matching :first-child, when only the first of them should match, is if each of those elements actually exists in its own container element. Here's an example:
<div class='parent'>
<select class='Gender'>
<option>Male</option>
<option>Female</option>
</select>
</div>
<div class='parent'>
<select class='Gender'>
<option>Male</option>
<option>Female</option>
</select>
</div>
<div class='parent'>
<select class='Gender'>
<option>Male</option>
<option>Female</option>
</select>
</div>
Here, every .Gender is the first — and only — child of its parent element, .parent. The .parent elements themselves, on the other hand, are siblings of one another, sharing the same parent element (not shown). Depending on what your source looks like, it may be difficult to pinpoint the location of these parent elements within the source, but as long as your markup is valid, they should be somewhere.
If it does turn out to be the problem, fixing it is trivial — just move the :first-child pseudo-class to the appropriate element:
.parent:first-child .Gender::-ms-expand {
display: none;
}
Updated fiddle
I want to do a portion of a form look like a spreadsheet.
There are several forms and <table> is thus not viable (though I'm not against it when you do are printing semantically tabular data, as it is the case).
So I tried to simply use a CSS2.1 layout directly with the form input elements, eg.
<div class="table">
<form class="tbody">
<div class="tr">
<label class="td">Label</label>
<input class="td" name />
<input class="td" name />
</div>
</form>
</div>
Full example in the fiddle.
But it looks like display:table-cell does not work on <input> elements!
If you check in Chrome "Computed Style" the display will be "inline-element".
But I did not find anywhere why it shouldn't:
Mozilla Dev Network CSS:display
W3C CSS 2.1 Recommendation Visual Formatting Model
W3C Tables Recommendation
Any idea?
It sounded so much better than having some <div class="cell"> around the <input> and then having to play with box-model to get it look nice...
From W3.org:
"CSS 2.1 does not define which properties apply to form controls and frames, or how CSS can be used to style them. User agents may apply CSS properties to these elements. Authors are recommended to treat such support as experimental. A future level of CSS may specify this further."
Sorry, but display: table-cell on input elements is treated experimental. Try to avoid it, use wrapper-elements for the positioning for example.
I've made an example with div elements. You can now have multiple forms within a table, however it only works when the form element spans full rows. Otherwise your nesting will be broken.
EDIT:
Updated the fiddle with a version where border-collapse is added to avoid double borders.
JSFiddle example
Here's another CSS changes only question. [
Demonstrated here
So, I have a background sprite for some styling elements, and want to style textfields with endcaps (TEXTFIELD) and a repeating background. I've lined things up using padding spaces here in the example, which lets me set background-color, but not a background I think. I've been staring at this for too long, and need some advice. Is it possible to line things up the way I want them, without changing the HTML?
<label> Enter Zipcode: </label>
<span class='bg'>
<span class='leftcap'>
<span class='rightcap'>
<input type="text" class="textfield" name="zipCode" />
</span>
</span>
</span>
edit: I'm spitting angry over here, somehow lost my jsfiddle, and gar. My question still stands... the other jsfiddle linked shared a couple similarities, and served as a base, but I ended up changing almost everything by the time I had it set up. Good thing I copied a little over here.
edit2: here is a partial remade jsfiddle. http://jsfiddle.net/dreamling/P3Jev/3/
I changed outer2 to display:inline-block, that fixes it.
The strange gaps are there because inline-block elements are whitespace dependend (and a whitespace is exactly 4px at standard font-size)
Fix: add letter-spacing:-4px + line-height: 1px.
See http://jsfiddle.net/L8TyD/6/
EDIT: i removed the fixed width, and added hack to make it work in ie7
Take a look at this page in FireFox. Feel free to navigate to any of the top six product categories to see more of the same type of code.
If you are [un]lucky enough to see the glitch, you will see at least one product box expand it's height to epic proportions.
Here is the code:
<div class="product_category">
<a href="../products/dht_1500.php" style="height: 340px;">
<h3>DHT 1500</h3>
(superfluous HTML omitted here)
</a>
</div>
Here is what Firebug reveals:
<div class="product_category">
<a style="height: 340px;" href="../products/dht_1500.php"> </a>
<h3><a _moz-rs-heading="" style="height: 340px;" href="../products/dht_1500.php">DHT 1500</a></h3>
(superfluous HTML omitted here)
<a style="height: 340px;" href="../products/dht_1500.php"> </a>
</div>
You can see FireFox is definitely closing my tags and re-opening them again, and pulling the custom CSS height style along with it, which is resulting in each product box height skyrocketing. Also note that strange _moz-rs-heading="" bit.
I suspect my problem has to do with my using block HTML elements within an inline tag, but I thought I solved that problem by converting the tags to block formatting in my stylesheet:
.product_category a {
display: block;
}
FireFox is playing favorites to my tags. It usually renders the page like I want it, but then every once-in-a-while, it will blow one of my product boxes sky-high, and seemingly at random.
The pages work properly in Internet Explorer and Safari. I have been testing it with FireFox 3.6 on Mac, but have seen the same problem on FireFox for PC.
Having block level elements (h3) inside an inline element (a) is not valid HTML.
Change your block elements to a span and use CSS to style it how you wish.
A similar question with the exact same symptoms was asked a few days back. The solution there was in fact taking the native block elements out of the natively inline ones. Seems changing display doesn't help in this case.