CSS - Text link larger than buttons - css

I have a style for inputs on my page, with some basic padding and font size, I tried applying the same style to a link, but for some reason the link is always larger (height) than the button no matter what I do, even with the exact same text and font size, I tried doing display: block but that just makes the button the width of the screen.
Here is the CSS:
.button{
padding: 10px 15px 7px 15px!important;
font-size: 16px !important;
color: white;
cursor: pointer;
border-radius: 2px;
text-decoration: none;
}
.button-3{
background-color: #ff4d4d;
border: 1px solid #ff4d4d !important;
}
I've looked at the Chrome styles panel and confirmed the font / padding is being used (it's not strikken through).
Here is what it looks like:

Looks like the issue is because:
You aren't using a CSS reset.
The line-height needs to be the same.
Make sure you give a consistent line-height to both. For now, set in the both:
line-height: 1.5;
This should fix it. Also, you can compare both the styles with the computed ones, to check if there's anything else being set. Since you say <button>, it might also have some border.
Also, like I guessed, you are also giving border and same colour as background to the button, making it look 2px bigger.
When you open the Developer Tools, try comparing the Computed Styles part:

To avoid this kind of stuff I always set the font family I used.
Take a look at this example: https://fiddle.jshell.net/tnr0jxka/
You also might want to consider adding:-webkit-apperance:none;-moz-apperance:none; to this kind of css, it will save you big time in cross-browser experience.

Buttons do not inherit the global styling automatically.
So, setting font-size of button explicitly will solve the problem
see this solution for more info

Related

some CSS rules are not updating in Safari

Note this is not because the css is incorrect or because Safari doesn't support these rules, its not that type of problem. I can uncheck and check the rule in the inspector and it works.
Im using Vue with sass for my website. The css works fine on every other browser, but on safari, theres a few instances where some seemingly random css rules are not taking effect.
The first example is this button, that gets enabled when the input is checked.
The button currently has the disabled class
When I check it, it removes the disabled class, meaning the background-color will be green and the font color white, this is the result
As you can see the background-color changed, but the font remained black. even though it has been updated in the inspector. In the inspector if i check the color property off and on, it will update and be correct.
Im applying these styles in the standard sass way shown below
button {
border-radius: 4px;
cursor: pointer;
font-size: 16px;
padding: 8px 12px;
font-weight: bolder;
display: flex;
justify-content: center;
align-items: center;
background-color: $secondary-color;
border: 1px solid $med-light-grey;
color: $black;
&.disabled {
pointer-events: none;
cursor: not-allowed;
background-color: $light-grey;
border-color: $med-light-grey;
color: $off-black;
}
}
I apply it to the button like this
<button v-if="!loading" #click="initalise()" class="submit" :class="{ disabled: !agreed }">Start</button>
The class does apply and remove correctly in the inspector and the color updates on every other browser
Im on Safari Version 14.1, on a new private browser, no cache, storage or anything. I dont know what could be causing this.
Here is another example where it happens
The content class stretches to 100%. But when i resize the window, making it a little bigger, the div doesnt stretch with it, so theres a gap. The background stretches as it should, and the header above it too. If i just uncheck and check the display: grid rule, everything works as it should and I can resize freely and the div will follow.
Im not sure if this is a browser issue, or the way my website is built, here are the versions that im using
"node-sass": "^5.0.0",
"sass-loader": "^10.2.0",
"vue": "^2.6.14"
Any help would be appreciated
Going to answer my own question, this was the problem for the button
pointer-events: none;
the pointer events property seems to be bugged on Safari and it will stop the DOM updating the color rule. I have found this codepen that replicates the problem and will fix when removing it.
Im guessing the 2nd example I showed is doing the same sort of thing with another property, but its a problem on Safaris end, so for that I will just restructure the html and css.
[codepen][1]

How do I make my inputs stay uniform on all browsers all devices - if possible?

