I'm currently using google chrome to inspect the elements of a bigger project I am working on and noticed that it gives very neat hints (e.g. striking through properties that are later overwritten). It also gives the hint that a property is invalid with a yellow exclamation mark. Is this information browser specific and it is only not valid in google chrome or can I assume that this property will not work anywhere? (of course I could look up every property for which I get this warning, but if I knew definetely these were unnecessary I could get rid of them without much hassle)
Striking through properties that are overwritten should generally reflect general CSS rules, i.e. be browser-independent. But the browser’s code for that might be buggy. Moreover, a potentially overriding rule might use a nonstandard value for a property, and then it would depend on browser whether it really overrides.
Indicating properties as “invalid” in browser tools should be taken just as saying that the browser does not recognize (support) the property. So it would be very much browser-dependent. It may also depend on browser version.
Related
I encountered this question while browsing the Q&A section of an online course on advanced responsive design. I found an answer for it, shared it, and decided to post it here as well in case anyone else might have the same dillema.
The dillema is that it could be a lot easier for ensuring browser compatibility if we could define a different style for certain browsers that behave differently from most, e.g. Internet Explorer and, in the case of my website at least, Safari.
So how do we go about doing that? Check out my answer below to find out, and feel free to contribute if you think you know a better way to target specific browsers for specific media queries unique to them.
Using caniuse (https://caniuse.com/), look for a specific property that is only supported by the specific browser you want to target. Then, using the #support query, target that browser with the property you've found is unique to it. Then, whatever styling you apply within that query will only apply to the browser(s) that support(s) the property by which you defined the query.
That is, the properties inside the brackets of a #support query are used to define when - for which browsers - the styling inside the curly braces will apply; they do not need to be the same, that is, you do not need to use the same property styled within the curly braces to define the query in the brackets, so you can choose any property that targets the specific browser(s) you want to display the styling for.
Update:
I found this site that seems to provide the solution to targeting specific browsers and browser versions in the caniuse style, sparing you the need to test each property by hand:
http://browserhacks.com/
This article offers a briefing on how to use it:
https://www.templatemonster.com/help/how-to-create-browser-specific-css-rules-styles.html
Update:
For Internet Explorer only, older versions only, you can create a separate stylesheet to load for them using conditional comments in your HTML. This can be a copy of your general stylesheet, tweaked to work on old IE versions, but loaded only if those versions are detected, therefore not interfering with display on other browsers. They are not, unfortunately, usable for other browsers. This article explains how to use conditional statements.
https://www.quirksmode.org/css/condcom.html
Update:
The most effective solution to this problem seems to me to be to implement some javascript that detects the browser version and then applies specific styles or even modifies the DOM based on the browser(s) you target.
This explains the principle and some applications nicely:
Is there any equivalent to IE conditional comment for chrome and safari?
This, if rather old, is still a very useful such application:
http://rafael.adm.br/css_browser_selector/
And that's it! The ability to ensure browser compatibility with most any browser!
I have been reading this article about HTML5 Custom Element.
It said I need to register the element's name before using it like:
var XFoo = document.registerElement('x-foo');
document.body.appendChild(new XFoo());
Then I can start using it normally:
<x-foo>...</x-foo>
But I just tried using it without registering in Chrome, Firefox, and IE11. All seems to render just fine, even CSS selector for x-foo also works.
I'm guessing that we no longer need to register since most browsers have supported it?
Thanks
Short answer: No.
As a good practice, always define things that are not official. Just because it works by all/most browsers does not make it correct. That would be similar to using a variable which is yet to be defined, and then the compiler automatically defining it. Sure, it works, but that does not make it right
No, and document.registerElement isn’t even supported widely. It is experimental technology, work in progress.
Browsers traditionally treat unknown element names as specifying elements that have generic properties of HTML elements but no default functionality and no default rendering (the content is rendered according to its own rules). However, old versions of IE ignore an unknown element name in CSS unless you introduce it with code like
<script>document.createElement('x-foo')</script>
Using registerElement is useless for such purposes, since it is not supported by IE.
If you use registerElement, you should take caution, since calling it causes an error and script termination in many browsers. So you would need code like
if('registerElement' in document) {
var XFoo = document.registerElement('x-foo');
...
}
I'm wondering how fallbacks work in CSS. For example:
background-image: url("images/icons-page1/getq.png");
background-image: url("data:image/svg+xml;base64,PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0idXRmLTgiPz4KPCEtLSBHZW5lcmF0b3I6IEFkb2JlIElsbHVzdHJhdG9yIDE3LjAuMCwgU1ZHIEV4cG9ydCBQbHVnLUluIC4gU1ZHIFZlcnNpb246IDYuMDAgQnVpbGQgMCkgIC0tPgo8IURPQ1RZUEUgc3ZnIFBVQkxJQyAiLS8vVzNDLy9EVEQgU1ZHIDEuMS8vRU4iICJodHRwOi8vd3d3LnczLm9yZy9HcmFwaGljcy9TVkcvMS4xL0RURC9zdmcxMS5kdGQiPgo8c3ZnIHZlcnNpb249IjEuMSIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIiB4bWxuczp4bGluaz0iaHR0cDovL3d3dy53My5vcmcvMTk5OS94bGluayIgeD0iMHB4IiB5PSIwcHgiCgkgd2lkdGg9IjM0LjIzNHB4IiBoZWlnaHQ9IjMxLjg2NnB4IiB2aWV3Qm94PSIwIDAgMzQuMjM0IDMxLjg2NiIgZW5hYmxlLWJhY2tncm91bmQ9Im5ldyAwIDAgMzQuMjM0IDMxLjg2NiIgeG1sOnNwYWNlPSJwcmVzZXJ2ZSI+CjxzeW1ib2wgIGlkPSJBcnJvd18zIiB2aWV3Qm94PSItMTEuNTkyIC0xMC43NjQgMjMuMTg0IDIxLjUyOCI+Cgk8Zz4KCQk8Zz4KCQkJPGc+CgkJCQk8cG9seWdvbiBmaWxsPSIjRkZGRkZGIiBwb2ludHM9Ii0xMS41OTIsLTEwLjc2NCAtMi42NzEsMCAtMTEuNTkyLDEwLjc2NSAxMS41OTIsMCAJCQkJIi8+CgkJCTwvZz4KCQk8L2c+CgkJPGc+CgkJCTxnPgoJCQkJPHBvbHlnb24gZmlsbD0iI0VGRUZFRiIgcG9pbnRzPSItMTEuNTkyLC0xMC43NjQgLTIuNjcxLDAgLTExLjU5MiwxMC43NjUgMTEuNTkyLDAgCQkJCSIvPgoJCQk8L2c+CgkJPC9nPgoJPC9nPgo8L3N5bWJvbD4KPGcgaWQ9IkxheWVyXzEiPgo8L2c+CjxnIGlkPSJMYXllcl8yIj4KCQoJCTx1c2UgeGxpbms6aHJlZj0iI0Fycm93XzMiICB3aWR0aD0iMjMuMTg0IiBoZWlnaHQ9IjIxLjUyOCIgaWQ9IlhNTElEXzlfIiB4PSItMTEuNTkyIiB5PSItMTAuNzY0IiB0cmFuc2Zvcm09Im1hdHJpeCgxLjQ3NjYgMCAwIC0xLjQ3NjYgMTcuMTE3MSAxNS44OTU0KSIgb3ZlcmZsb3c9InZpc2libGUiLz4KPC9nPgo8L3N2Zz4=");`
First image is given with location. Second image is provided with value of the svg. I think it's clear that the second one will be displayed if browser supports svg, otherwise the first one.
What I'm wondering is, the first one is loaded and then the second one also loaded, since the second one modifies value of background-image finally it persist. if second one is not working for some browsers, then first one persist.
In both cases browser tries to load both of their value right? Or only the last one is executed?
I'm asking for performance related answer.
There is probably no explicit statement about this in specifications, but actual browser behavior (which can be observed by monitoring the network traffic for simple test documents) is that a URL is processed and accessed only after the browser has decided, applying the cascade rules, that a property value with url(...) is actually used. Thus, if a rule contains two background declarations that are syntactically valid as per CSS syntax, only the latter is used.
In the example case, the first background declaration never has any effect. It would be a different matter if the second declaration were of different syntactic form, say a keyword like dwim, which might be defined in some CSS spec in the future. Then old browsers would ignore it and use the first declaration instead.
So there is no fallback. The browser decides, on the basis of syntax (parsing) and by the cascade, which declared value will be used for a property, such as a url(...) value for background. If it then turns out that URL does not work or yields an image in an unsupported format, the browser does not go back and try another declaration instead.
When writing css on Chrome's "inspect element", it shows a list of possible values once you type the first few letters (e.g, bac...then it shows a list of possible properties to choose from, such as "background" "background-color" etc.)
I'm wondering if there's a way to access the full list of possibilities, before typing anything at all? For instance, if I typed in "font-family: (...now get me the list of fonts I can choose from without having to type in the first letter of it).
Edit: Well, it looks like Chrome doesn't really give hints for font-family anyway, but you get my point.
There is no mention of that being possible in the docs.
It would also be extremely impractical (and, IMO, useless) from a user interface standpoint to choose from a massive list, considering there are ~307 standard CSS properties, plus tons of -webkit- vendor-prefixed properties Chrome offers.
As to values, I don't undestand how you expect the Web Inspector to guess what you want.
It looks like Google Chrome 30 now supports this feature!
Why don't browsers autocorrect CSS3 transitions? The only difference between the Safari/Chrome and Firefox CSS transition is "moz" and "webkit". Surely firefox could just add an autocorrect feature to change every instance of "webkit" in the css to "moz" and the problem would be solved. Or is there something more?
Normally the -moz and -webkit are for CSS selctors are properties that are are specific to the the browser engine. The selector could be unstable, or act differently in each browser as they refine the behavior.
They don't want to "autocorrect" to the other implementation because the other browsers interpretation of the CSS property could be different. It could cause problems about what CSS property should "win" in the event of a conflict. Lastly, it could increase development time for each browser since they would need to figure out what the other browser engine is doing.
In the end what you want is to not use any -* prefixes at all. For that to be possible there needs to be a standard syntax and behavior defined by the, wait for it, CSS standard. Then instead of repeating *-opacity: ... several times with different prefixes, you just write opacity: ... once, like any other CSS declaration.
Vendor specific prefixes are there to allow browser specific behavior regardless of what the current standard says. It allows vendors to implement new features for which no standard exists yet, or to test the implementation of features before committing to it. The end goal is always to implement all features defined by the standard in the way the standard defines it; but you won't get there over night. New features need to be tested as widely as possible to find problems with their implementation or possible problems in the standard itself. This testing happens by making features available through vendor specific prefixes.
When you use a documented standard feature like opacity, it's pretty sure that it works consistently across browsers (*cough*letsforgetabout*cough*IE*cough*forasecond*cough*). When using a vendor specific prefix feature, it means you're using a feature at your own risk which is subject to change and/or may not work consistently (yet). Browser vendors don't touch each others prefixes for a reason, they work towards the standard and eventually make the feature available without prefix.