We embed React components in our website. There are some basic styles which apply to our buttons, which come from the user agent (such as outline on focus) and from the HTML/CSS environment where we embed our React components.
We want our React components to be style independent. Since we also use our components in widgets, we can't really control the external environment.
One solution is for our basic Button element to render <div role="button" ... instead of an actual button element.
Is there any reason to avoid this practice, such as browser support, functionality, etc.?
Don't do this. Don't. It's accessibility hell. <button>s are interactive. <div>s are not. This is worst practice.
As you commented, focus is not available either on a <div role="button" ...>, which is quite nicely baked into a <button>.
while, i'm not sure but maybe we can control it using unique/different class name
Try using this (you can add it to your reset.css):
*:focus { outline-width: 0px !important; }
This should completely eliminate any visible outline, despite element's class name (or if it doesn't have a class name).
If at some point you'll need outline back, you can add it directly to your custom class.
Related
I've developing an app with Vue, and a third-party template, and dynamic plugins, and all kinds of trickery. I'm have a really hard time with the CSS.
Often I need to style particular element on the page, an <input> for example, and I can't figure out how to write a selector that actually works. The input may have been created dynamically by some Javascript and may have had CSS applied programmatically.
So I go to Firefox Web Developer, click on the element, and see a bunch of CSS classes. I create a rule:
.myCustomClass {
color: red;
}
put myCustomClass in the class="" tag in the <input>, and... nothing.
I'm thinking I need to prefix it like this:
.someOuterClass .someInnerClass .myCustomClass {
color: red;
}
but that rarely works. Sometimes I give up and add !important. Sometimes that works, and sometimes it doesn't.
So my question is, can I examine the classes that I can see in Web Developer and somehow derive a rule that is specific enough that it will always work?
I've read about specificity, but it's not helping.
Specificity is a PITA sometimes, especially when other 3rd party libraries are adding stuff to the mix.
Here are a few things you can try:
Make sure to add your styles to the END of the CSS. Theoretically, you can affect the order Webpack includes CSS (I've never tried it)
Add an ID not a class to a wrapper outside the elements you want to change. Then reference this ID in the CSS chain eg: #myAppID .className .subClassName {} Basically ID's are stronger than classes in CSS specificity. I would try to do this at a page/view level to make life easier.
If elements are already getting classes (as you see them in the inspector) try to reuse those classes with your "override" CSS. If the classes are modularized (Have a random suffix like someClass__34xft5) you shouldn't use those exact classes since they can change if the source is recompiled. In that case, use a "matching" selector [class^=”someClass__”] to match any selector with that prefix.
Not sure how deep you want to go, but here's an article about overriding Amplify-Vue prebuilt styling.
One caveat, if the CSS is being added inline via javascript somewhere, it's going to be very hard to override. You may want to use !important in conjunction with the above.
"...can I examine the classes that I can see in Web Developer and somehow derive a rule that is specific enough that it will always work?"
Probably, but why bother? You're already adding class attributes to elements. Why not add inline style attributes instead? Adding a bunch of classes or ids just to create a specificity chain to touch up styles is pretty messy...inline styles are barely if at all worse and are clearer to understand.
Inline attributes are the most specific CSS instructions you can give.
I inserted a button in header of page and I want change padding and margin of another element when a user clicks on this button. I used this code but didn't work:
a:clicked
{
#header
{
padding:0 40px 0 40px !important;
}
}
In css docs, programmers use # symbol at begin of their code. Can I use that? How?
CSS has no mechanism for giving your styles "state." It's difficult to make decisions in CSS based on "The user clicked a button," etc.
Difficult, but not impossible. One thing you could do is change the button to a checkbox and use the :checked selector. Another option is to hide the checkbox and make the button a label for it; this is known as the CSS checkbox hack.
The usual way, though, is to use Javascript to add/remove a class from an element when a button is clicked, then style based on the existence of that class. This is probably more maintainable since it doesn't require hacks to your HTML. Note that it won't work for users who have blocked Javascript.
I've been looking through various websites and came across multiple ways to make "buttons". What are the pros and cons to each way?
<div class='btn'><a>Click Me!</a></div>
<span class='btn'><a>Click Me!</a></span>
<a class='btn'>Click Me!</a>
CSS:
.btn{
display:inline-block;
min-width:100px;
text-decoration:none;
cursor: pointer;
}
Those are all three the exact same thing. They're all just a link, the only difference is that parent class is used as a selector target. They are effectively identical.
There is one differences between the first and second 2, though. a div, by default, is a block element while a span and an a tag are both inline, thus a dive fills up the entire width of the container, but that can be changed with css (as your example does).
Why not just, I don't know.. call me crazy.. but why not just use an actual button?
The only reason I can think of to NOT use a button is if you want the links to be search spider visible. If you're going to use javascript to post a form, then i suggest using a button instead.
I recommend reading this article by Chris Coyer. It's titled "When (and when not to) use an anchor tag?".
Here's an excerpt:
I think if you are going to put a href attribute on the anchor that
actually does something even if JavaScript is disabled, then the
anchor is the right choice. If the app is totally JavaScript dependent
all behavior is attached via JavaScript, I guess it doesn't really
matter what element you use. Maybe it's even better not to use an
anchor since the behavior probably bears no resemblance to what anchor
links do. You could probably talk me out of that though. The thing is,
anchors give you ("for free") lots of the visual functionality that
you want with deep browser support. So...
I'm not sure about the a tag (more info here), but the span tag is inline and the div tag isn't. Otherwise they're all pretty much the same.
the <div> and the <span> must have an action using javascript but the <a> can have a link to another page without using java script code
If you are using a form submit i prefer to use a input button. As it doesn't need further Javascript code to submit a form.
The difference between span and div is that div is a container element whereas span is not. How this is helpful to you? Check out his link.
If you dont want to apply any style and if you are okay in writing (or) if its a simple get request to server (or) if you are willing to write some javascript event handlers then go with anchor tags
I think the best method is the third one because you use only one DOM element instead of two. This will improve the performance and will make your code more semantically because you are not creating empty DOM elements for styling.
In addition, with the example 1 and 2 if the anchor is smaller than 100px the clickable zone will be smaller than the example 3.
My understanding about CSS is that, generally if you set <div style="color: Red">, all content inside <div> will be affected. However if you put a html button inside, the color on the words on the button is not affected. I'm a bit disturbed by this exception. How do I give a reasonable explanation to it?
It's about users' expectations of the user interface.
Buttons (and other user interface widgets) prefer to look like their operating system counterparts. On Windows, users expect buttons to be grey with black text, so that's how browsers present them. It's intentional that you have to try quite hard to override that behaviour.
It's because it would be impractical for input elements to inherit style information from parent elements, this means whenever you style a form, you would have to create style rules for every type of input used in it, to make sure they don't turn out unexpected. you can however force inputs to inherit their parent's style with css:
input {
color: inherit;
}
That code will cause all input elements to inherit their parent's text color style.
The "cascading" part of "Cascading Style Sheets" (CSS) means that in general, you're right: a property set on an object will cascade down to objects below it.
However for some properties this doesn't make sense, so those properties are explicitly non-cascading (eg if you set a border on a div, you don't want all its children to have borders as well).
If we were dealing with raw XML in our DOM, that's where it would end. The colour would indeed cascade all the way down. However, we're dealing with HTML, and HTML has some pre-existing conditions, exceptions and overrides. For example, a <div> always defaults to display:block; whereas a <span> will default to display:inline;.
Buttons and input fields have a lot of defaults and overrides, which is why they show up as buttons and input fields without you having to do loads of styling on them. This is also why they override the cascading effect of certain CSS rules, including color.
You can override the override by specifying inherit for the overridden styles. So if you want you button to take the red colour you specified previously, you would do something like this:
.mybutton {
color:inherit;
}
You will want to look up the rules for inheritance in CSS; certain property values will cascade to certain descendant elements, and certain ones won't. In fact, one of the possible values for many CSS properties is inherit, which suggests that this value is not always the default.
The browser itself has default styles for input types, dependent on the OS it's running on. So for Windows, it will most likely be grey, for Apple OS' blue and round (fancy).
There are very easy ways to override this in CSS, I use it all the time in my websites, customising buttons and input fields to better match my site design with images and as mentioned before color values either inherited or changed.
Here is a nice article explaining the cascade and inheritance rules native to using CSS that might help you out.
:)
Buttons and some elements else come with their own style. This style is browser dependent. In different browsers the buttons can look a bit different.
Is it possible to set CSS for disabled textboxes? I don't want the automatic gray-out in Firefox/Chrome.
The reason is that I'm sometimes disabling textboxes right before submitting a form so they don't get unnecessarily transmitted (and clutter the URL), and that gray-out behavior is degrading the user experience by creating flicker.
Help?
You should be able to style the text box by defining a class with how you want it to look, and then adding the class when you disable the input. If you're not worried about IE6 compatibility, then try using attribute selectors:
input[disabled="disabled"] {
/* your CSS style */
}
You should be able to use any styles you'd use on any other element.