I have some issue which only encounters my iPad Pro 12.9, but not on phones or desktops.
🐞 on : Safari + Chrome + Firefox
input[type=text], input[type=email], input[type=time] {
color: white;
background-color: black;
font-size: 1em;
width: 100%;
border: solid 1px white;
border-radius: 5px;
margin: 10px;
padding: 10px;
}
How do I make my inputs padding look nice on all browsers all devices?
Firstly you need to make sure your inputs aren't being over-ridden from another declaration which often causes the problem you have here, particularly in relation to the line-height and font-size properties. Set your line-height value to line-height: normal on your input elements. Using the input[] selector has a low specificity in the CSS cascade, hence why it could be being over-ridden.
If the above values aren't being over-ridden from a different part of your stylesheet you can use box-sizing:border-box, line-height: normal on your input elements. You'll most likely need to increase the padding value slightly to get the aesthetic look you require.
How about to use all: unset;
To be honest I found out about it just yesterday and not used it yet, but it seems to be widely supported.
Here is a small demo. Though, I used sass.
Screenshot from iPad Pro:
Screenshot from Chrome (on Linux):
You don't really need padding top and bottom within an input, so you can remove it, just use padding: 0 10px
If some browser do not vertically centres the text, you can equal the line-height with the height and that should be fine.
also apply a box-sizing: border-box; rule will probably avoid differences between browsers on how do they render paddings.

Stylish Add-On: border-radius property breaking my CSS

I'm using the Stylish browser extension to create a custom dark theme for a website. In a recent update, the site owner came up with rounded corners for a lot of things, which is ugly as hell in my opinion, especially with input fields. However, when I try to apply border-radius: 0px !important; using Stylish, the input fields go nuts. It works fine on things like regular divs, but not on any kind of inputs, be it a regular <input type=text>, a <textarea> or even things like a <select>.
This is how a text area looks like without my custom CSS:
This is how it looks like with my custom CSS:
This is how it looks like when I add border-radius: 0px !important; to my CSS:
When border-radius: 0px is applied, all other border properties and background are ignored. Not even the site's native CSS properties are used. The browser just uses the standard look like there were no CSS rules defined for the textarea at all. color still works though.
It's like border-radius was intended to change everything. If I add it only on :hover, the input fields only go crazy on hover. I don't even have to use 0px: The issue happens even when I use the same 6px that the site's native CSS uses.
This is my whole CSS rule:
textarea, input[type="text"], .textbox {
border-color: #282828 !important;
border-width: 3px !important;
border-style: solid !important;
border-radius: 0px !important;
background: #0F0F0F !important;
color: grey !important;
}
What's really weird is the fact that border-radius: 0px causes no problems when added using the Firefox developer tools, so it seems to be a problem with stylish.
What's causing this madness? How can I fix it? Is there a workaround? The only idea I had is to use a custom JS that adds the property ...
Oh my god, removing border-style: solid; fixes everything. I have no clue why, but I am happy now.

Load sections of a css file depending on the browser

There are buttons on my website that look overly skinny in Chrome compared to Firefox. The button's HTML looks like: <button name="shutdown" type="submit" value="df" class="boton"> Press </button>
My CSS attempt looks like:
.boton {
font-size: 17px;
color: #000;
background: #ee3333;
background: rgba(225, 50, 50, 0.6) !important;
font-family: lucida console;
border: 1px solid #FF4444;
padding: 2px;
-moz-border-radius: 7px;
border-radius: 7px;
cursor:pointer;
}
.chrome .boton
{
padding: 5px !important;
}
I'm not sure if I'm doing this right. ".boton" does indeed change the style of the button, but the padding doesn't change in Chrome. What's wrong here?
The reason that the padding isn't applying to the element is due to the fact that there is no chrome class assigned to any element. There are various hacks around certain Vendor-Specific styles, see this article, but no browser applies a class of .chrome or .moz or anything like that.
However, to achieve more "horizontal" padding, you can use the -webkit-padding-start(padding-left) and the -webkit-padding-end(padding-right). Currently I do not believe there is full padding, or vertical padding for these yet. Be sure when using these to write the -webkit-padding-start, or whichever rule you use, after your padding rule. Otherwise the latter will overwrite the former and both will be lost.
Unless you've also added some browser sniffing that adds the class .chrome etc. to the body that class has no effect.
On the other hand the box model of Firefox and Chrome is not radically different, but the defaults for padding, border, margins etc. may be different. Just explicitly set those values and they should most likely render the same (give or take a few pixels because of different rounding errors). You should not need to add custom css for each browser (but if you use experimental css features like -moz-border-radius and -webkit-border-radius with vendor prefixes you should use all of them in at the same time; the others will ignore the unknown properties).
The different versions of IE (Internet Explorer) do have a radically different box models, and if you cannot get some version of IE to render something correctly with the standard css you should use conditional comments to include IE specific css overrides after the main css file.

