I applied a font family to the entire HTML document as below. The font changed for all elements apart from two buttons I have in the document. I didn’t use any other font styles on them. Why is this happening? Are buttons any exceptions? Any ideas?
When I declare this font directly under button element in CSS it works but when I remove it the font changes to the default one I guess. I can leave it there and it will solve the problem but I just want to understand what is happening.
html {
font-family: "Source Sans Pro", sans-serif;
}
Buttons are a bit weird for sure. I tend not to use them because of the need to style them seperately. I tend to think I may as well do it my way from the start. Not sure how much variation there is from 1 browser to the next but I suspect thier all styled slightly differently.
Only the CSS gods know why they set them apart probably, makes no sense to me.
Form elements don’t inherit styles because each browser has its own specific way of styling the actual elements. They are already specified in a stylesheet, so it’s the same as any other element in CSS. If you specified a font-family for the whole document but decided you wanted a different one for <h1> elements (and so used, for example, h1 { font-family: serif; }), those <h1> elements would use a different font because you’ve told them to use that. Buttons and other form elements use the browser’s stylesheet, so there is a definition for <button> elements’ font-family already.
You need to specify font-family: inherit to override that
EDIT for clarity: that’s on buttons and any other form elements you want to target, like:
button {
font-family: inherit
}
All the other elements afaik have a default font family specified in that browser stylesheet, but it’s at the same level that you’re specifying (html), and they are all set to inherit the font family. So when you write what you’ve written, you’re simply overriding that declaration in the browser stylesheet
You want to be very careful about this because buttons provide a lot of accessibility features that you will need to emulate with JS/ARIA if you use another element as a button. The overwhelming majority of accessibility experts will tell you to always use a button if that is the appropriate element. Yes, styling is a little more of a pain but it is not a reason to forgo accessibility.
I would highly encourage you to always use the semantically correct element.
Even from a basic usability perspective, form elements provide a lot of stuff out-of-the-box, replicating that from scratch during development to avoid small styling issues (and I must have written code to reset form element styles hundreds of time now, so I get those issues can be really frustrating) is not very practical.
What exactly is the advantage of using a button over an input? The FCC courses don’t mention any special properties of buttons nor do the other tutorials I have come across so far. W3schools and MDN don’t explain it very well.
Why and when would I want to use a button rather than an input?
Surely inputs have similar accessibility characteristics, not that accessibility for a tiny minority is particularly high on my list of priorities at this stage when producing something that’s functional and appealing to the masses is currently challenge enough for me without needing to be symantically perfect having not been tought those aspects in any detail.
you generally wouldn’t use an <input type="button">, you’d just use <button>, <input type="button"/> just isn’t a very commonly used element. If that’s what you mean, then I don’t really understand where you’re coming from at all: you’re not avoiding any styling problems at all because exactly the same things need to be done with that as need to be done with <button> elements to style them (and afaik they are a few extra issues that tend to crop up when styling input buttons vs button elements). If you don’t mean <input type="button"> then I have no idea what you mean, because you can’t replace a button with any other type of input.
Edit: What anyone reading your post is going to assume is that you’re avoiding using some elements (buttons in this case) because you find them hard to style, so it doesn’t make any sense why you’d think that meant using input elements instead, which are harder to style. They have the same level of accessibility when used in the correct context
So here’s the great part about using semantically correct HTML, you don’t have to worry as much about all those accessibility issues because they are provided for you automatically when you use the correct HTML element.
One advantage of a button over an input is that you can put HTML content inside the button:
<button>Your content here</button>
But yes, if you are just using a button to submit form data and don’t need to have custom content inside of it then you can use the input instead.
What I thought you were originally referring to was using something like a <div> for a button, which a lot of people mistakenly do.
Last thing, “accessibility for a tiny minority” is not a good way to look at this. In the “Real World” accessibility is a huge part of developing web interfaces (companies are even sued over not being accessible enough). And keyboard accessibility is very important, a lot more people depend on it than you would think, so it is not a tiny minority. If you want to be really good at this stuff, perhaps even doing it professionally, and especially if you want to have an edge over other people when applying for jobs, then the more you know about accessibility the better off you will be.
To be honest at my limited stage of development inputs and a tags do seem to cover links and submit buttons (input type = submit) which are about the only uses I can currently conceive of. That may change in time.
I do accept that accessibilty is an increasingly important part of web dev however I do feel that perfect semantics or expert accessibility is a lot to ask of learners especially considering that some pro web devs can’t manage it. Encourage good practice by all means but it cannot be expected of newbies.
For me personally the buzzwords are functional & responsive at this stage and they are challenge enough.
Thanks for taking the time to explain your point further.
