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:
Related
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.
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.
I have Google'd this nine-ways-to-Sunday, but can't seem to come up with anything that fits my needs... I'm looking for a Firefox extension (and or Eclipse plug-in) that does the "opposite" of what SitePoint's handy Dust-Me Selectors does. Briefly, I want to be able to go to a page and get a summary of all the class and id attribute values that are specified in the HTML markup. Dust-Me is more stylesheet-centric, in that it compares the used and unused STYLESHEET selectors to what appears on the page. I need to find classes and ids that are specified in the page, but have no corresponding stylesheet selector, or no stylesheet at all for that matter.
The venerable Web Developer extension for Firefox does exactly this, EXCEPT, it's overlayed on the rendered page, which is not quite what I need. I'd like output more akin to Dust-Me; i.e., a summarized list.
Sure, I can do this with command-line grep... except that I can't, because I'm dealing with JSF, and I wanted to see what the rendered output in the browser is.
Another reference is PrimerCSS. It does "sort of" what I want, but I'm looking for a more on-the-fly, Firefox solution; and again, a list-- not a template. PrimerCSS makes you copy/paste the markup into a form on the site, and then comes up with a naked CSS stylesheet. Useful, but not.
Any leads?
It sounds to me like Firebug combined with the CSS Usage plugin would get you what you want.
I am working on a big form and it contains a lot of buttons all over the form, therefore I am trying to get working input[type="button"] in my main css file so it would catch all buttons with out having to add a class to every single one, for some reason this is not working on IE7, after checking on the web it says that IE7 should be supporting this.
Also it has to be type="button" and not type="submit" as not all buttons will submit the form.
Could anybody give a hint what am I doing wrong?
input[type="button"] {
text-align:center;
}
I have also tried input[type=button]
I was struggling getting input[type=button] selectors working in IE7 or IE8. The problem turned out to be that the HTML Pages were missing a "!DOCTYPE" declaration. Once I added
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
Then everything worked fine. You can obviously use a different "!DOCTYPE" declaration to suit your requirements.
input[type="button"]{ text-align:center; }
What do you expect that to do? The text in an <input type="button"> is already centered by default.
If you want to align the button itself within the parent, you have to set text-align on the parent element, not the button.
Attribute selectors — with or without quotes — do work on IE7. It's IE6 that's the problem browser there.
I've had no problems getting css statements like that working in IE7; IE6 is always the problem but I believe this CSS would work in there as well. So I don't think IE7 is the problem.
The first thing is that your CSS sample will only affect buttons, it will not affect submit buttons. But that's an easy fix; change your css to:
input[type="submit"], input[Type="button"]
{ text-align: center; }
Second, as Manolo Santos said, could you have another CSS statement that is overriding the text-align setting? A setting on just input elements? It's probably worth using a developer tool like Firebug or the developer components built into Chrome or IE8 to help find the CSS problem.
Attribute selectors are, unfortunately, not yet well implemented in all major browsers, because it is CSS3 and not 2.1, the current standard. Because the guys over at W3C are not that quick in making decisions, you better not set your hopes too high, because we won't be able to use css3 any time soon. Some aspects of it are already implemented, but this one isn't (surely not in IE6).
So, as you already said yourself, it would be much better to provide all of your inputs with a class, and make it a habit to do so every time you create a form. It's always handy and not a lot of work when you are already programming the form.
When I create a form, I always add the type of an input as a class, e.g.:
Especially the last two will come in handy in a lot of cases, because you don't háve to style the .button and .submit separately, but you cóuld if you would like to do so.
They work for me in IE7 (both forms, with and without quotes).
Maybe there's another selector that is masking yours. You could try making your selector more specific in order to give it more priority, e.g.:
body form input[type="button"] {
background: red;
}
I am pretty sure everybody is aware of the fact that the solution of adding a !DockType to the header isn't a possibility all the time.
For instance, I develop in DotNetNuke (DNN) environment which the developer doesn't have an access to the header. Then it makes it almost impossible to add !DocType.
In this case you don’t have too much of an option except relating a CssClass to the button and referring to it, explicitly, in the CSS module.
This question is old but if someone have a related problem.. I spend a few minutes trying to solve a similiar problem
input[type="Submit"] doesn't work on IE7 (despite of IE assigning the style correctly to the input as I saw in dev tools).
SOLUTION: I switched from Submit to submit and it worked!
I posted this here because it may help someone when debugging.
For whatever reason, there are times when attribute selectors will not apply before the page is displayed in IE7. This actually just happened to me. My selector was table[bgColor="#c0c0c0"] and would not apply on page load. Since I was using IE9 (Browser Mode: IE7, Document Mode: IE7 Standards), I was able to use F12 Developer Tools to look at my CSS file. I unchecked the selector and then checked it again. The attributes applied after that. This is reproducible exactly in good ol' IE7, so I'm going to have to find a work-around. (Note: Neither using single, double, or no quotes nor making variations in capitalization make an impact here.)
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.