If the sass file content is
#some-div
color: #333
font-size: 17px // This value actually has some issue on WebKit because it makes
// the label a little off centered, and is better if it is 16px.
// But on IE, the font turns out to be rather ugly, so we would
// use 17px for now since IE has a larger user base
the above will actually fail, because it will complain the indentation is not correct (starting the second line of comments). How might it be solved to have multiple lines like this? Note: It can be made into all indented the same level as the font-size line (and on top of it), but I'd rather not do it like that in this case.
Sass is very indentation-based. As such, there really is no choice but to either
Combine the comment onto the end of the line, which will be huge and unwieldy.
Move the comment above or below your line.
The documentation for the indentation syntax covers comments in this section.
You might find some of the options useful, for example, you only need to have the first line of the comment with slashes, the rest can be indented, which may be more readable for your purposes.
It would look like this then:
#some-div
color: #333
font-size: 17px
// This value actually has some issue on WebKit because it makes
the label a little off centered, and is better if it is 16px.
But on IE, the font turns out to be rather ugly, so we would
use 17px for now since IE has a larger user base.
SCSS is the preferred syntax to use now as all valid CSS is valid SCSS; it also allows for the type of comments you would like (in addition to quite a few very nifty additions such as using &:hover inside of a selector to group your variations on styles more logically).
Related
I am trying to place an overarrow over a piece of text in MathJax.
I am using a custom font that I declare in the code-
\(\overrightarrow{\style{font-family: mysans, TeX, Arial, sans-serif;}{\text{" + tString + "}}}\)"
It works ok for most letters- for capital W or M , using a couple in a row like "WWW" the overbar is too short.
For lowercase i , using a couple in a row, ie "iii" it is too long. My hunch is that MathJax is using a standard character width size to figure out the length of the overarrow and when the character is much longer or shorter than that size, it calculates the overarrow incorrectly. Is there any way around this?
Thanks!
First off, you generally cannot use custom fonts with MathJax. As the documentation says
Since browsers do not provide APIs to access font metrics, MathJax has to ship with the necessary font data; this font data is generated during development and cannot be generated on the fly. In addition, most fonts do not cover the relevant characters for mathematical layout. Finally, some fonts (e.g. Cambria Math) store important glyphs outside the Unicode range, making them inaccessible to JavaScript.
However, if you are only looking to use custom fonts in text elements, then there is a way to work around this: style the surrounding context and set mtextFontInherit:true for the output jax, cf. e.g. here for HTML-CSS.
Unfortunately, this won't actually help you right now. There's a minor regression in MathJax 2.5 (see this discussion leading to the result you describe). This will be fixed in 2.5.1 and in the mean time you could set noReflows:false for the HTML-CSS output.
If I add too many/too long captions to a vaadin7 timeline, they will only be displayed partially (i.e. the part we have space for is displayed and the remainder is truncated)
How can I increase this area in order to allocate enough space for all?
timeline.setGraphCaption(container, h.toString());
You need to add these rules in your scss file:
.v-timeline-widget .v-timeline-widget-modelegend{
background: inherit;
}
.v-timeline-widget-legend-label{
height: auto !important;
white-space: normal !important;
}
Before:
After
3 points:
While these rules may not met criteria of well-written CSS or good practice rules (I am looking at you !important), they do the trick. Still, better approach would be to get your hand dirty by editing Vaadin Timeline addon sources.
As you surely noticed text background has changed. That's because we override default background which was designed for only one line (you should provide your own background image)
Bottom of the widget is cut off by few pixels. Well, the only way to fix it is to jump into DOM and css and try fix it. Doable but I haven't tried.
I just realized that my entire Rails app was to pale, and would like a quick fix to make all text look, say, 120% darker. My trouble is, my text color values are all over the places. (If I just have a few text color values, then it could have been easier to find and replace all of them).
Is there a way to do this? I am not familiar with less, but I hope there's some quick fix that can help me out.
I believe less is used to make all the css based on rules so it would be just as hard to implement it now as if you were to re-write your css.
For example if you set the base colour as #base: #ccc; then you can set other colours as a % like
div { .box-shadow(0 0 5px, 30%) }
However, this would still force you to go through and replace all your css values with percents and also learn less... Good longterm solution, but not a quick fix.
I am not an expert on rails but if you were to go through all your files with a replace command and replace #fff with #ccc etc?
Since your css is not less (or Sass)-based there is no straightforward way to accomplish this. However, writing a script that would find all color values in css (using a regex) and replace them with darker color (i.e. decreasing all individual color values by some percentage) wouldn't be a hard thing to do.
I have a paragraph tag that I defined elsewhere with a line height of 15px, and I have another paragraph tag further down the page where I want to make the line height around 10px. Funny thing is, it won't let me get down to 10px or anything smaller than that, but when I set it to 25px or higher, the line-height property seems to be working.
I checked the relevant CSS (all hand-coded) via the Chrome browser's web developer tools (Chrome's version of Firefox's Firebug) and couldn't find anything relevant. Is there a common CSS bug that prevents me from shrinking the line-height beyond a certain minimum amount?
I've noticed in both Firefox and Chrome that if you set the HTML5 doctype there's a minimum line-height for inline elements. For block elements you can set the line-height to whatever you want, even make the lines overlap.
If you don't set the HTML5 doctype, there's no minimum line-height for either block or inline elements.
I ran into the same issue, worked well with:
.element { display: block; line-height: 1.2; }
After testing this in IE 8-11, Firefox 38.0.1, and Chrome 43, the behavior is the same: inline elements have a minimum line-height that they won't go below. It appears this minimum height comes from the CSS spec:
On a block container element whose content is composed of inline-level elements, 'line-height' specifies the minimal height of line boxes within the element. The minimum height consists of a minimum height above the baseline and a minimum depth below it, exactly as if each line box starts with a zero-width inline box with the element's font and line height properties. We call that imaginary box a "strut."
If you want to maintain some benefits of inline elements, you can use display: inline-block. You can also use display: block. Both will allow you to make the line-height whatever you want in all the browsers I tested.
Two related questions for more reading:
why the span's line-height is useless
The browser seems to have a minimum line-height on this block that contains text. Why?
line-height is relative to font-size, you can't go any lower than that unless you declare negative margin.
I'd like to use CSS Sprites, but I haven't used it in massive scale before, and seems like when all the images are being displayed using CSS Spirites (image as background), then it must be inside a div or span with display: block so that it can have a width and height?
If so, then isn't it messy that, before, as an <img>, it can flow as an inline element naturally, but now, it has to be floated.
It might be able to be shown as inline-block, but I think it is not well supported by all browsers?
I use this fix for inline-block when spiriting (although I ignore the vendor style for Firefox as modern FF plays nice).
FTA:
display:-moz-inline-stack;
display:inline-block;
zoom:1;
*display:inline;
Note that IE is generally fine as long as the element hasLayout.