Bog*_*gin 11 css fonts frontend svg glyphicons
对于我目前的工作流程,我使用Icomoon生成的标志性网页字体.这是一种非常简单有趣的技术,具有明显的优势:
text-shadow,text-decoration,color等.font-family元素.但它有重大缺陷不让我入睡.
<span class="icon"></span>为此目的使用虚拟空和非语义的正确方法.嗯,显而易见的替代方案是SVG,它没有提到的缺点.但是它有自己的缺点,不容易让我使用它.
我已经搜索了一些npm软件包,由于某些原因我不满意.
所以,我问你的建议如何管理这个简单而常规的任务.是否有生产和可靠的方法来生成SVG精灵与旧浏览器的原始图标和位图后备的修改变体？
Mik*_*ans 14
在没有以下情况下谈论"支持旧浏览器"是没有意义的:
话虽如此,这并不是一个答案,而是解释你所提出的"反对"字体所有这些点是没有根据的.答案很好,但在这种情况下,我们需要直接设置记录,以便您可以根据事实做出真正的决定,而不是("从不"或"不再"有效)先入为主.我花了太多年的时间从工程角度处理字体,让你保持这些声明=)
"无论曲线如何与像素网格对齐,字体图标都很模糊.更不用说糟糕的Windows渲染了."
这显然不是真的.作为矢量图形,如果它们渲染效果不佳,SVG也会在相同的尺寸下渲染效果不佳,尽管SVG通常会渲染得更糟:字体实际上允许用于处理小点尺寸的微轮廓优化(.otf在此处更好. ttf,但是字体制作者需要花时间把它们放进去.几乎所有专业字体都带有完成的工作),而SVG则没有,因为它的矢量图形语言没有指令这样做.因此,字体可以与(如果它们没有优化指令)相提并论,或者比(如果它们更好)SVG更好.
例如,Font-Awesome带有轮廓优化,允许它将像素完美渲染到14px的字体大小,这已经小于浏览器用作页面上文本的默认大小(几乎所有浏览器都同意)使用默认的16px serif).如果您将其图标设置并将其转换为SVG,然后尝试使用按比例缩小以匹配14px大小的图标,它们看起来将是一个绝对模糊的混乱.
或者您可以使用更进一步的图标集,例如明确设计用于网格对齐的符号集,这意味着即使尺寸低于预期,它仍然呈现非常清晰.
SVG输给了这里.
至于Windows渲染,它可能看起来很糟糕,但这不是Windows的错.Uniscribe和DirectWrite都非常擅长渲染字体.就像,非常好(这可能不是一个惊喜,因为桌面出版传统上一直是微软的核心业务,因为它已经开始了,尽管这种情况正在发生变化).连接它们的浏览器可以很好地呈现字体:IE甚至支持自IE4以来的Web字体......那是1997年.那时HTML4之前就是一件事,我们当时仍然在使用HTML3.2.
问题不在于"Windows",因为它是"在Windows上不是IE的旧浏览器".很长一段时间,浏览器并不真正关心网页字体.只是在过去的几年中,主要的努力突然变成了确保它们带有良好的字体整形引擎(如Harfbuzz,现在被Firefox和Chrome使用),除非你是个,否则你不会得到很好的字体结果在Windows机器上使用现代版本的"not-IE".
最后在Windows和IE上出现了"font vs SVG"特有的问题:虽然IE已经支持Web字体,但是SVG支持只停留在IE9中,所以如果你需要支持IE8,你甚至不能使用SVG.对于这个非常具体的目标受众,"字体与SVG"甚至不是一个问题,你必须使用字体.
"很难在字体中添加新的图标,特别是当制作矢量源字体时,不可用甚至丢失."
不,不是,你仍然在使用带有CSS的HTML,所以当我们需要"不是这种字体的字母"时,我们总是这样做:使用font-fallback: font-family: iconfont1, iconfont2, iconetc.
"它需要大量不同的字体版本(woff,eot,ttf)才能获得可接受的跨浏览器支持."
不是几年了.这些天来,我们并不需要多个来源:caniuse告诉我们,一切支持WOFF,并为几个版本这样做.
即使是IE,虽然如果你需要支持IE8,你也必须找到自己.eot(这实际上只是一个ttf带有额外元数据的文件,所以IE会接受它......就像WOFF!)然后生活在事实上,如果这需要从otf到eot的转换,你将最终得到一个糟糕的字体,因为它是一个有损转换(如将.png转换为jpg.优秀的转换软件可以产生一个不错的结果,正常的软件将产生一个平庸的结果).
因为一切都支持WOFF,我们(谢天谢地)不再需要荒谬的无所不包的ttf + otf + eot + woff + svg,还有一个"防弹"的@ font-face规则试图优化加载顺序所以不要太多许多文件被不必要地加载 - 只需使用WOFF.完成.在一个pickle中,添加.eot为第一个源(带格式指示符),除IE之外的所有内容都将跳过它.
它也值得看看SVG字体支持:几乎没有任何支持它,那些正在贬值它的人.SVG字体作为一种东西已经停止使用,因为使用SVG字体的结果比使用真实字体要糟糕得多,强调了第1点的解释.
"最后,字体根本不是用于图形的(特别是不是单色的),似乎不是
<span class="icon"></span>为此目的使用虚拟空和非语义的正确方法."
这两个说法都是不正确的.
字体用于编码将在排版上下文中使用的矢量图形.这可能意味着字母,图标或表情符号; 它甚至可以是音符或麻将牌.他们这样做的方式直到最近一直是"单色",这实际上就是单色.单色渲染字体可能是一个问题的唯一地方是在单色显示器上,在这种情况下:在哪里你的网页被访问,他们可以渲染webfonts,但在古代甚至为CRT技术O_O这样做
至于语义:如果你需要一个在文档中没有任何意义的图标并且纯粹是UI糖果,那么你确实需要一个非语义元素,以便视觉或阅读障碍人士的文本阅读器等不会得到你的图标大声读出来,搜索引擎(私人或公共)的文本索引器可以完全安全地忽略它们.您的图标绝对应该是一个非语义的空元素,可以被所有内容跳过.
总而言之,位图怎么样？
位图绝对赢得低点大小,但是 - 这可能是一个惊喜 - 字体实际上可以包含嵌入的位图,以便它们可以在小点大小渲染实际位图,而不是矢量图形.
当然,只有高级字体才有,但这也是你要检查的东西:你看的图标字体是否带有位图？如果是这样,我们有一个胜利者.如果没有,那么您可能想要使用要使用的图标字体,将图标生成为位图文件,然后在您的站点上使用之前手动清理位图.
这个过程本质上是手动,没有公用程式会为你做这一点,不要搞错了足够的时间,你仍然需要手动解决的事情了,但如果你做沿着这条路走下去,你制作基于一个众所周知的自己的图标字体,在一个点的大小,使图标看起来比字体渲染更好:回馈世界,并把这些位图回字型创作者,让他们可以使用它们来构建出字体的EBLC,EBDT和EBSC表和其他人都喜欢在字体内部使用位图,所以我们不需要做疯狂的CSS精灵渲染.