I would like to test if a browser supports a CSS property. I know I can use modernizr to do this but I don't want to install an entire library to test for one property.
How does modernizr test for properties? Say I want to test for support for the background-size property.
I scanned through the properties of the document object but couldn't see anything that looked like it would help.
Any ideas or help would be great.
Modernizr works by creating an element, applying a css property and then checking the return value of the css property. For example, if you wanted to test for text shadow you would do this:
if (document.createElement("detect").style.textShadow === "") {
document.getElementsByTagName("html")[0].className += " textshadow";
}
I think think this will be specific to each feature since you have to look for certain side effects in the DOM. Here is a link with some ideas http://www.sitepoint.com/detect-css3-property-browser-support/
Modernizr is an open source project - you can literally view the code that powers it. here is background-size detect specifically.
This is a fairly trivial thing to check. You create a dom element, set background-size (both vanilla and all of the vendor prefixed versions) to 100%, and then check the value of backgroundSize on the dom element's style property to see if it kept that value.
That being said - modernizr is pretty lean. You just get the tests you want, and nothing more.
Related
It seems like when modifying the CSS properties of elements when using JS methods (CSSStyleSheet, with insertRule or deleteRule, or CSSStyleRule.style.setProperty()), the underlying CSS has been updated, but the page itself not not reflect the changes.
The changes are only realised upon some reflow trigger, say after I've changed the attribute of the element, even if it's an invalid one.
May be related to this question: What are the conditions under which a browser will re-assess and reapply CSS selectors and styles?
What is the recommended way to modify CSS using JS? Apart from changing class strings, or a hacky way to insert and delete attributes?
Note: Testing on Edge / Chromium
After reading your post, I'm not sure if you are aware of these simple ones:
element.style = stylestring (IE: "display:block; color:red;")
or
element.setAttribute('style', stylestring)
These will be treated as inline-styles. So changed properties will take priority over the external css and the effect will be immediate.
Now, is it the recommended way? That's a tough one, I'll let others answer this question, I'm not really a W3C guy...
I am trying to find good tools for checking accessibility. One of the tools I tested said I should put set CSS background-color whenever I set CSS color.
Unfortunately that is not really an option for me, but I can see why the say so: color is explicitly inherited, but background-color is not. However background-color is kind of implicitly inherited because child HTML elements are (normally) contained within the parent element on the screen.
Now, with the last assumption (implicit inheritance), is there any way to find HTML elements where a contrast problem actually occur? Javascript? Chrome Workspace? FF dito?
Here is a list of utilities to check your content for accessibility problems.
10 colour contrast checking tools to improve the accessibility of your design
Check out WAVE at http://wave.webaim.org
They have a FireFox plugin, but be warned it's not as up to date as the website, so you might deploy a page and find it fails the online checking even after passing the plugin tests.
Chrome DevTools has a new feature called CSS Overview. Go into your DevTools settings, got to Experiments, and activate CSS Overview. You can then take an overview clip of your site on this, which tells you any contrast issues you may have. For instance, on this site on dark mode, it shows me this:
The AA and AAA refer to the standards of compliance reached.
I'm trying to write something in JS that allows me to tell whether a user's browser supports CSS3 blur, and display (or not display) an element as necessary. It doesn't look like Modernizr supports it, and I really couldn't figure out another way to check this. How can I do this?
blur is actually a value of the CSS filter property, and not a CSS property within itself.
To check for support of the CSS3 filter property with modernizr, you can simply use the Modernizr.cssfilters value.
I have created a Javascript based element that can be embedded into websites. The Javascript itself adds the HTML code into a pre-defined HTML container and dynamically loads the necessary CSS file that contain the element's visual definitions.
The problem starts when the site itself has its own definitions for general items. For example: The site's CSS defines a certain list style which is applied on the element's list because the element's CSS doesn't define an explicit list style or if the site's CSS overrides the element's CSS definition.
For the time being, I was able to solve this specific issue by explicitly defining the list's style and adding the !important definition. However, I would definitely want to go for a more robust solution that will assure that:
1. CSS definitions from the site's CSS that are not explicitly defined in the element's CSS will not be applied on the element
2. I will not need to explicitly add the !important definition to every one of my CSS definitions
Is there a general way in which I can specify that a site's CSS will not be applied on a certain element or that only a certain CSS will be applied to a specific element?
Any help will be greatly appreciated.
You need to use a localised reset.
Grab an existing CSS reset, such as Eric Meyer's Reset Reloaded and namespace all the selectors with your parent element, e.g. #something a { ... }.
I was going to put up the same answer as Alex, but he beat me - but I was also going to add:
If you're not going to use #alex's suggestion then ultimately you have to explicitly style all of your elements the way that you want them to appear; using selectors that keep your styles local too (and don't interfere with the parent site) - in the same way that the localised reset is suggested.
Update
Or you could do what Google Translate and many other widget-type things do, usually a no-no but in dynamic scenarios I think perfectly acceptable; since the visual style of your elements is not just important to you but to the container site: use inline styles.
Final update
So I thought I'd just double check what Google Translate does. And of course it's an iFrame inject in addition to using inline styles. They no doubt use inline styles to maximise compatibility and so that the browser doesn't have to make another request to get the stylesheet; and they would be using an iFrame so they can ensure a consistent look and feel.
Consider both of those points in tandem - and weigh that up against the amount of work that might be required in resettting all the styles for a minority portion of the page; or defining rules for every CSS property you need to control - which, let's face it, is basically all visual CSS properties.
The iFrame solution actually seems to offer the best solution - if you can use it; hence I've +1'd the first comment by #roberkules on your question.
How can you detect if a browser supports the CSS attribute display:inline-block?
Well, here's what you can go if you want to do it purely by examining the bavhiour of the browser w/ javascript instead of user agent sniffing:
Set up a test scenario, and a control scenario. With, say, the following structure:
div
div w/ content "test"
div w/ content "test2"
Insert one copy into the document with the two internal divs set to inline-block, and insert another copy into the document with the two internal divs set to block. If the browser supports inline-block, then the containing divs will have different heights.
Alternate answer:
You can also use getComputedStyle to see how the browser is treating a given element's css. So, in theory, you could add an element with "display: inline-block," and then check the computedStyle to see if it survived. Only problem: IE doesn't support getComputedStyle. Instead, it has currentStyle. I don't know if currentStyle functions identically (presumably it functions similarly to the behaviour we want: disregarding "invalid" values).
According to the QuirksMode charts, the only mainstream browsers not supporting inline-block are IE6 and 7. (Well, they support it, but only for elements which have a native display type of inline.) I'd just assume it is supported and then apply a workaround for IE6/7 via conditional comments.
(Note: I'm ignoring Firefox 2's lack of support for inline-block and assuming the vast majority of users have upgraded to FF3, but brief googling didn't unearth any numbers to back that up. YMMV.)
If determining support from JavaScript is your only option however, you'll have to fall back to user-agent sniffing. The YAHOO.env.ua class from the YUI library is a handy chunk of code that you could copy and use. (It's BSD licensed, doesn't depend on other parts of the YUI library, and is only about 25-30 lines without comments)
By the way: There is a neat way to implement cross-browser inline-blocks in IE6+, FF2+, Opera and WebKit with CSS alone. (Not valid CSS, but still only CSS.)
Christopher Swasey is quite correct.
I have set up a jsFiddle demo of his technique at http://ajh.us/test-inline-block.
The code is essentially:
var div = document.createElement('div');
div.style.cssText = 'display:inline-block';
// need to do this or else document.defaultView doesn't know about it
$('body').append(div);
// that was jQuery. It’s possible to do without, naturally
var results = false;
if (div.currentStyle) {
results = (div.currentStyle['display'] === 'inline-block');
} else if (window.getComputedStyle) {
results = document.defaultView.getComputedStyle(div,null).getPropertyValue('display')=== 'inline-block';
}
//clean up
$(div).remove();
alert('display: inline-block support: '+results);
Please note this exact same technique also works for detecting display: run-in support.
There is no way to detect that with Javascript as it is a pure CSS attribute that does not relate to any object or function in Javascript. The best thing I can tell you is to check here for a pretty good compatibility list and use CSS to create a workaround.