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!
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'm working on a project where accessibility is of prime importance. There's frequent reference to parts of an ordered list and I'm not sure how to mark it up.
I made have a jsfiddle demo of referencing an ordered list with CSS Counters that I would like to implement, but I'm not entirely sure how accessible it is. I'm getting mixed results from my own research.
I would like to use the HTML5 feature, but the decimal aspect is important.
If I marked it up with screen-reader only tags (ie <li><span class="sr-only">3.5<span> ... </li>) then it's likely that the numbers will be double read. Of course, I'm also worried about them not being read at all...
Is there a best practice surrounding this challenge?
I tested your jsfiddle with NVDA in Firefox and it read every list item the way I would expect. I agree with FelipeAIs that you should test with other screen-reader software too as they vary a lot in their interpretation.
MDN shows browser support for counter CSS going back as far as IE8: https://developer.mozilla.org/en-US/docs/Web/CSS/counter-reset
If you find that only some screenreaders are picking it up, try using the start attribute as a fallback.
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.
I've posted an image of what my Chrome debug tools look like on a fairly standard JQuery Mobile page. I've already figured out that it actually isn't using the :visited style because none of the links are actually visited. I didn't have an :active style so the links were still blue. So I know what I need to do to fix it, but that's not my question. My question is why is it telling me that it is using that style when it is not? Is this a Chrome bug or am I reading the tool wrong?
You are looking at the total inheritence of all classes. To see what final properties are being applied clicked on "computed"
Also this looks like JQUERY mobile so I suspect you are going to run into some issues of very large class paths that are not easy to detect. I posted a few of these up here - one in particular about styling buttons.
Here's something interesting, turnsout that many people out there had this problem, but i couldn't find a solution:
Problem is related (and observed) only with IE8 and IE7:
If i add filter: progid:DXImageTransform.Microsoft.gradient( startColorstr='#FFEEBB', endColorstr='#FFEEBB',GradientType=0 ); to css "body" then all fonts on my page are messed up! If i remove "filter", font's are back in normal.
What's wrong?
P.S. Messed up -> Fonts look jagged, exactly like there's no cleartype!
Internet Explorer disables ClearType rendering in all elements that use a DXTransform.
There's a workaround described here that involves a relatively positioned wrapper element. It seems to be working in IE8 at least.
That looks very much like a proprietary Microsoft filter. Unless you know that 99% of your website users use ie, don't use those filters. Of course, if you are using this in an ie-specific style-sheet, to complement another style-sheet for proper browsers, you can use that filter without ruining your market.
Either way, I would highly recommend not using an ie-specific filter (or anything ie-specific really). Instead you should recommend to your users subtly to change to a more compliant browser, with less security holes and privacy-concerning back doors.
I"m no expert, but it sounds like you are using something that is IE specific. If so, I could not recommend highly enough that you find another way. Gone are the days of IE being the only browser to develop for and doing so will turn away numerous people.