For an online demo (project) I wosh to pretend an LCD display. I found a fine 7segment font https://fontlibrary.org/en/font/segment7 . One of it's fetures is that the decimal dot uses some kind of "negative kerning" (or letter-spacing, please apologize my lack of terminology), so it visually belongs to previous number. This is desired behaviour.
However, this behaviour works only in FF & Chrome, not in Edge/IE (
see https://jsfiddle.net/jan_koupil/o1c8srt1/2/)
#import url(//fontlibrary.org/face/segment7);
#display {
font-family: 'Segment7Standard', sans-serif;
font-size: 30px;
border: 1px solid black;
padding: 3px 5px 1px;
width: 142px;
text-align: right;
}
…
<div id="display">8.8.8.8.8.8.8.8.</div>
For these browsers I need to switch the font to a different variant or at least reduce font size in order to fit into the fixed size display DIV. My trouble is that everybody recommends testing features, not browser versions but I don't know which feature to test.
This could be due to missing kerning in Internet Explorer. See this answer on how to explicitly add kerning to the text rendering for IE. You might also check other Opentype features and how they are activated via CSS.
Related
I have some issue which only encounters my iPad Pro 12.9, but not on phones or desktops.
🐞 on : Safari + Chrome + Firefox
input[type=text], input[type=email], input[type=time] {
color: white;
background-color: black;
font-size: 1em;
width: 100%;
border: solid 1px white;
border-radius: 5px;
margin: 10px;
padding: 10px;
}
How do I make my inputs padding look nice on all browsers all devices?
Firstly you need to make sure your inputs aren't being over-ridden from another declaration which often causes the problem you have here, particularly in relation to the line-height and font-size properties. Set your line-height value to line-height: normal on your input elements. Using the input[] selector has a low specificity in the CSS cascade, hence why it could be being over-ridden.
If the above values aren't being over-ridden from a different part of your stylesheet you can use box-sizing:border-box, line-height: normal on your input elements. You'll most likely need to increase the padding value slightly to get the aesthetic look you require.
How about to use all: unset;
To be honest I found out about it just yesterday and not used it yet, but it seems to be widely supported.
Here is a small demo. Though, I used sass.
Screenshot from iPad Pro:
Screenshot from Chrome (on Linux):
You don't really need padding top and bottom within an input, so you can remove it, just use padding: 0 10px
If some browser do not vertically centres the text, you can equal the line-height with the height and that should be fine.
also apply a box-sizing: border-box; rule will probably avoid differences between browsers on how do they render paddings.
I got a problem on Firebug tools. You can see the pic. I drag it.. where is it from? and one more think if i write just some css it's expand a lot.. like
h2 {
padding: 20px
}
but when i am trying to copy my css style then
`h2 {
padding-top: 20px;
padding-right: 20px;
padding-bottom: 20px;
padding-right: 20px
position: 0 0;
}
please help me
They are not bugs, but features, Bapy.
ua.css stands for User Agent CSS and is internally used by your browser. You need a CSS reset to override it.
In style inspector, all shorthand properties can be expanded to see each of the individual properties they stand for.
Additional note: Over (at least) the past year, Firefox has been a step behind Chrome regarding (web) developer tools. Most of their recent enhancements have been implemented after that functionality was initially featured by Chrome dev tools and they look and feel surprisingly similar in Firefox.
For example, at the moment of this writing, Chrome dev tools currently feature a cubic-bezier() viewer which is not available yet in Firefox. I expect one to show up in Firefox dev tools over the following months.
For development purposes only, I recommend using Chrome, at least for the time being.
Please note the above note does not mean I don't appreciate the extraordinary effort and the quality of MDN as a resource, which I highly recommend. It is an incredible aid in web-development and has grown to be a dependable source of information on web standards.
CSS has properties for specifying the padding for each side of an element:
padding-top
padding-right
padding-bottom
padding-left
so you must have to use shorthand css like :
h2 {
padding: 50px 30px 50px 80px;
}
or you can specify individually by name like
h2
{
padding-top: 50px;
padding-right: 30px;
padding-bottom: 50px;
padding-left: 80px;
}
Hopefully it is useful to you :)
I ask this because when I try to create a CSS font stack for multi-language content, such as English and Chinese, the final rendering is affected by the first font in the stack (usually Latin ones, since most Chinese font comes with Latin support).
See this Codepen, for example.
div.a p {
overflow: hidden;
}
p {
background-color: red;
border: 1px solid black;
display: inline-block;
}
.chinese-only {
font-family: "Hiragino Sans GB", sans-serif;
font-size: 24px;
line-height: 48px;
}
.english-chinese {
font-family: "Avenir Next", "Hiragino Sans GB", sans-serif;
font-size: 24px;
line-height: 48px;
}
.chinese-english {
font-family: "Hiragino Sans GB", "Avenir Next", sans-serif;
font-size: 24px;
line-height: 48px;
}
What I am seeing:
Since Chinese glyphs only appear in the Hiragino Sans GB, I expect all Chinese blocks to use the same line height. But they are apparently affected by adding the Avenir Next font at the top of the stack.
Since both Firefox and Chrome on OSX renders my example the same, I wonder if the CSS specification mentions anything about this. CSS 2.1 fonts spec doesn't appear to state what to do with line height when you fallback on missing glyphs.
Updated: Safari does render differently, but unfortunately the difference is due to overflow: hidden, not glyph fallback. My updated example may show this a bit clearer.
On Chrome and Firefox
On Safari
And if you are really into font-related headaches, try this example showing different font stacks, and see how they differ on each browser.
This is pretty much going to come down to the user agents. Any time the CSS specification says, “not defined by this specification”, that’s code for “we’ll let browsers do whatever they think is best and then try to get them all to behave consistently after a few years of doing it differently”.
Furthermore, the latest CSS Inline Layout Module states right at the top of Section 1 (Line Heights and Baseline Alignment):
This section is being rewritten. Refer to section 10.8 of [CSS21] for the normative CSS definition or the 2002 Working Draft if you want pretty pictures. (But ignore the old text, half of it’s wrong. We’re not specifying which half, that’s to be determined.)
That’s from last month. So, you know, good luck and Godspeed, basically.
Interestingly, I see a different result in Safari 6.2.2 than you posted:
If there’s a difference between that and the latest Safari, you might be able to track down a bugfix between the two versions that explains why it changed.
I am having a lot of trouble vertically aligning an entypo icon font.
Here is the codepen which currently displays as intended on Safari and Chrome on mac - http://codepen.io/anon/pen/jJtwz
As you can see the right arrow is vertically centred. Now the problem browsers...
Mac Firefox - The arrow is slightly lower but can tolerate this
It appears too low on the following browsers... (Every PC browser)
Mac Opera PC Chrome PC Firefox PC IE 10 PC IE 9
All the PC browsers seem to be resolved by adding a line-height:5px and getting rid of the top value.
Has anyone experienced the line height inconsistencies between browsers with icon fonts and know of a fix? It seems the OS has something to do with this as opposed to just browser inconsistencies.
I have tried all sorts of tricks like negative margins, absolute/relative positioning but cannot get consistent results.
Thanks
P.S. This was tested on all latest versions of browsers on the latest Mac OS and Windows 8
Here is the code if you cant view the link...
HTML
<section class="hbox hshop cfix">
<img src="http://placekitten.com/g/600/400">
<h3>Clothing</h3>
</section>
CSS
.hshop > a {
display: block;
border: 1px solid #ccc;
}
.hshop > a >img {
vertical-align: bottom;
padding: 0.75em 0.75em 0;
}
.hshop > a > h3 {
padding: 0.5em 0.6em;
position: relative;
font-weight: normal;
}
.hshop h3:after {
content: '\E766';
font-family: 'entypo';
position: absolute;
right: 0.3em;
font-size: 2em;
top:3px;
}
img {max-width:100%}
It was an entypo problem. The spacing around their glyphs was causing the issue. I used the icon fonts from fontello and this worked http://codepen.io/anon/pen/sidje
There are still inconsistencies in that entypo font. In all icon fonts.
The best solution I have found is set a baseline font size, and play around with you font metrics until you get something semi consistent Matching the base font metrics is a good start .This method works best if you keep the same size icon-font, changing the size throws everything off.
Also IE reacted better when I set the line-height a little smaller then the font size.
Really sloppy, but it got me close enough.
I fixed the font vertical space oiand made it available here https://github.com/zenx/entypo
There are buttons on my website that look overly skinny in Chrome compared to Firefox. The button's HTML looks like: <button name="shutdown" type="submit" value="df" class="boton"> Press </button>
My CSS attempt looks like:
.boton {
font-size: 17px;
color: #000;
background: #ee3333;
background: rgba(225, 50, 50, 0.6) !important;
font-family: lucida console;
border: 1px solid #FF4444;
padding: 2px;
-moz-border-radius: 7px;
border-radius: 7px;
cursor:pointer;
}
.chrome .boton
{
padding: 5px !important;
}
I'm not sure if I'm doing this right. ".boton" does indeed change the style of the button, but the padding doesn't change in Chrome. What's wrong here?
The reason that the padding isn't applying to the element is due to the fact that there is no chrome class assigned to any element. There are various hacks around certain Vendor-Specific styles, see this article, but no browser applies a class of .chrome or .moz or anything like that.
However, to achieve more "horizontal" padding, you can use the -webkit-padding-start(padding-left) and the -webkit-padding-end(padding-right). Currently I do not believe there is full padding, or vertical padding for these yet. Be sure when using these to write the -webkit-padding-start, or whichever rule you use, after your padding rule. Otherwise the latter will overwrite the former and both will be lost.
Unless you've also added some browser sniffing that adds the class .chrome etc. to the body that class has no effect.
On the other hand the box model of Firefox and Chrome is not radically different, but the defaults for padding, border, margins etc. may be different. Just explicitly set those values and they should most likely render the same (give or take a few pixels because of different rounding errors). You should not need to add custom css for each browser (but if you use experimental css features like -moz-border-radius and -webkit-border-radius with vendor prefixes you should use all of them in at the same time; the others will ignore the unknown properties).
The different versions of IE (Internet Explorer) do have a radically different box models, and if you cannot get some version of IE to render something correctly with the standard css you should use conditional comments to include IE specific css overrides after the main css file.