I am developing a simple page with a form.
When I put a input text in the page, the characters that appear inside the input element have the browser default values, in chrome using the developers tools I can see that the font defaults to "webkit-small-control". But one of the fields that will appear in the page will be just a span field with data like this
<td>
<span id="readOnlyField">data</span>
</td>
When I render the page the data inside the span field is not equal to the data inside the input text field. My question is, how can I know the fonts and colors that the browser is applying to the input text field ? I can not use the value "webkit-small-control" because will not work in another browser.
I have only noticed this in Safari on a Mac. In order to make everything display the content as expected you need to override Safaris user agent stylesheet:
font: -webkit-small-control;
can be overridden using this in your reset.css:
button, input, textarea, select, isindex, datagrid {
font: inherit;
}
I cannot seem to find this in any reset.css but it done the trick for me.
In general, you can't know those values, because the defaults vary across browsers. Also, a user can set things like the default font family and style and hyperlink colors.
It is a good practice to use a "CSS reset" stylesheet to override browser defaults with your own "base" styles. There are lots of CSS reset examples on the web, for example the HTML5 Doctor's one or Eric Meyer's one. While your question is only about font style, resetting also other styles prevents many headaches in the long run.
There is no way to know for sure what default font-size the browser will choose.
You should instead reset the CSS (with Normalize for example) and further style your pages, for example:
span.some-class {
font-size: 12px;
color: #333;
}
And then your HTML:
<span class="some-class" id="readOnlyField">data</span>
that is the reason you should reset all the styles at first or use some established css framework like blueprint and avoid reinventing the wheel.
You should probably be overriding any style that you want in your css to aovid browser defaults
The default color for all major browsers for fonts is #000 but you can set it to whatever you want. The font you can set to whatever you want as long as it's on the system viewing it. Those defaults can be found by Googling.
There’s no known way you could find out, on your page, which font the browser uses by default. Neither can you specify in CSS that the browser render a span element using whatever font it uses by default for an input element.
But you can make text in span and input elements look the same (with the usual CSS Caveats, of course) by explicitly setting their font-family and font-size, e.g.
input, span { font: 100% Arial, sans-serif; }
In theory, you might need to set other properties too (there is no law against a browser displaying input element contents in blinking purple underlined by default), but this should take care of things in practice. Note that font size setting is needed, because browsers generally use reduced font size (about 90%) for input boxes.
If you are willing to use javascript, you can use getComputedStyle to find this data (check out Mozilla Developer Network).
For old IE browsers, you would need to use the currentStyle property (check out Quirksmode).
To copy ALL styles from one element to another, you could do something like this (I have simplified this to support modern browsers only):
var spanElement = document.querySelector('#mySpanElement');
var inputElement = document.querySelector('#myInputElement');
var styles = getComputedStyle(inputElement);
for (var name in styles) {
spanElement.style[name] = styles[name];
}
You will probably find you want to filter them, or only take a few ones you really want.
It is a behavior of WebKit.
See https://bugs.webkit.org/show_bug.cgi?id=50092
For a solution see: http://sijobling.com/tips/css-fix-for-html5-search-in-webkit/
Related
hello am having different h1 sizes on different browsers, how can i fix this please
h1 text on chrome h1 text on chrome
h1 text on firefox
h1 text on firefox
You will need to use CSS to set the font-size so all browsers will use that value instead of their own defaults.
h1 {
font-size: 2rem;
}
There may be other properties that you need to reset to get consistent, cross-browser results.
Many sites will employ a third party reset CSS like normalize.css or write their own defaults.
h1 tag is just pure html, so it is just semantic. HTML, as semantic, doesn't apply any styling. Browsers will always try to render "h" tags in a way that you can understand which ones are the most relevant, comparing it to the others. H1 will be bigger than h2 in every browser, but that doesn't mean they will appear exactly with the same sizes.
You need to apply your CSS to achieve the behaviour you want. Just keep in mind that html is only semantic, not styles :) usually we can insert a normalize or reset CSS code to our stylesheets, so that it resets browsers called user agent stylesheets. try to use a font-size property with the correct value on it. Good work!
Here is my code:
.blue {
color:#6E99E1;
font-size:9px;
}
<span class="blue">::CLICK HERE:: to view our New Equipment inventory. <br /><br /></span>
I've somehow triggered something that prevented the <a> tag from inheriting color of parent <span>.
Just an addendum to the other responses, if you want your <a> tags to inherit the colour from their parent you can use
a {color: inherit; }
By default an anchor tag does not inherit attributes like color if an href attribute is present.
Check out the difference between these two on a page:
<span style=color:green>test</span>
<span style=color:green><a>test</a></span>
The following link is to the w3 c:
http://www.w3.org/TR/html401/struct/links.html#h-12.2
User agents generally render links in
such a way as to make them obvious to
users (underlining, reverse video,
etc.). The exact rendering depends on
the user agent. Rendering may vary
according to whether the user has
already visited the link or not.
.....
Usually, the contents of A are not
rendered in any special way when A
defines an anchor only.
This is an answer to the question as well as a reply to Kevin's answer and its comments.
Anchor tags do inherit color, linked or not. The only reason they don't in practice is because they already have their color set in the browser's default stylesheet. The same can be said for the underlining of the link (which, I presume, you didn't notice, because you actually want it or had already changed it yourself).
In Firefox, you can see this in Firebug if you toggle "Show User Agent CSS" (or you can have a look at Firefox's internal stylesheets directly. You can see the browser's defaults in Webkit's Web Inspector and Opera's Dragonfly as well. I don't think you can in IE.
I don't know of any site which has an overview of all browser's defaults. CSS2's "informative" HTML4 stylesheet as well as the YUI reset stylesheet would be a good starting point, but neither of them mention any (link) colors (the HTML4 stylesheet does mention the underline).
To find out which properties are inherited in general, you can use the CSS2 reference property index table (see the "Inherited?" column). SitePoint also mentions it in its CSS reference.
So if you want to make sure your link inherits its color from its parent instead of from the browser's default stylesheet, you would ideally do something like this:
.blue a:link {
color: inherit;
}
You could set it for the different pseudo-classes separately (so :visited, :hover and :active as well), or for the a tag altogether.
However, IE6 and IE7 don't support the inherit keyword, so if you want to support them too, you'd have to set the color explicitly.
I think a doesn't inherit color by default. (certainly it has always worked that way on my sites). Why not change
.blue {
color:#6E99E1;
font-size:9px;
}
to
.blue, .blue a{
color:#6E99E1;
font-size:9px;
}
Firebug will show you exactly which style rules are applied to which elements. It's perfect for this.
(A non-CSS possibility: Do you have link/alink/vlink attributes on your <body> tag?)
Edit: Duh, silly me, the others have it right - <a href> doesn't inherit colour. But Firebug is still a good tool for this kind of problem (even if I'm not. 8-)
In addition to firebug (which should be your first port of call), the IE developer toolbar will also tell you where a given style is sourced from, just in case IE - shock, horror - should be different.
You need to explicitly set the color of the links to override the default blue color.
You are likely seeing the a:visited colouring. Try this:
.blue, .blue:link, .blue:visited {
color:#6E99E1;
font-size:9px;
}
In our application we use Bootstrap and there are multiple CSS files that are used.
Recently, I had a issue where there was a border created around a input box. The border for the CSS for input types were over-ridden in a particular CSS file.
I tried to use the Chrome DEV tools to identify which CSS file that input box was picking (for color) but for some reason it was not identifying the correct CSS files. For borders, shape and size it was mentioning it was inheriting from the parent but it never mentioning which is the parent CSS file.
Is there a better tool which correctly points the CSS that the component is using?
Is there a better tool which correctly points the css that the
component is using?
Firebug is great & very well developed. But works only in FireFox, which should not be a big deal for your basic CSS debugging purposes. In general there is no one good tool to debug things like this. You will always be jumping around from tool to tool to get things right. It’s just the nature of front-end web development.
But in general, might not have to even touch the parent CSS to deal with this issue. Just target the element in CSS—if it is not already being targeted—and use !important to force your new setting to override others from parent styles.
However, for balance, an "!important" declaration (the delimiter token
"!" and keyword "important" follow the declaration) takes precedence
over a normal declaration. Both author and user style sheets may
contain "!important" declarations, and user "!important" rules
override author "!important" rules. This CSS feature improves
accessibility of documents by giving users with special requirements
(large fonts, color combinations, etc.) control over presentation.
Here is an example code that would force outline: none to all input elements:
input {
outline: none; !important
}
You can even add border: 0px solid; to the mix as well:
input {
border: 0px solid; !important
outline: none; !important
}
I tried to use the Chrome DEV tools to identify which CSS file that input box was picking (for color) but for some reason it was not identifying the correct CSS files. For borders, shape and size it was mentioning it was inheriting from the parent but it never mentioning which is the parent CSS file.
In general Chrome Developer Tools shows exactly which .css-files are used and from which element the styles are inherited.
Can you maybe provide an example with your exact problem?
My understanding about CSS is that, generally if you set <div style="color: Red">, all content inside <div> will be affected. However if you put a html button inside, the color on the words on the button is not affected. I'm a bit disturbed by this exception. How do I give a reasonable explanation to it?
It's about users' expectations of the user interface.
Buttons (and other user interface widgets) prefer to look like their operating system counterparts. On Windows, users expect buttons to be grey with black text, so that's how browsers present them. It's intentional that you have to try quite hard to override that behaviour.
It's because it would be impractical for input elements to inherit style information from parent elements, this means whenever you style a form, you would have to create style rules for every type of input used in it, to make sure they don't turn out unexpected. you can however force inputs to inherit their parent's style with css:
input {
color: inherit;
}
That code will cause all input elements to inherit their parent's text color style.
The "cascading" part of "Cascading Style Sheets" (CSS) means that in general, you're right: a property set on an object will cascade down to objects below it.
However for some properties this doesn't make sense, so those properties are explicitly non-cascading (eg if you set a border on a div, you don't want all its children to have borders as well).
If we were dealing with raw XML in our DOM, that's where it would end. The colour would indeed cascade all the way down. However, we're dealing with HTML, and HTML has some pre-existing conditions, exceptions and overrides. For example, a <div> always defaults to display:block; whereas a <span> will default to display:inline;.
Buttons and input fields have a lot of defaults and overrides, which is why they show up as buttons and input fields without you having to do loads of styling on them. This is also why they override the cascading effect of certain CSS rules, including color.
You can override the override by specifying inherit for the overridden styles. So if you want you button to take the red colour you specified previously, you would do something like this:
.mybutton {
color:inherit;
}
You will want to look up the rules for inheritance in CSS; certain property values will cascade to certain descendant elements, and certain ones won't. In fact, one of the possible values for many CSS properties is inherit, which suggests that this value is not always the default.
The browser itself has default styles for input types, dependent on the OS it's running on. So for Windows, it will most likely be grey, for Apple OS' blue and round (fancy).
There are very easy ways to override this in CSS, I use it all the time in my websites, customising buttons and input fields to better match my site design with images and as mentioned before color values either inherited or changed.
Here is a nice article explaining the cascade and inheritance rules native to using CSS that might help you out.
:)
Buttons and some elements else come with their own style. This style is browser dependent. In different browsers the buttons can look a bit different.
I implement the Eric Meyer's reset.css in my website, and works great, but it was a little problem. As this a CMS users are free to format the content of their articles as they want and the reset CSS resets the formatting of their text.
Any ideas how we can prevent reset.css inheritance to propagate to the dynamic content?
All you input is more than welcome.
It will always propagate (that's kind of the point of reset.css :)), but if you're not already doing so, you should of course make sure that reset.css is the first stylesheet linked in your pages - any custom styles will then override the reset styles.
If the problem is that the styles are "too reset" and you'd like a more sensible set of defaults (e.g. weighted font sizes, margins, line-height etc.) for your dynamic content you could create your own baseline CSS styles and apply them only to the dynamic content area using an ID selector for example.
As Eric Meyer himself says on his CSS Reset page:
The reset styles given here are
intentionally very generic. There
isn't any default color or background
set for the body element, for example.
I don't particularly recommend that
you just use this in its unaltered
state in your own projects. It should
be tweaked, edited, extended, and
otherwise tuned to match your specific
reset baseline. Fill in your preferred
colors for the page, links, and so on.
In other words, this is a starting
point, not a self-contained black box
of no-touchiness.
By the looks of it, you're finding that the CSS Reset is doing a bit too much for you. I would therefore tweak it for the items you're experiencing problems with. For example, as you're experiencing problems with tables, I would either remove the parts of the CSS reset that target tables, thus leaving it at the browser default, or add extra CSS of your own after the reset to specifically style tables your own way.
I've had problems like that, my solution for that was to wrap the dynamic content generated by WYSIWYG editors, into a div with a unique class, where to that class I've created a reset style sheet with standard attributes!
Ex.:
div.wrap_to_prevent {style, style,
style}
div.wrap_to_prevent input,
div.wrap_to_prevent textarea,
div.wrap_to_prevent h1 {style, style,
style}
.
.
etc
Basically, I've used a reset style sheet, but preceded all css style's with the class of my div, that way, it just affects the code inside that div, thus creating a brand new set of rules for that content.
Since 90% of my projects use WYSIWYG editors, with this solution I was able to work around that same problem...
Can't tell if this works for you, but give it a try!!
Does the CMS create inline styles? If so these should override the styles from the reset.css file.
If the CMS includes it's own .css file, make sure that it appears after the reset.css file in your generated html output.
If you need to use the css reset, the only reliable way to work around this is to use an iframe element for the dynamic content. The main problem with iframe s is that they can't be automatically adjusted in height according to the inlying document's size. If you can work around that, I'd say this is the most hassle-free approach.