It appears that at one point in time combining multiple pseudo-selectors was possible. For example, one could do this:
a:visited:hover {color: red}
A quick Google search reveals multiple examples of this in action, here, here, and here. I am unable to get this feature to work in the latest versions of Safari, Firefox, or Chrome. Can anyone explain why this feature has regressed and/or been handicapped?
The :visited pseudoclass can't be used for most styling in a lot of modern browsers anymore because it's a security hole. See this link for a more formal discussion on it.
The short version is that if you can style :visited links differently, you can use that to determine if people have visited various sites, and therefore target them based on their browser history. Most modern browsers therefore heavily restrict the styling that can be done on them.
You can still chain pseudoselectors. For example, a:focus:hover works just fine to apply styles only if the element is focused AND hovered. See this link for a demonstration.
Related
I actually acomplished what I wanted to do: hiding some webkit pseudo-elements from the page when I want to print it, the code looks like below.
The problem is that I didnt learn anything from my research to do tha and I couldn't find any documentation about it, and every answer I saw about this topic only shows the code, without any further explanation.
::-webkit-resizer,
::-webkit-calendar-picker-indicator {
display: none;
-webkit-appearance: none;
}
Some sources:
https://developer.mozilla.org/en-US/docs/Web/CSS/WebKit_Extensions
This one show some extensions, but the callendar one is not listed here and I wasn't able to find elsewhere.
https://gist.github.com/afabbro/3759334
This gist has a lot of those pseudo elements, classes or properties, but the guy who did it didnt explain how he have acomplished that, and those doenst show on my dev tools.
Use pseudo classes for selecting webkit pseudo elements
This guy talks about the shadow-dom, I didnt heard of it before, but on my research I couldn't understand how it would help-me.
Some similar answers: 6195329, 11418289, 17340038, 15530850, 53483852
Also visited the wikipedia article and this site: https://webkit.org/
I really want to understand the concept behind this webkit things and any help would be appeciated.
To be more specific: if any time in the future I want to override a component, how can I know what pseudo-element has being aplied on an compnonet given the browser?
The best way to know which pseudo-elements you can work with is by reading specifications (like W3C standards) and realiable docs and resources (like MDN). If you can't find a particular pseudo-element there (or if it's only referred with a vendor prefix), you should probably avoid using it.
It seems ::-webkit-calendar-picker-indicator is supported by Blink and WebKit (follow the links for little pieces of information), but since it's poorly documented and also non-standard I would refrain from adopting it at all.
There is no specific documentation for pseudo-elements, but I finally could find, while tinkering on the Chrome Dev Tools' preferences a setting that shows the "Shadow-Dom" from the user-agent.
Go to "Preferences" and scroll to the "Elements" section, where there is a oprtion for that:
I am attempting to ask a more specific question than "how does browsers work??", please bear with me :)
If I understand correctly, html elements may have some default properties that determine their behavior. For example, <div> has display: block property set by default, while span has display: inline
These defaults exist because they are defined in the browser's default stylesheet.
Ok cool, I get that (hopefully). But what about <br /> or <img>? The behavior of those is determined by more than their properties right? Is it just up to the browser's implementation to make them behave how the W3 html5 specification says they should?
Also, is there an official word for this kind element behavior or does it just fall under 'browser implementation'?
So, you're really asking two questions here:
What is the default presentation and behavior of HTML elements?
Who/what determines how this works in a browser?
Let's start with question 2
The HTML specification is written and reviewed by a group within the W3C called the HTML Working Group. When they've agreed on a specification they publish it as a Recommendation. You can read the HTML 5 spec here, but I don't recommend reading the whole thing - it's very long and boring full of technical jargon.
However, the W3C's recommendation defines only the syntax and intended purposes of the features of HTML - it does not define how browsers should render HTML. Browser vendors, like Microsoft (IE), Mozilla (FireFox), Apple (Safari), and Google (Chrome), get to determine how their browsers render and implement the features of HTML.
Fortunately, most of the common HTML elements behave almost exactly the same from browser to browser. It's in the vendor's best interests to stay consistent among each other, because if one of them decided to do something drastically differently from all the others, the people who build websites would have to spend more time supporting that specific browser and it would fall out of favor (as was the case with IE 6 up until IE 11).
What determines the behavior of HTML elements?
The browser's rendering engine. Some browsers share the same rendering engines (like Safari and Chrome) (not true anymore - see comments), but not all. This article offers some insights (and leads to more insights) about how browsers are built, and here's an article listing several browser engines.
For the most part, you can affect how your HTML document looks by changing its CSS properties, but the behavior of most HTML elements is unchangeable without scripting using JavaScript.
The default CSS styles applied by your browser is defined by a stylesheet called its User Agent Stylesheet. These are usually pretty basic styles that browser vendors design in order to make HTML documents a little more readable without drastically affecting the presentation of the document.
However, there are so many basic styles applied by different browsers, that it's very common for web developers/designers to what's called a CSS reset. Normalize.css is a great example of this, and it's one of the most popular ones.
I believe it is up to the browser implementation. The way it will appear on the screen is up to the browser implementation.
Although, all browsers agree on how it should appear on screen.
These standards are defined by the World Wide Web Consortium - (wikipedia).
I guess this information you are seeking can be found in these sites!
I'm putting together a page, and am really struggling with backgrounds across browsers.
The page uses a number of alpha-blended backgrounds, box shadows and border-radii and it is composited almost entirely using inline styles (essentially there are few/no CSS classes used).
IE9 is my primary browser, and in it, the page looks great. However, on Chrome (and I'm told Firefox), most of my alpha-blended backgrounds render either not-at-all (transparent), or as solid colors! I'm using Standards Mode with an HTML5 !DOCTYPE declaration, so it's not as though I'm leveraging IE quirks or anything!
Clearly on IE versions before 9, the backgrounds (and other things are problematic). But I'm not concerned with supporting ancient software, and those users get a browsing experience that they deserve.
The common refrain for years has been that "transparency on IE sucks!", so I was comfortable in expecting that if I got it to work adequately on IE (typically the worst platform), then the others would just fall in line, but here I am struggling in the opposite direction! I'm using the standard "rgba(r,g,b,a);" directive on the "background-Color" attribute so I'm not using any radical DirectX filters or other magic, nevertheless, on (NOT Internet Explorer 9+) browsers, I'm getting some non-alpha-blended results (sometimes it works, sometimes it doesn't).
The site can be previewed at: https://net-xpert.com/ -- All of the pull-down menus are supposed to have translucent backgrounds, and so too the hovering link-bar at the bottom of the page. Also if you go to the "Ask us a Question" page, the dialog there should have tinted backgrounds on all of the input fields...
Oh, lastly, I am ENTIRELY LOATHE to implement ANY b/s, browser/platform-specific, 'experimental' style-codes! Anything in CSS2/3 is fine, but I simply REFUSE to use any kind of "-browser-some-quirky-CSSAttribute" styles! (I wish more developers would do this too! -- then browser manufacturers would be under greater pressure to adopt these STANDARDS and our lives would be SO MUCH EASIER, but I digress...)
Anyway, any insight on a standards-compliant solution would be greatly appreciated (even if it's just a communal acknowledgement that "ya, Chrome et al is currently not implementing this correctly...", at least then I'll know there's nothing to be done about it...)
Thanks!
Well, this is a very late answer, but maybe this'll still be of use to you (your site still seems to be up and running).
I have a should-work-for-you solution, assuming that you can modify one of your stylesheets. As to WHY you've encountered this problem ..? I can only speculate, because I don't know how to recreate your exact configuration.
The fix;
div[id^=mainMenuOverDiv] {
background-color: rgba(128,128,128,0.9) !important;
}
I'm not a fan of using !important unecessarily, and you may be able to remove that by using greater specificity. I've tested this in Firefox, though and it seems to work - obviously, you'll want to substitute the actual rgba(x,x,x,x) values with your own.
You seem to be using some JavaScript (I'm assuming) which randomizes the DIV ID every time you hover over the menu - but the beginning remains consistent (i.e. one time it will be #mainMenuOverDivjkhasdfsd89f9f9sdfl3l4l34lfdbvbc, then the next, it'll be #mainMenuOverDivLSDklsdkmlzxncbzmxnc90234xcvassf). Using the 'starts with' CSS selector (as provided in the example), you can still isolate the menu despite this potential spanner in the works.
It's interesting (and probably insightful) that this even works, given that inline CSS usually can't be overridden.
As for why this is happening, one possibility is that some JavaScript generated code is not correctly porting over to the non-IE browsers. Alternatively, if you're using it anywhere, code minification may also break some functionality (and vary between browsers) - many minification plugins need to be tweaked for individual setups to ensure that everything continues to work fine as one size does not necessarily fit all. For example, you might find that on one site you can minify everything except the JavaScript, while on another site, JavaScript is fine, but you can't minify inline CSS, etc. Google Analytics code sometimes falls victim to this.
So to my eye, the issue possibly isn't to do with IE/Chrome/Firefox or Safari - transparency is working fine on all of them - I think it's most likely the way your code is being manipulated or delivered to the browser.
Hope that helps in some way. Let me know if you can't use an external stylesheet and I'll try to find an alternative.
For the occasional late-night computing session, I like to tone done the colors of the sites I'm using for the sake of retaining my eyesight. My typical go-to extension is Stylish, a useful tool that loads custom CSS in webpages.
Curiosity and tampering led to the question I have here. Can I change WebKit's CSS defaults in WebKit's tags to better suit my needs? I'm speaking in regards to custom browser CSS rules, those used in Safari and Chrome for -webkit-, and others for other browsers. Is there any plain-text file that helps define these rules, which would allow me to edit them and therefore tamper with browser-loaded defaults?
What you're looking for are userstyles that would let you customize your browsing experience (if you're really specific about setting up your browser, you may want to do a quick google search on userscripts as well for more functional modifications)
The rules you are referring to are, for all purposes, bona-fide css rules with vendor prefixes.
Check out http://userstyles.org/ and from there you can download an add-on for Chrome here: https://chrome.google.com/webstore/detail/fjnbnpbmkenffdnngjfgmeleoegfcffe
I don't recommend going on with this. Making a page appear differently in a certain browser,
is not user friendly, but rather confusing
and its sure to decrease usability.
Having said that, that are many webkit specific rules which you can define. And, overriding them is the only way of changing the default behavior.
This page consists all the webkit specific rules and you can override these rules by redefining them in your style sheet.
For example:
-webkit-box-orient: vertical;
Override the default rule and orients the elements vertically.
Generally, what's the best way to tackle a layout bug in IE6? What are the most common bugs or problems that one should look for when trying to figure out why your page suddenly looks like a monkey coded it?
First Things First
Get yourself the Internet Explorer Developer Toolbar. It's a life saver and works great with IE6 and/or IE7. It's no replacement for Web Developer Toolbar or Firebug for Firefox, but it's better than nothing.
Know Thy Enemy
Read up on the quirks of IE — particularly hasLayout and overflow and the like. There are also many CSS niceties that you'll have to either do without or find alternatives. Look into how many of the popular JavaScript toolkits/frameworks/libraries get around different issues.
Rome Wasn't Built in a Day
The more you have to work with it, the more you'll remember off hand and won't have to lookup as often. There's just no replacement for experience in this. As several have pointed out, though, there are great resources out there on the net. Position Is Everything is certainly up there.
http://www.positioniseverything.net/ will certainly address your problem.
It provides comprehensive and in-depth descriptions of browser bugs along with options to work around them. A must read, in my opinion,
One good way to start learning about how IE happens to be mangling the page is to turn on red borders on different elements with CSS (border: 1px solid red;). This will immediately tell you whether it's a margin problem or a padding problem, how wide the element really is, etc.
The box model is usually the culprit. Basically what this means is that any div you are trying to position and use unsupported CSS with will cause this problem.
You may find it happens if you are using min-{width,height} or max-{width,height}.
this provides a great reference for checking compadibility with different versions.
http://www.aptana.com/reference/html/api/CSS.index.html
Noticed that Marc's post is at a -2 =D. He's only saying "resort to tables" even though they blow, because in sucky browsers like IE6, some of the broken CSS commands work in tables only (who know's why... dam you Bill Gates!!!). Here's a good reference to see what works and doesn't work as far as CSS goes. http://www.quirksmode.org/css/contents.html . It's a great reference to check on what cool effects work/don't work with various, widely used browsers. Also, always have a go-to plan for users who browse with IE6 (even though it's just about as old as mechanical dirt) as many businesses still use older browsers (including non-profits/3rd world countries etc.) So by all means, create the bugged out drop-down menu that looks WAY better than a standard horizontal menu, but create a secondary one specifically for IE6 that becomes the default when the page receives a request from an IE6 browser.
how do you define layout bug? the most frustrating layout implementation (i don't know if this should be defined as bug) in IE is we need to always specify style="display:inline" in the HTML <form> tag so that a blank line won't appear to disturb the form layout.
This question I believe has far too much scope.
Validate your code, and if pain persists, well, good luck.
The only real solutions, as with any other ballpark bug type are to google for a solution, or ask somebody who knows, ( ie: give the exact problem to us here at stackoverflow ).
You can use the IE Dev toolbar to glean an Idea, but many of the bugs are random, inexplicable, and esoteric. IE: the guillotine bug, the random item duplication bug, etc etc, the list goes on, and you can spend hours literally goofing with stupid variables everywhere and achieve nothing.
I have a simple strategy that works every time.
First, I develop the site using commonly accepted CSS to look good in Safari and Firefox 3. See w3schools.com for details on browser support.
Then, I go into IE6 and IE7 and alter the CSS using conditional includes.
This is hack free and lets you handle different browsers (IE6 and IE7 have separate issues).
Most of the issues you'll find come from unsupported features in IE (like min-width), errors in the box model (IE adds unseen extra padding (3px) to some boxes), or positioning issues. Go for those first as they are often the issue.
A common problem is padding not getting added to the width of a block element. So for layout div's, avoid using padding and instead use elements within them to define the padding.
I use Rafel Lima's Browser Selector when I need to tweak differences between IE/Standards browsers. It greatly reduces using "hacks" in your HTML to solve common problems.
You can target CSS statements for different browsers, or even different versions of browsers (Hello IE 6). It's very simple to implement, but requires the user has JavaScript turned on (most do).
.thing { ....}
.ie .thing { ....}
.ie6 .thing { ....}
We had a floating div issue that was only evident in a particular version of IE6. It was fixed by downloading the latest service pack.
In theory, use CSS compatible with IE6 layout bugs, utilise only well known workarounds (css and html filters) and code for them in a way that wont break forward compatibility, test for quirks/strict mode.
In reality, resort to tables.