It seems Chrome is wrapping an inline-block element if it is at the end of a line even if there is a white-space:pre container around it with overflow: auto. Is there a workable solution to prevent this from happening without changing the content?
<div style="width:400px;height:200px;overflow:auto;white-space:pre">
The span should be at the end of this text, however, it wraps to the next line.<span style="width:1px;display:inline-block;height:1em;background:red"></span>
</div>
The white-space must be preserved using newlines at least. Spaces and tabs may be compressed.
This bug is 4 years old and still present in the latest Chrome and Safari, but I did find a workaround that doesn't add undesirable whitespace, which is to add an empty :after pseudo-element: http://jsbin.com/oQuBAmIJ/1/edit
Try changing your white-space setting to white-space: nowrap instead.
Related
We're having some trouble displaying the latin small letter a with caron (ǎ or U+01CE) correctly in Windows 10 - Chrome with font-family Verana. It displays the caron next to the letter 'a'. Other fonts display it correctly.
It works fine in Firefox and IE (under Windows/Linux/macOS) with Verdana.
Also Chrome in Linux/macOS displays it perfectly. The combination Windows + Chrome + Verdana seems to be the only one having difficulty.
For example, check Graphemica a with caron and put the font-family of the example letter on
font-family: Verdana
If you have Windows it will display the caron not above, but next to the letter 'a'.
Does anybody have an idea how we can fix this for Windows Chrome users?
Other letters with a caron, for example: č (U+010D) works fine.
Does anybody have a suggestion how we can let this 'ǎ' work in Chrome - Windows - Verdana, without changing the font?
Thanks in advance.
It doesn't display correctly because U+01CE is not present in Verdana. The components (a, caron) are both present, but there is no character (nor any OpenType layout rules) that combine them into U+01CE form. When you see it "working" in other browsers, it's likely because it's substituting with a fallback font whose design is similar to Verdana (or it's at a small text size where you can't see the difference).
More about Verdana here: https://learn.microsoft.com/en-us/typography/font-list/verdana, have a look at the "Code pages" section. None of the listed pages contains U+01CE, so the font simply doesn't support that character. The other characters you mention are in Verdana.
To work around, you could use some simple CSS to set up a fallback for that specific unicode, for example something like this:
#font-face {
font-family: "fallbackfont";
src: local('Tahoma');
unicode-range: U+0100-01FF;
}
<p style='font-family: fallbackfont, Verdana; font-size:72px'>a ǎ</p>
NOTE: I chose local 'Tahoma' for a fallback here because its design is more similar to Verdana than others. And it is selected for use for the entire Unicode range of U+0100-01FF. But you could (probably should) use a webfont or other local/"web-safe" font of your choosing. Also, you could set the unicode-range for just the one character if you're sure that's the only one not displaying correctly for your text.
I have this snippet in my reStructuredText document:
1. Find the file at ``~/Google Drive/code/mac/install.sh``.
Notice the code/quote environment. Notice the space between Google and Drive in the path.
When rendered with Sphinx in HTML, there is a line-wrap between Google and Drive, and the space is gone. (Since this is documentation, I need everything in the code environment to appear to the user exactly as it is entered, which includes the space between 'Google' and 'Drive'. Not only should a space be present, but it should be shaded grey just like all the other code in the code environment)
How do I tell reStructuredText to use a non-breaking space in that location?
It works for me if the regular space character is replaced with a non-breaking space (U+00A0) in the reST file. That will produce a single <span> element containing Google Drive in the output:
<span class="pre">~/Google Drive/code/mac/install.sh</span>
Inserting a literal non-breaking space can be done in several ways. See https://en.wikipedia.org/wiki/Non-breaking_space#Keyboard_entry_methods.
Put some css in a file _static/custom.css at top repertory in your project
code.docutils.literal {
white-space : pre;
}
(I don't know how from CSS allow breaks say at slashes but not at spaces).
For the approach you can do this:
1. Find the file in our Google Drive folder It is located at
``~/Google`` |_| ``Drive/Quisquam/code/repo/latest/application-bundles/mac/install.sh``.
.. |_| unicode:: 0x00A0
:trim:
Edit: much better than second approach is as pointed in comment to use a NO-BREAK SPACE in the reST source. Then the HTML will use , and the URL will still wrap at slashes contrarily to first approach above which makes it really unwrapping (in my brief investigation).
I had used second approach in other context (also targeting LaTeX output) to insert Unicode+202F, and it had slipped out my mind that for Unicode+00A0, one only has to use it directly in reST source.
The fix for me was to add the following css to the custom.css and make background-color match the pre background-color
tt,
code {
color: #839496;
background-color: #073642;
}
I was developing MVC3 application. In my Application, there will be a number of Chinese and Japanese characters. When showing those characters on the webpage I was getting some weird characters appears on the screen instead of Chinese or Japanese characters. Can anyone tell me how can i show above mentioned language characters without any issue on the page.
I have Tried the below way
font-family: Arial Unicode MS, Arial, Helvetica, sans-serif; // But this way didn't help me out.
Thanks
If you're using ISO character sets, you need to use the right one for these languages
Character Sets
Or you can just simply set character set to UTF-8 and not worry about the language on the page it self. If you're still seeing weird characters, might be that you somehow overwrite the encoding, or perhaps have a malformed HTML code.
Cheers,
Deadpool
I'm using Prettify (from Google Code - https://code.google.com/p/google-code-prettify/). When one adds the linenums attribute then it renders the program using alternating background colors on each line (i.e., it uses "stripes" or "piano keys"). When one removes that attribute Prettify no longer stripes the lines.
Is it possible to get Prettify to stripe source code WITHOUT also adding line numbers?
If you look at the themes gallery you'll see that this is affected by the stylesheet, and that there are some with line numbers on every line.
Something like
<style>li.L4, li.L9 { list-style-type: none }</style>
should do it.
The operative part of the default stylesheet is
li.L0,
li.L1,
li.L2,
li.L3,
li.L5,
li.L6,
li.L7,
li.L8 { list-style-type: none }
which turns off list bulleting for all items with index i where (i % 10) ∉ (4,9), hence the li.L4, li.L9 selector fills the gaps.
Answer is yes. Mike Samuel's answer seems to misinterpret or ignore the question.
The "piano keys" striping of code (not line numbers) occurs with every other line of text having an alternating background color whenever line numbers are requested. I wanted to turn it off when showing line numbers, but the original questioner wanted to know how to turn it on (like for an Excel spreadsheet) but without showing line numbers. Neither question, however, would seem to have anything to do with the line numbers or the li style directly, hence the confusion.
To fix this, a background-color property can be added; this overrides the striping colors of the numbered prettify commands and allows custom stripes.
An answer to both my problem and the original was eventually found. A style was added to override the current prettify code such as the following. You must still specify linenums in the prettify class but none will be shown:
highlight every 5th line no nums:
<style>
li.L0,li.L1,li.L2,li.L3,li.L5,li.L6,li.L7,li.L8
{ background:#000022 !important; list-style-type:none !important}
li.L4,li.L9
{ background:#080833 !important; list-style-type:none !important}
</style>
highlight every 5th line with nums:
<style>
li.L0,li.L1,li.L2,li.L3,li.L5,li.L6,li.L7,li.L8
{ background:#000022 !important; list-style-type:decimal !important}
li.L4,li.L9
{ background:#080833 !important; list-style-type:decimal !important}
</style>
Important: there is no comma before the curly bracket. If you insert such
a comma the style will fail!
Does anyone know what is wrong with this rule?
#media screen and (-webkit-min-device-pixel-ratio:0) {
#nav-main li.c_course div{margin-left:1px !important;}
#nav-main li.c_course div{margin-left:1px !important;| margin-right:0px !important;;}
#nav-main li.c_course div div{margin-left:0px !important;}
#media screen and (-webkit-min-device-pixel-ratio:0) {
#nav-main li.c_course div{margin-left:1px !important;}
}
I researched it at media syntax possible combinations. It seems to be valid code (judging by the post even though the 7.3 Recognized media types spec doesn't list the syntax the way the OP does).
Is it supposed to be positioned somewhere else in the .css or what?
Thanks
Using the code:
#media screen and (-webkit-min-device-pixel-ratio:0)
Is a way to target just webkit browsers as it matches a webkit browser with a minimum pixel ratio of zero which in affect is every webkit browser. The issue is that the webkit prefix won't validate against W3C standards as it's vendor specific - it should be used as a last resort and if you don't mind the CSS failing validation.
Here's some info www.w3.org/TR/css3-mediaqueries/#device-aspect-ratio.
It appears the rule should be written as
#media screen and (min-device-aspect-ratio:0){ ... }
Thing is, I don't know if "0" is a valid value. The spec uses a ratio and I don't know what the coder meant by using "0". "0" means nothing anyway---so the statement seems meaningless. www.w3.org/TR/css3-mediaqueries