I recently started using bootstrap SCSS on my node project. So I have app/bower_components/bootstrap-sass/lib/_glyphicons.scss
for example.
Looking at my CSS output I see things like:
@media -sass-debug-info{filename{font-family:file\:\/\/\/home\/some\/path\/project\/app\/bower_components\/bootstrap-sass\/lib\/_normalize\.scss}line{font-family:\0000332}}
audio,
canvas,
video {
display: inline-block;
}
I have 2 questions:
- This seems like a security hole. Everyone can deduce something about my OS and directory structure simply by looking at my CSS. What is the correct way to close this security hole?
- How does it work? I nearly got it figured out, but I am missing something. Looking at the SCSS, I see bootstrap is using
$icon-font-path
which apparently turns into this absolute path. Looking at compass documentation, I see they provide absolute values but no$icon-font-path
This is the piece of code I am referring to:
@font-face {
font-family: 'Glyphicons Halflings';
src: url('#{$icon-font-path}#{$icon-font-name}.eot');
src: url('#{$icon-font-path}#{$icon-font-name}.eot?#iefix') format('embedded-opentype'),
url('#{$icon-font-path}#{$icon-font-name}.woff') format('woff'),
url('#{$icon-font-path}#{$icon-font-name}.ttf') format('truetype'),
url('#{$icon-font-path}#{$icon-font-name}.svg#glyphicons-halflingsregular') format('svg');
}
The -sass-debug-info
mess is rudimentary "source mapping", so browser developer tools can show you the original line number and filename of the Sass rule that generated that CSS (instead of the line number for the generated CSS).
Firebug has a FireSass plugin that understands these annotations. I think Chrome has built-in support, but it might be behind an experimental flag.
It has nothing to do with fonts; font-family
is just used because it's an easy way to shove a string into CSS in a way that's still accessible to JavaScript without actually affecting the rendering of the document. It also has nothing to do with Bootstrap; this is part of the scss
compiler.
It won't be there in compressed output, which I hope you're using in production. :)
Both answers are correct. To sum it up, there's no magic
.
Bootstrap initializes $icon-font-path
with a default value.
if you include
bootstrap's SCSS
in a manager that requires a different value for $icon-font-path
you should also override their default value.
The syntax $icon-font-path: some_value !default;
means - use this value if not already set.
So when you include you should do the following
/* override icon-font-path value and include scss */
$icon-font-path: bower_components/bootstrap/fonts;
@include bower_components/bootstrap/bootstrap.scss;
paths might be different in real scenarios.
This seems to be a standard mechanism for publishing a reusable SCSS modules.
Here is the variables file where they set the $icon-font-path
variable.
It looks like $icon-font-path
is set to the foldername of the font files. not necessarily a security hole because its a relative path to the fonts.
@guy mograbi: In Bootstrap-SASS-3.3.6, $icon-font-path in /bootstrap/bootstrap/_variables.scss @83
is declared like this:
$icon-font-path: if($bootstrap-sass-asset-helper, "bootstrap/", "../fonts/bootstrap/") !default;
Since $bootstrap-sass-asset-helper is not defined yet, it may be useful to include the _variables.scss before overwriting the $icon-include-path, so we can read the "settings" and overwrite the $icon-font-path together with the if() cases.
We can use something like:
@include bower_components/bootstrap/bootstrap/_variables.scss;
$icon-font-path: if($bootstrap-sass-asset-helper, "bootstrap/", "/fonts/bootstrap/");
@include bower_components/bootstrap/bootstrap.scss;
来源:https://stackoverflow.com/questions/19446845/how-does-icon-font-path-works-in-bootstrap-scss