怎样更好地操纵input键入框的高宽比

日期:2021-01-20 类型:科技新闻 

关键词:html网页制作,php网页制作,网页设计稿,网页编辑工具,学生网页设计模板

很久之前 Roger Johansson 就在他的 blog 上做了1个 用款式操纵表模块素 的检测 , 告知大家妄图用款式操纵表模块素是1件不能能的事儿using CSS to style form controls to look exactly the same across browsers and platforms is impossible
乃至 css2.1 标准中也沒有确立这层面的要求 , 而是准备将它 fix in future
CSS 2 . 1 does not define which properties apply to form controls and frames, or how CSS can be used to style them. User agents may apply CSS properties to these elements. Authors are recommended to treat such support as experimental. A future level of CSS may specify this further.
因此假如要想让表模块素在各个访问器下彻底1致 , 最好是的处理方式莫过度彻底没理会实际操作系统软件的款式 , 用自定的 ui 设计风格 , 就像 bing 或 Google 的 Jazz UI 那样

但是 , 这会致使页面和客户的系统软件背道而驰 , 现阶段 google 关键還是对于访问器做了些独特解决 , 如 webkit 下用 gradient 使得按钮看上去好些

mac 下 webkit 的按钮不太好操纵

本文凑合键入框高宽比的难题开展调查 , 找寻更好的处理方式
键入框高宽比
最先 , 这个调查的1个关键缘故是 , 检索結果页准备进到规范方式 , 这会致使盒实体模型的转变 , 导致键入框高宽比和原先不1样 , 因此以便和网上实际效果维持1致 , 大家必须寻找1个最好的处理计划方案
有同学将会会不解 , 有那末难么 ? 设定1个 height 不就处理了么 ?
<input type= "text" style= "height:28px" />
但是 , 经检测发现这里边的细节难题還是还挺多 , 因为資源比较有限 , 这里只检测了关键的访问器友谊台 , 包含现阶段关键用到的 5 个访问器
·         IE6(xp)
·         IE7(xp)
·         IE8(win7)
·         Firefox 3.5(xp)
·         Firefox 3.5(win7)
·         Firefox 3.5(mac 10.6.2)
·         Firefox 3.5(ubuntu 10.4)
·         Chrome 5(xp)
·         Chrome 5(win7)
·         Chrome 5(mac 10.6.2)
·         Chrome 5(ubuntu 10.4)
根据设置 height 的方法
大家的总体目标是和现阶段检索框尺寸维持1致 , 既 28px
最先检测的是最简易的 height, 先看现阶段网上的计划方案 ( 简易起见就立即写到 style 中了 )
<input type= "text" style= "font: 16px arial; height: 1.78em; padding-top:2px" />
从款式上推导 , 因为盒实体模型难题 , 在 IE 下的尺寸将是 1.78 * 16 = 28px, 而 Firefox 等访问器应当是 1.78 * 16 + 2px + border-width * 2 = 30 + ? px
检测結果是
访问器
height + padding-top + padding-bottom + border-top-width + border-bottom-width
IE6(xp)
21 + 2 + 1 + 2 + 2 = 28
IE7(xp)
21 + 2 + 1 + 2 + 2 = 28
IE8(win7)
21 + 2 + 1 + 2 + 2 = 28
Firefox 3.5(xp)
21 + 2 + 1 + 2 + 2 = 28
Firefox 3.5(win7)
23 + 2 + 1 + 1 + 1 = 28
Firefox 3.5(mac 10.6.2)
19 + 2 + 1 + 3 + 3 = 28
Firefox 3.5(ubuntu 10.04)
19 + 2 + 1 + 3 + 3 = 28
Chrome 5(xp)
21 + 2 + 1 + 2 + 2 = 28
Chrome 5(win7)
21 + 2 + 1 + 2 + 2 = 28
Chrome 5(mac 10.6.2)
21 + 2 + 1 + 2 + 2 = 28
Chrome 5(ubuntu 10.04)
21 + 2 + 1 + 2 + 2 = 28
实际效果非常理想化 , 全部访问器全是 28px, 来看即便是 Firefox 和 Chrom 在 quirks 方式下的 input 都沒有遵照盒实体模型 , 因此网上的键入框高宽比在各个访问器下很完善地维持1致
但是假如是在 standards 方式下 , 結果则是
访问器
height + padding-top + padding-bottom + border-top-width + border-bottom-width
IE6(xp)
28 + 2 + 1 + 2 + 2 = 35
IE7(xp)
28 + 2 + 1 + 2 + 2 = 35
IE8(win7)
28 + 2 + 1 + 2 + 2 = 35
Firefox 3.5(xp)
28 + 2 + 1 + 2 + 2 = 35
Firefox 3.5(win7)
28 + 2 + 1 + 1 + 1 = 32
Firefox 3.5(mac 10.6.2)
28 + 2 + 1 + 3 + 3 = 37
Firefox 3.5(ubuntu 10.04)
28 + 2 + 1 + 3 + 3 = 37
Chrome 5(xp)
28 + 2 + 1 + 2 + 2 = 35
Chrome 5(win7)
28 + 2 + 1 + 2 + 2 = 35
Chrome 5(mac 10.6.2)
28 + 2 + 1 + 2 + 2 = 35
Chrome 5(ubuntu 10.04)
28 + 2 + 1 + 2 + 2 = 35
就仅仅加了1句 <!DOCTYPE html> , 却致使访问器差别变得这般大 , 细心观查发现 , 关键难题在 Firefox 上 它的 border 在 win7 下是 1 像素 , xp 下是 2 像素 , mac 下是 3 像素 , 让人很头疼 , 因而准备换1种计划方案试试
padding 的方法
因为 Firefox 的 border 难题 , 设置 height 是不能能确保高宽比1致的 , 除非分辨再去分辨实际操作系统软件种类 , 但那样做太不便了 , 并且说不确定 mobile 版又不1样
那是不是能够堵塞过设定 height 来操纵 ? 在现阶段的大检索主页也是 standards 方式 , 它是选用 padding 的方法来完成 28px 的高宽比的
<input type= "text" style= "font: 16px arial; padding:3px" />
这类写法的检测結果是
访问器
height + padding-top + padding-bottom + border-top-width + border-bottom-width
IE6(xp)
18 + 3 + 3 + 2 + 2 = 28
IE7(xp)
18 + 3 + 3 + 2 + 2 = 28
IE8(win7)
18 + 3 + 3 + 2 + 2 = 28
Firefox 3.5(xp)
19 + 3 + 3 + 2 + 2 = 29
Firefox 3.5(win7)
19 + 3 + 3 + 1 + 1 = 27
Firefox 3.5(mac 10.6.2)
20 + 3 + 3 + 3 + 3 = 32
Firefox 3.5(ubuntu 10.04)
19 + 3 + 3 + 3 + 3 = 31
Chrome 5(xp)
19 + 3 + 3 + 2 + 2 = 29
Chrome 5(win7)
19 + 3 + 3 + 2 + 2 = 29
Chrome 5(mac 10.6.2)
18 + 3 + 3 + 2 + 2 = 28
Chrome 5(ubuntu 10.04)
19 + 3 + 3 + 2 + 2 = 29
在不设置键入框高宽比的状况下 , 访问器会自主特定1个 , 并且都有差别 , mac 上的 Firefox 更是高出了 4 像素 , 但总的来讲 , 实际效果尽管有缺憾 , 但還是能够接纳 , 绝大多数状况下都只差1个像素
但是这类方式带来了许多不确定性性 , 內容区的高宽比是伴随着字体样式尺寸而变的 , 假定 font-size 是 14px, 访问器的高宽比又维持1致了
访问器
height
IE6(xp)
16
IE7(xp)
16
IE8(win7)
16
Firefox 3.5(xp)
16
Firefox 3.5(win7)
16
Firefox 3.5(mac 10.6.2)
16
Firefox 3.5(ubuntu 10.04)
16
Chrome 5(xp)
16
Chrome 5(win7)
16
Chrome 5(mac 10.6.2)
16
Chrome 5(ubuntu 10.04)
16
是不是也有更好的计划方案呢 ?
box-sizing
height 和 padding 都没法完善操纵键入框高宽比 , 而 border 的尺寸又不可以改 , 难道说就真的没法了么 ? 禁不住怀恋 quirks 方式下的便捷 , 设置1个高宽比就完善了 , 如果能既进 standards 方式 , 又能用到旧盒实体模型就行了 , 很当然地就想起了1个几乎没用过的 css 特性 box-sizing, 之前1直没想好这特性究竟能用在哪儿里 , 终究这下派上用处了 , 应用它大家便可以处理 Firefox 下 3 种 border 的差别 , 让 Firefox 自身去算內容区的高宽比
但是因为 IE6/7 不适用这个特性 , 因此必须写 hack, 因为 IE 下的默认设置 border 值是 2, padding 是 1, 因此 height 必须减 6 像素 , 也便是
-moz-box-sizing : border-box ;
-webkit-box-sizing : border-box ;
box-sizing : border-box ;
height : 28px ;
* height : 22px ;
这样 , 就可以确保绝绝大多数的访问器下实际效果1致了 , box-sizing 特性的适用状况以下表所示 , 来自 mozilla 适用的浏览十分广 ,
Browser
Lowest Version
Support of
Internet Explorer
8.0
box-sizing
Firefox (Gecko)
1.0 (1.0)
-moz-box-sizing
Opera
7.0
box-sizing
Safari (WebKit)
3.0 (522)
-webkit-box-sizing
但是 , 事儿都还没完毕 , 刚刚假设了 IE 下默认设置 padding 是 1 像素 , 但是现阶段许多 css reset 都会将 input 的 padding 设为 0, 因而 , IE 下的区别将并不是 6 像素 , 而是 4 像素 , 因此以便防止遭受危害 , 提议将 padding 设为 0
padding-top : 0 ;
padding-bottom : 0 ;
height : 28px ;
* height : 24px ;
访问器在 quirks 下的完成方式
转过头看来 Firefox 和 Chrome 在 quirks 方式下应用了非规范的盒实体模型 , 看模样是成心去做的 , 它是怎样完成的呢 ?
因而在 webkit 源代码中找寻 , 1刚开始认为它是在源代码中对 quirks 下的 input 做了独特解决 , 但没看寻找又甚么非常的地区 , 而在看到测算 box 高宽比的情况下
int RenderBox::calcContentBoxHeight( int height) const
{
    if (style()->boxSizing() == BORDER_BOX)
        height -= (borderTop() + borderBottom() + paddingTop() + paddingBottom());
    return max( 0 , height);
}
突然想起 , 会不容易是根据访问器默认设置款式来完成的呢 ? 将这类独特的逻辑性立即写在编码中的确太恶心想吐了 , 既然适用 box-sizing 特性 , 立即将它写在 quirks 的默认设置款式不就完善处理了么
果真 , 在 Firefox 的 res/quirk.css 中发现了这句
/*
* Quirk: Use border-box box sizing for text inputs, password inputs, and
* textareas.  (b=184478 on why we use content-box sizing in standards mode)
*/
 
