I am using a famous japanese font called "Meiryo" for on a japanese website. However, the usage of this font causes all my input fields to stretch. It is a very strange bug, if i replace the font by anything else, all my input fields get back to normal.
Anybody can explain me why this bug occurs please?
Tested on all major browsers
It’s not a bug. An <input type=text> element has its visible size set by the size attribute (defaulted to 20), which sets the width in “characters”. This means “average width” characters according to HTML 4, whereas HTML5 drafts say that “the user agent should ensure that at least that many characters are visible”. The reality varies across browsers. In any case, the visible width of the element should depend and actually depends on the properties of the font – on the widths of glyphs in it.
The following simple test (which assumes some common default font to be used for input) illustrates this:
<input value="Hello world"><br>
<input value="Hello world" style="font-family: Meiryo">
The latter element is considerably wider, and by looking at the appearance of the initial text, set you can see the reason to that: in Meiryo, characters (glyphs) are generally wider than in fonts commonly used as default input fonts.
The conclusions depend on the page design and layout. In flexible design, the details of layout adapt to the requirements of data and fonts, rather than the other way around. If the design is more rigid, you might consider setting an upper limit on the width in CSS, using pixels if you really must, e.g. max-width: 200px.
it's font issue
use CSS width and height property to solve the problem
I've been working with contenteditable recently within a HTML5 page and encountering bugs when using it with certain elements, and I'd like to know where and how I can actually safely use it.
I've discovered that making a span element contenteditable results in some buggy behaviour in both Firefox1 and Chrome2. However, making a div or section contenteditable appears completely safe3.
A guideline a couple of people have mentioned is that only block-level elements should be made contenteditable. However, the Mozilla Developer Network lists the heading elements h1 through to h6 as block-level elements, and making a heading element contenteditable is buggy in Firefox4 and can crash the page in Chrome5.
I'd like to be able to use more than just divs and sections, but I'm not clear on what elements I can actually safely make contenteditable. By safely, I mean that using the element under normal conditions, I should be able to perform normal editing tasks without it doing unexpected or buggy things. I should be able to write in it, delete content, cut, copy, paste, and move my text cursor about and highlight text without unexpected or strange behaviour.
So, which elements can I really make contenteditable safely? Is there a specific category? Are there certain criteria the safely-contenteditable element must match?
Bug notes:
Firefox 21 w/ span: Element loses focus if the text cursor is brought to the beginning or end of the element, but not if it got there by deleting content. Highlighting part of the element, cutting and then pasting will split the element in two at that point then insert a blank element between the two parts - without actually putting the text you were trying to paste anywhere.
Chrome 27 w/ span: If the span covers multiple lines e.g. by being wordwrapped, cutting and pasting content will often insert a linebreak after the pasted content.
Unless you make the div display:inline, in which case it can still lose focus as in 1, but apparently only if you bring the text cursor to the end. I don't consider this "normal" usage of the element though.
Firefox 21 w/ heading: Selecting part of the content then cutting and pasting will, similarly to 1, split the heading element in half at that point, and insert a third heading element between the two halves. It will, at least, have your pasted content inside it, but now you have three heading elements where there was originally one.
Chrome 27 w/ heading: Select some content and cut and paste. The page crashes. You get an "Aw snap!" message. That's it.
Demo code
Here's a demo for reproducing the above. It's pretty simple, though at the moment the only thing it isn't reproducing is the lose-focus bug.
[contenteditable=true] {
border: 1px dotted #999;
}
<article style="width: 100px">
<h1 contenteditable="true">Heading</h1>
<p>
<strong>Some adjacent content</strong>
<span contenteditable="true">Span! This is long enough it will spread over multiple lines.</span>
</p>
<div style="display: inline" contenteditable="true">An inline div also with multiple lines.</div>
</article>
In my opinion, I'd say div is the safest bet across the board. Any element you wish to truly edit (be it a span, header, etc), you can place inside the div and edit as if it were just that element. Also, to account for the display:inline issue you mentioned, you could always use float:left or float:right on your editable div to give it an "inline feel" without having it actually be inline.
Hope that helps!
Since this is an evolving feature with, apparent, low priority from the browser vendors support has been sketchy and regressions not uncommon. The current state of affairs is evolving, so check the Googles, CanIUse etc and make sure support is there for your sites visitors, everything else is moot ...
Support in Firefox seems to be solid, at least for some elements, now https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Editable_content
It works well in Chrome as well as far as my testing goes.
And CanIUse looks good: http://caniuse.com/#feat=contenteditable
There are a number of different bugs related to the feature in the different browsers though, but for simple use cases it should be ok now, as of August 2016.
It seems that all fonts have some sort of embedded padding or margin. By setting:
margin: 0px;
padding: 0px;
You never get what you want. Does anybody know why this is?
It sounds like the issue you are having is not with the CSS but the font itself. Most fonts define a baseline, x-height and line-height out-of-the-box. Your specific issue is likely with the font's leading, the space between lines. Sometimes these values can be wildly inconsistent. If you are really trying to get a specific font to line up correctly, I would recommend taking a look at FontLab and editing the glyphs/baseline/line-height for the specific font you are working with.
You can also look at a web-safe version of the font. These types of fonts usually have been specifically spaced to render best on the web. This isn't always the case, but it might get you the results you are looking for. Check out Google's library of web fonts here.
Update
This answer has received enough attention that I decided to add the first comment below to the answer and expound on it.
Browser Reset: Every browser will set default states for many of the reserved HTML tags like a and strong. There are other things defined by default including fonts, line-heights, weights and sizes. This could have an affect on the rendering of a font. Generally this is localized to specific browsers. So, by using a CSS reset, you can eliminate default rendering issues in browsers. Eric Meyers Reset is a good reset, but there are definitely others. Try using different ones to see which works best for you.
However, CSS resets work by targeting all browsers and setting them to all be the same. Some people prefer to use something that, instead, targets only the issues with each browser. That is were Normalize will be better.
There are also issues that a CSS reset will not fix. Such as font aliasing (making the fonts seem smooth rather than jagged). Since some browsers and operating systems do not add anti-aliasing to fonts, you will also see glyph width differences. This, unfortunately, is unavoidable in most cases. Some people go the route of using a flash font replacement tool like Cufon or Sifr. This too has it's own list of issues (such as the FOUC).
Another Update
One other issue that is still out there is the problem with kerning, or the space between glyphs. There is a CSS property letter-spacing that will allow you to do a global kern on a block of text, but it lacks the ability to target individual glyphs like Photoshop or InDesign. The kerning is also based on whole-pixels, so you are limited by what you can achieve. It also has issues with IE and is not as reliable as one would hope. There is a javascript called kerningjs that is pretty decent but it, too, is whole-pixel based and therefore not as accurate as rasterized text.
On the whole, fonts on the web have gotten better over the past few years. Sadly, we are still dealing with issues from the past, when fonts were only intended to be printed or rasterized. There is hope on the horizon for us font enthusiasts, though. As #allcaps said, the CSS3 specification for linebox is out there, so it's only a matter of time until it is widely accepted!
The reasons of this pecularity of the computer fonts are mostly historical. In the past, fonts were the sets of small metal blocks with one character on each, and the height of these blocks had to be enough to contain all the elements of any character, including descendants, ascendants and diacritical marks. The typographic tradition has defined the font size as the height of such metal blocks. That's why almost all actual characters are usually much smaller visually than the font size set for the text and there is some white space above and below them.
Here is a good article explaining the historical roots of the main typographic measurements: http://www.dev-archive.net/articles/typograph1-en.html#Ch22
x ov gjqpy bdfhklt CAPS ÂÊÁËÈ
A glyph is designed on a two dimensional canvas. For the latin writing system the height of this canvas is consistent and width may vary. Glyphs are placed on a baseline. x is on the baseline and the top of x defines x-height. Round and pointy shapes appear smaller so are optically corrected. Descenders extend below the baseline. Ascenders, capitals go above x-height. Browsers align text with different fonts (in the same paragraph) by baseline.
So why is the build in margin? Glyphs need whitespace around to be aligned to each other.
What can we do to influence these margins?
Choose your fonts wisely.
Specify line-height p { line-height:0.5EM;}.
Baseline shift .shift { top:-.5em; position:relative; }
And wait for CSS3 module: line.
General advice: do not adjust a font yourself unless you are absolutely sure what you are doing. One of the many things you'll encounter is hinting. Windows needs hinted fonts and hinting is hard to get right. Also the way fonts are loaded (#font-face) will load a local copy if it exists. You can disable local fonts by a hack. Your mileage may vary.
you can use line-height and letter-spacing padding/margin in fonts...
otherwise use custom css for each heading........
/*use line-height*/
.font{
line-height: 1px;
letter-spacing: 1px;
}
or use custom css......
h1{margin:1px 0;}
h2{margin:1px 0;}
h3{margin:1px 0;}
h4{margin:1px 0;}
using these css before use reset css .......
The "padding" at the top and bottom of fonts is essentially reserved space for diacritics (https://en.wikipedia.org/wiki/Diacritic). Some scripts stack multiple diacritics on some letters, including capitals (for example, Vietnamese https://en.wikipedia.org/wiki/Vietnamese_alphabet) so a font designer that forgets to reserve some place for them won't be able to extend his font later. Also, horizontal scripts require some separation (leading) between lines to be readable.
Only very specific glyphs like box drawing elements extend to the limits of a glyph box
http://www.unicode.org/charts/PDF/U2500.pdf
That's also why the "padding" is built-in each glyph. If it was an external property it would not be possible to differentiate between glyphs intended to be jointive and glyphs that need some separation (in other words the amount of padding is a glyph property no a whole-font property).
The following example requires a good font with decent Unicode coverage (http://dejavu-fonts.org/ works)
Jointive box drawing elements
↓
┃ÇŖŞ
┃ẤỄǛȰ┃U ← You really need to include the "padding" to align with box drawings
↑
Latin capitals with multiple diacritics (really crowded)
Lastly fonts stem from very old technology (movable type), and the conventions used to describe them still refer to fifteenth century habits, which makes them quite un-obvious to laymen.
(See also http://www.webfonts.info/node/330 for info on complications added by computer font formats)
fonts opentype text-rendering
If you want use space between lines in a paragraph, you can use:
line-height: 3px; /*3px is an example*/
Or, if you use space between letters, you can use:
letter-spacing: -2px;
Its not a problem with the font as such. Yes, as #matthew said, the font design itself has some character built in. For example, check out difference between say "Segoe" family and "Verdana" family. You will keep on resetting your css if you need to use both. One style just won't work.
The larger part of the problem lies in the way different browsers render even on the same OS. Heck, even different versions of IE render differently. ClearType, Anti-aliasing, font smoothing, software rendering instead of GPU rendering, rendering engine itself, etc. etc. all play their role to make sure you don't end up with pixel-perfect design across all browsers across all OSs.
ClearType tries to align with pixel-grid causing another set of problems with subtle differences in height.
This link is very old, but still very relevant: http://www.joelonsoftware.com/items/2007/06/12.html
See Also: http://www.codinghorror.com/blog/2007/06/whats-wrong-with-apples-font-rendering.html
See Also: https://webmasters.stackexchange.com/questions/9972/how-can-i-make-fonts-render-the-same-way-across-different-web-browsers
See Also: CSS font differences between browsers
Your best bet would be to keep tinkering with css until you get close enough.
The native margins for text elements are as follows (at least in Firefox and Chrome):
Working Example
p{margin:16px 0;}
h1{margin:21px 0;}
h2{margin:19px 0;}
h3{margin:18px 0;}
h4{margin:21px 0;}
h5{margin:22px 0;}
h5{margin:24px 0;}
To remove them you'll have to re-set the margin like so:
p, h1, h2, h3, h4, h5, h6{margin:0;}
After looking at the html source of a html document found out that after the normal margin/padding added by all the browsers, chrome by default adds its own webkit's margin/padding properties.
-webkit-margin-before: 1em;
-webkit-margin-after: 1em;
-webkit-margin-start: 0px;
-webkit-margin-end: 0px;
Solution is instead of normal
*{
margin:0;
padding:0;
}
Append the style with
*{
margin:0;
padding:0;
-webkit-margin-before:0;
-webkit-margin-after:0;
}
As -webkit-margin-start and -webkit-margin-end are already set to 0px, there is no use of setting them in here.
Tell me if that works! :)
I think is kerning what you intend to describe
take a look to this library
http://kerningjs.com/
CSS, meet kerning. Kerning, meet CSS. Kern, style, transform, and
scale your web type with real CSS rules, automatically.
Print designers have had it easy for way too long. This is 2012; the
web has been around for over two decades, yet web designers don’t get
full control over their typography? Forget that, use Kerning.js!
it's free
The fonts itself has problems it seems. CSS can be used as shown above to solve the problem but still it should be said that it is better in your scenario to fix up the font files itself.
Check out this page as it will give you better insight on how to edit a font:
http://mashable.com/2011/11/17/free-font-creation-tools/
Here is my Opinion
The margin is the distance from each side to the neighboring element and the margin property can be set for the top, left, right and bottom of an element
padding is the distance between the border of an HTML element and the content within it.
But in your case you dont really need these both you , as you are interested in font spacing , there is one css property called letter-spacing
The letter-spacing property increases or decreases the space between characters in a text
Try
h2 {letter-spacing:-3px}
The letter-spacing property is supported in all major browsers.
Note: The value "inherit" is not supported in IE7 and earlier. IE8 requires a !DOCTYPE. IE9 supports "inherit".
I often run into the same issue, especially when trying to get text to top-align with something beside it that isn't text, such as an image.
Here's a technique I've had some success with. Select a portion of the text so that a colored background appears behind it. The top of the selection highlight will reveal what the font considers the "top" and "bottom" of the letter. Take screenshots of the font at various sizes and across multiple browsers. Zoom in on the screen capture in Photoshop and count the number of pixels from what you believe "should" be the top and the actual top. Calculate the percentage that number of pixels represents within the entire selection height.
Then set a negative top margin on the text in ems that is equal to the percentage of the "overflow." So if the text should be 10px tall and it's actually 12px tall, then give it a negative top margin of -0.2em.
Then wherever you assign the font-family that's causing the problem, also include this negative top margin as well. You can use the same technique for bottom and side overflow as well, but I typically find it's the top that causes the biggest headaches.
What's about resetting the margin and padding value to zero in all
*{
margin: 0;
padding: 0;
}
I have run into this pain a couple of times when using some webfonts for icons and gained better control by placing them in an absolute positioned container.
HTML
<div class="relative">
<div class="webfont">✔</div>
</div>
CSS
.relative { position:relative; }
.webfont { position: absolute;
top: -5px;
left: -5px; /* easier control with these values */
}
This felt like a better way to control things cross browser, rather than say, using positive/negative margins and paddings.
Giving the text block a container and class we have much more cleaner ability to tweak it's position cross browser. ( IMO ).
Might be something there.
Cheers,
Rob
You can do it with line-height
I know it's not too common in HTML5, and is more HTML4.1, but...
<font style="line-height: 5px;">
and if it's really that important:
<font style="padding: 5px;">L</font>
<font style="padding: 5px;">o/font>
<font style="padding: 5px;">r</font>
<font style="padding: 5px;">e</font>
<font style="padding: 5px;">m</font>
I'm remaking an old website with html and CSS, having never made a website with "old-style" mark-up I have no idea what the size=+x relates to in CSS, is it pixels or what? Is there a way of replicating this in css or do i have to specify the size exactly?
In short, how do i add x pixels to something i dont know the size of?
For my particular example here is the mark-up:
<H1 ALIGN=CENTER>
<B><FONT color="red" SIZE=+4>PHONE BOOK</FONT></B>
</H1></CENTER>
This dirty old value is equivalent to this css
.item{
font-size: xxx-large;
}
That's if you view it in webkit.
In firefox, it's about 48px.
Here's the old plus and minus tags in action
Here's the W3C's details of the modern equivalents
The old font sizes are set relative to the browsers current default font-size.
It's not the sort of thing you want to leave up to chance, if you want your site to look how it was designed.
Want my opinion, dump it, and use a value of em or px instead.
For the good of your sanity, don't sweat too much over matching these crummy old values, do it by sight, or if you're really worried, do pixel comparisons of screen-grabs.
in short the tag has 7 sizes for text: 1-7.
the default was always 3 when used size=+1 it means make it a size larger than 3 (same as size=4).
it was used so different web browsers will show the page correctlly (their sizes are apparentlly different size 3 on explorer wasnt the same on firefox etc)
in css just define a font and a decent letter size and be done with it.
for further reading: http://www.jonstorm.com/html/font.htm
Much of this depends on the base font size used on the page, as well as how those font sizes are defined in the stylesheet. The best way to determine the actual size use to use Firebug. Inspect the element and open the "Computed" tab of the right. It will tell you the font size in pixels.
For an iPhone ebook application I need to break arbitrarily long HTML documents up into pages which fit exactly on one screen. If I simply use UIWebView for this, the bottom-most lines tend to get displayed only partly: the rest disappears off the edge of the view.
So I assume I would need to know how many complete lines (or characters) would be displayed by the UIWebView, given the source HTML, and then feed it exactly the right amount of data. This probably involves lots of calculation, and the user also needs to be able to change fonts and sizes.
I have no idea if this is even possible, although apps like Stanza take HTML (epub) files and paginate them nicely. It's a long time since I looked at JavaScript, would that be an option worth looking at?
Any suggestions very much appreciated!
update
So I've hit upon a possible solution, using JavaScript to annotate the DOM-tree with sizes and positions of each element. It should then be possible to restructure the tree (using built-in XSLT or JavaScript), cutting it up in pages which fit exactly on the screen.
Remaining problem here is that this always breaks the page on paragraph-boundaries, since there is no access to the text at a lower level than the P-element. Perhaps this can be remedied by parsing the text into words, encapsulating each word in a SPAN-tag, repeating the measurement procedure above, and then only displaying the SPAN elements that fit onto the screen, inserting the remaining ones at the front of the next page.
All this sounds rather complicated. Am I talking any sense? Is there a simpler way?
You should look at the PagedMedia CSS module: http://www.w3.org/TR/css3-page/
CSS3 also support multicolumn layouts (google for "css3-multicol". I don't have enough Karma to include a second link here :-)
About your update: how about doing the layout of one single page, then use a DIV with overflow:hidden for the text part. Next thing would be to overlay a transparent item on top of that, that would programmatically scroll the inner content of the DIV PAGE_HEIGHT pixels up or down according to some navigation controls (or gestures).
The other option is to have a parent <div> with multiple css3 columns: link1, link2.
This works on Android:
<style type='text/css'>
div {
width: 1024px; // calculated
-webkit-column-gap: 0px;
-webkit-column-width: 320px; // calculated
}
p {
text-align: justify;
padding:10px;
}
</style>
The CSS multicol suggestions are very interesting! However, and I hope it's ok to respond with another question: how would you go from splitting one or more long <p> elements into columns to having one particular of these columns being rendered in a WebView? The DOM hasn't changed, so you can't pick out an element and render it. What am I missing?