IE/Edge styles applied in different order compared to other browser - javascript

I am finding that styles are being applied in a different order in IE edge compared to chrome.
Example
on this site http://videojs.com/ inspecting this element
<div poster="http://vjs.zencdn.net/v/oceans.png" preload="auto" class="video-js vjs-fluid vjs-paused preview-player-dimensions vjs-controls-enabled vjs-workinghover vjs-v6 vjs-mux vjs-user-inactive" id="preview-player" lang="en-us" role="region" aria-label="Video Player"><video id="preview-player_html5_api" class="vjs-tech" preload="auto" poster="http://vjs.zencdn.net/v/oceans.png" tabindex="-1">
...
</div>
IE
Chrome
what is the reason for the difference?

The order that each browser lists the styles in is not the order that they are actually applied to the element. This can be easily seen by comparing the two lists. Although they may list certain selectors in a different order, both are applying them equally (neither browser is applying something that the other browser isn't). Each browser vendor is free to set up their development tools in whatever way they like - there are no standards to follow on that. So, it's perfectly reasonable to expect differences in how various browsers report information in their tools.
There are specific rules about CSS selector "specificity" and what selectors will override others. Both of those browsers are standards complaint and apply the specificity rules equally.
Only when two selectors have identical specificity, and when the properties set in those selectors conflict with each other, will the location of the selectors (relative to each other) in the overall CSS be a factor.
Both your div and your video elements have ids as well as classes applied to them, so there are multiple styles being applied with different specificity. Also, the video element is nested within the div, so inherited CSS properties come into play.
Understanding CSS specificity is the key to solving your issue.

Related

How to add Keyboard navigation( Accessibility Access) to existing website using JavaScript, CSS or HTML?

How to add Keyboard navigation to an existing website using JavaScript, CSS, or HTML?
I don't want to add any paid apps. if you know free javascript library or something let me know.
similar techs I used:
tabindex="0",
a:focus{border : solid 2px blue}
Some concrete advice:
Use standard HTML5 elements where possible. Read up on HTML5 semantics, in particular headings and navigation. Before reaching for custom classes and CSS display/visibility features, make use of HTML attributes like hidden and disabled to control the visibility and availability of content and UI.
By all means use <div> and <span> elements for presentation and layout, but pay attention to document structure. Let semantic markup reflect/express the meaning you intend. ARIA landmark roles can help, although most of them are implicit in HTML already.
Note that the "Outline algorithm" mentioned in the HTML5 spec is not implemented on any browser, so don't get too hung up on perfectly sequential heading levels, just be consistent and logical. I find that starting each landmark with a new <h1> tends to be easiest to manage, but others prefer to have only one <h1> per page (thereafter starting distinctly meaningful areas or landmarks with <h2>). Both approaches are acceptable, and the exact choice should depend on complexity and did I mention consistency?
Add ARIA attributes sparingly, and only when HTML does not already express the intended semantic. (e.g. adding aria-pressed to a <button> turns it into a toggle button). No need to add aria-disabled="true" if the element already has a HTML5 disabled attribute.
It's worth knowing that ARIA attributes work well in CSS attribute selectors. If you use them, you can style your content based on their values, which keeps things synchronised.
Ensure that all operable/interactive elements are clearly labeled using standard HTML mechanisms like <label> if possible. If a visible label is not desired, or is ambiguous without visual cues, you may use aria-label to provide an 'offscreen' one.
More complex interactions may need some special keyboard handling in javascript.
Pay attention to the many articles offering guidance about color and contrast (for users with low-vision or color blindness). In particular, make sure the keyboard focus indicator is always clear and obvious. (You mentioned the CSS outline property in your question, so you are on the right track).
Provide text alternatives for all non-decorative images. If you're using an <img> tag, the alt attribute works very well. Decorative images need this too, but with a null value. (e.g. alt="")
Bear in mind different screen sizes and orientations. Consider using responsive CSS features such as media queries, grid and flex layouts. Avoid re-ordering content visually when it contradicts the meaning of the sequence in the underlying HTML code.
Consider that users may want to increase text size or line spacing using custom settings. This means leaning on relative units such as %, em and rem, rather than px, which should be reserved for hairline borders, or media query breakpoints.
VALIDATE YOUR CODE using an HTML validator. Free dev tools such as axe-core will also give very useful feedback and helpful guidance.
Use stack overflow for concrete questions. It's pretty reliable. Many good accessibility questions have already been asked and answered. Search first!
If you follow this advice, and if your product is not too outlandish in design, you will most likely be able to approach a high level of conformance with WCAG A/AA without too much pain.
Finally: Transparency is more important than full conformance. If you have WCAG violations you can't fix in the current iteration, be open and honest about it, and you will be in the clear, legally speaking. Perfect conformance is rare, and especially so for a first time accessibility implementation. Welcome to this challenging and rewarding field, and good luck!

How do I know when to abandon vendor specific prefixes? [duplicate]

I have a website which I support as far as IE8, no further.
When I first launched the site, I decided to use CSS vendor prefixes for CSSs elements such as border-radius, box-shadow etc. I did this from a complete noob standpoint.
However, is a better approach not to use them and simply let browsers catch up rather than patch up for the sake of uniformity?
No, you shouldn't remove all of them, however you may as well remove the ones which are no longer required.
How can I find out which prefixes are no longer required?
Can I use... is a great resource for checking browser support for various CSS, HTML and JavaScript features. If you perform a search for box-sizing, for instance, it will tell you that all modern browsers have partial support for this and that Firefox requires the -moz- prefix. You can also view all of the CSS support tables on just one page here.
How can I clarify that the prefixes are no longer required?
There are a couple of online resources which display information about browser usage. An example of this is StatCounter. StatCounter offers browser version statistics which can be filtered on time. If we look at the last 3 months, we can guestimate that we should still aim to support Firefox 20+, Chrome 25+, IE 8+ and Safari 5.1+.
Personally, I would just keep your vendor prefixes for now - this still remains professional practice - those browsers who don't need them, will simply ignore them anyway.
Our approach is to drop those which aren't needed.
border-radius
box-shadow
box-sizing (soon? firefox still uses it. Noted by #James Donnelly)
opacity (not a prefix, but no need for the ms-filter thingie)
inline-block (same here, no need for inline+zoom fix)
If you really want to get rid of prefixes, one of the solutions you can try is -prefix-free. It's a javascript plugin which loops through your stylesheets and, according to current browser removes the unused ones.
Although I didn't test it, I think it will definetely lower the performance.
You can also remove prefixes for properties which doesn't have a signifact meaning for functionality and/or user experience, like border-radius, box-shadow etc. You would have to test each element how it behaves without these properties. E.g. you have a button with border-radius: 4px. In a browser which doesn't support border-radius it will simply have rough corners. You must only consider if its worth sacrificing.

Can I detect whether CSS filter effects are supported?

CSS Filter Effects is currently in draft, but already supported by chrome. It provides the possibility to apply effects to images:
The CSS filter property provides for effects like blurring or color shifting on an element’s rendering before the element is displayed. Filters are commonly used to adjust the rendering of an image, a background, or a border.
Included in the CSS standard are several functions that achieve predefined effects. You can also reference a filter specified in SVG with a URL to an SVG filter element. (source)
As far as I know, CSS filters effects are only supported in Chrome 18+ yet, however is it possible to detect the availability of CSS filter effects via JavaScript or some CSS tricks?
You can use the Modernizr Javascript library for CSS3 feature detection I believe.
According to the following links, (as of Modernizr 2.6) Modernizr can now be used for CSS filter detection:
http://www.browserleaks.com/modernizr#filter
http://modernizr.com/news/ (under the test improvements section).
and http://modernizr.com/news/modernizr-260/.

Apply CSS rule to all future elements

I'm making a simple Chrome extension for personal use. I want to apply a CSS rule to all elements that match a class, even if they are rendered dynamically at some point after my extension's script is executed.
How can I do this in RAW javascript?
CSS rules will match any current and future elements in your document. The style gets applied as the document changes.
HTML5Rocks has a great article to give you a nice overview of how browsers work, including when and why layout and styling is applied.

-prefix-free Script and Prefixes in CSS

I am going to be remodeling a website and will be using the -prefix-free script to eliminate my prefixes in the CSS. However, some of the CSS I will not be editing. This CSS does contain some prefixes. If I leave those prefixes in the CSS will -prefix-free still work correctly or are there reasons I should go through the CSS files and eliminate all prefixes?
In other words: Will prefixes in the CSS break or cause weird functionality in conjunction with the -prefix-free script?
-prefix-free will leave any properties already prefixed in your stylesheet alone. In fact, it will not add other prefixes for the same property or rule if you specify at least one individual prefix for it.
For example, if you have
-webkit-border-radius: 10px;
Then -prefix-free will not add -moz-border-radius for Firefox versions older than 4.0, nor will it add an unprefixed border-radius for any browser. WebKit browsers will apply the border radius as usual, since they understand -webkit-border-radius.
If you want -prefix-free to add prefixes for other browsers, you will need to change that to
border-radius: 10px;
So, it depends on which properties you want it to apply all the necessary prefixes for. If you want -prefix-free to apply prefixes everywhere that is necessary, you'll need to go through your stylesheet and remove any prefixes that were already there.
Of course, keep in mind that you may want to keep prefixes hardcoded for certain properties, such as WebKit-specific pseudo-elements, -webkit-appearance and -webkit-text-size-adjust. Again, this depends on the property; you may have to research and decide based on your layout needs.
The script's homepage contains a test drive which you can use to preview the results for prefixed and unprefixed properties. Bear in mind that the results are tailored to the browser you use to run the test drive, so if you add border-radius and run it in Firefox 4 or later, you won't see any changes. However, if you place a -webkit-border-radius declaration instead, you'll still see that -prefix-free leaves it untouched in the preview pane, without even adding the unprefixed property, regardless of the browser you use.
The -prefixes are only for supporting features that are present in the browser, but have not been standardized yet, or have not complete implementation.
Since a lot of spec has been standardized, the requirement of prefixes for certain properties are no longer required, and have been present since a lot of versions. example : border-radius.
You can have a look here, to see which properties still require the prefix.
There will be no effect when using a CSS, with prefixes for some elements, while no prefixes for the others.

Categories

Resources