/* Note that all other <input>s already use border-box
sizing, so we're ok with this selector */
input :not ([ type = image ]), textarea {
  -moz-box-sizing: border -box;
}
在 webkit 源代码中的 WebCore/css/quirks.css 发现了这句
/* This will apply only to text fields, since all other inputs already use border box sizing */
input :not ([ type = image ]), textarea {
    -webkit-box-sizing: border -box;
}
原先访问器便是这么处理的 , 那末在规范方式下用它将是1种较为好的计划方案
one more thing
但是这类写法在 Firefox 3.5 下列的版本号会有个难题 , 那便是键入框內容将没法竖直垂直居中 , 以英文为例 , 3.5 中合顶部的差别是 5 像素 , 而 3.6 是 7 像素 , 现阶段还想不到处理计划方案

幸亏在 Firefox 3.6 中处理了这个难题 , 并且 3.5 会默认设置升級到 3.6, 因此这个难题也就不必须考虑到了
结果
从这个事例能够痛楚地体验 , 假如沒有统1的标准 , 要适配不一样访问器是这般的艰难 , 并且这还仅仅是1个很不彻底的检测 , 好在访问器還是尽量保证了最大适配 , 例如 , 假定 windows 下默认设置主题和經典主题有差别 , 就代表着全部 windows 下的检测都要乘 2.