text-decoration: underline vs border-bottom

What is the difference to use {text-decoration: underline} and {border-bottom: ...}?
which is easy to style and cross browser compatible?
when we should use border-bottom over text-decoration: underline?
Would it be good to use border-bottom always in place of text-decoration: underline?
border-bottom puts a line at the bottom of the element box. text-decoration:underline renders the text underlined. The exact difference depends on the HTML and text layout engines in use, but in general if you want text underlined, then underline it.
Sorry to say this, but some answers here are misleading. Splitting a line of text does not place the border at the bottom of the entire block, because of the nature of inline blocks. Borders under links are actually more consistent across browsers than text-decoration: underline.
See: Text-Decoration vs. Border-Bottom
As Ignacio said, border-bottom will put the line at the bottom of the containing box, whereas text-decoration:underline will actually underline the text. This becomes an important distinction for multi-line strings.
I am a single line and will look similar for both methods
---------------------------------------------------------
would probably render the same for both styles, but you'll get the following for multi-line strings.
I am a string that has been
split and added a border-bottom
-------------------------------
I am a string that has been
---------------------------
split and underlined
--------------------
Apologies for using code formatting rather than properly rending these examples, but you can see the point I'm trying to make.
bottom-border lets you control the distance between the text and the underline, so its more versatile. And (as mentioned above) it allows a different color for the underline (although I don't see a reason why you'll want to do that).
text-decoration is more 'correct' because it is the 'real' CSS property meant for underlining text.
if you set text-decoration: underline for all links then you will have to set text-decoration: none for special links which you don't need an underline. but if you use border-bottom instead, you'll save one line of CSS code (provide you set text-decoration: none in your reset CSS.
so all in all, i'll vote for border-bottom if you have a complex layout with different styles for each link but text-decoration for a simple website coded 'by the book'.
While there are always going to be cases where one is more appropriate than the other, border-bottom offers much more precise control over text-decoration and is therefore probably the preferred method. Here's a quick (likely not exhaustive) list of properties that border-bottom can control/enable that text-decoration cannot:
Spacing between text and "underline"
"Underline" style (dotted, dashed, solid, gradient, image)
Thickness
CSS transitions/animations
Separation of color between text and "underline"
In many cases, most of these abilities will not be needed - but it is good to have them available! I've switched to using border-bottom primarily for the ability to put a few pixels of padding between the text and the underline; the next most common use I've found is divorcing the underline color from the text color.
With CSS variables now shipping in every major browser, a "reset" stylesheet might look something like this:
:root {
--link-color: blue;
--hover-color: purple;
--underline-color: var(--link-color);
}
a {
color: var(--link-color);
text-decoration: none;
border-bottom: 1px solid var(--underline-color);
}
a:hover {
color: var(--hover-color);
border-bottom-color: var(--hover-color);
}
This way, links will display as expected on a "default" basis, yet still allow for customization as needed.
setting your text to display inline (actually, it should be that by default) will cause the border-bottom to render much as a text-decoration rule.
however, i presume that you want to use this technique on links by doing the following:
/* my super eye catching dual colour link */
a {
color:black;
border-bottom:1px solid red;
}
which is all well and good, but you'll find that wherever you have an img tag inside a link, the image will have a red border under it.
if you can figure out a way to target the parent of a page element (the image) using existing selectors and no javascript, i'll buy you a beer but i don't think you'll have much luck.
using "text-decoration" avoids this issue altogether as an image is clearly not text, it will not render an underline when inside a link.
if you have complete control over your markup, i suppose you can bumble your way through by adding classes to every link, but if you're working with any popular CMS system, you're going to struggle with this idea.
Try this border with 1px image
a:hover {
background: url("img/bg-link-hover.png") repeat-x scroll 0px 92% transparent;
background-color: transparent;
background-image: url("img/bg-link-hover.png");
background-repeat: repeat-x;
background-attachment: scroll;
background-position: 0px 92%;
background-clip: border-box;
background-origin: padding-box;
background-size: auto auto;
}

Resources