我记得在 WebKit 中,placeholder=""
文本在输入框和文本区域上的行为发生了一个微妙的功能变化,即文本会保留在原位,直到您开始输入,而不是在空输入框获得焦点时消失。 我想它可能最初是在 iOS 上实现的,但现在稳定的 Chrome 和 Safari 都支持此功能。
我还记得我当时觉得这是一个明智的变化。 当然,占位符不能替代真正的
然而,Jeremy Keith 指出 Markus Earnst 的一些研究 表明保留占位符会导致某些期望失效并引发问题
似乎相当数量的用户在占位符文本仍然可见的情况下,甚至不会尝试开始输入。
当然,这项研究的范围有点有限,但它是有道理的。
Jeremey 提供了以下 CSS 解决方案,如果您希望在基于 WebKit 的浏览器中恢复旧的行为
[placeholder]:focus::-webkit-input-placeholder {
color: transparent;
}
我在这里插一句,提出了一种可能的折中方案,兼具两全之美
[placeholder]:focus::-webkit-input-placeholder {
transition: opacity 0.5s 0.5s ease;
opacity: 0;
}
该过渡中的第二个时间值意味着“等待半秒钟再触发此过渡”。 我怀疑有些人会在点击或使用 Tab 键进入输入框准备输入信息之前,还没有准备好集中注意力到该输入框。 但一旦获得了焦点,他们就开始注意。 如果我们给他们半秒钟让占位符保持可见,再用半秒钟的时间淡出它,这很可能足以让他们理解占位符提示的内容。
事件时间线为:
- 用户点击(或轻触,或使用 Tab 键,或其他方式)输入框
- 他们的目光移到输入框,他们的大脑开始关注它
- 他们理解了占位符提示
- 占位符消失
占位符淡出以及占位符向标签滑动消失的另一种变体的演示
Check out this Pen!
郑重声明,我并不是说这绝对更好。 这里没有硬性的科学依据。 我只是提出了一种在我看来似乎合理的替代 UI 体验。
我们还能探索其他解决方案吗?
在输入框获得焦点时,占位符是否可以采用不同的样式? 比如可以更浅一些的颜色。 类似于“嘿,快看,我快消失了,你可以输入了,但你仍然可以看到我,获取提示”。
这里有一个快速的想法:http://jsfiddle.net/vbkBk/
Hugo,我认为这里的关键点是“似乎相当数量的用户在占位符文本仍然可见的情况下,甚至不会尝试开始输入”,而你的想法可能会让这些用户更加困惑。
Hugo,我喜欢这个想法。 我唯一担心的是,如果颜色太浅,可能会造成潜在的无障碍问题。 普通的占位符本来就对比度低于平均水平。
Edson,与其关注用户行为,不如尝试找出背后的原因。 我敢打赌,他们没有意识到字段处于活动状态,因为没有明显的视觉变化。 使文本变浅可以提供这种变化。
当然,如果原因是他们认为这会保留旧的文本(坦白地说,没有人希望每个搜索字符串都以“搜索”开头),那么这个解决方案可能仍然不起作用。
是的,我同意 Edson 的观点。 而且在测试中,我还观察到“输入犹豫”的行为。 我自己也犹豫过几次,具体取决于占位符中的内容以及它的样式。
另一个选择是将占位符文本向上移动
http://codepen.io/garypaul/pen/DehEk
这样,你就可以把示例移开。 不过,我不确定可用性方面的影响。 我可能会测试一下。
太好了! 我看不出有什么理由不将此作为最佳实践。
我不同意。 主要是因为它不是最佳实践。 你专注于文本字段,而你的提示消失了。 而且没有办法在不离开输入框的情况下恢复它(与删除你输入的内容并重新显示占位符相反)。
而且这个前提很奇怪。 如果我自己输入了几个字符怎么办? 我应该被它们的存在吓住,不再输入了吗?
@Rimantas – 如果你开始输入,占位符无论如何都会消失…?
Hugo,很棒!
关于第二个示例,占位符被吸入光标(将字体大小减小,使过渡看起来像将文本拉入真空,这将是一个很酷但可能过度的效果……),将占位符文本移到输入框的右侧会更有用。 这只是我的一个想法
1. 该示例不会消失。
2. 你不用担心过渡速度过快或让人困惑。
3. 占位符似乎在为你的输入“腾出空间”。
4. 占位符在输入文本时会立即消失,这应该是用户已准备好输入的指示,而不是对占位符消失的时间进行计时,或者推断出用户可能已准备好输入。
我个人最喜欢 Hugo 的解决方案(虽然我一直不喜欢模糊的蓝色边框……)
我第一次使用 HTML5 占位符时,我认为它坏了。 我不明白为什么占位符在文本框获得焦点时不会消失。
我觉得它太糟糕了,所以又回到了使用我们多年来一直使用的 jQuery 插件,该插件在旧版浏览器中也能正常工作。
如何不完全淡出到不透明状态,而是淡出到 0.4?
顺便说一下,你可以像示例中那样使用占位符“John Smith”,或者使用类似“输入你的全名...”的东西。 哪一个更好? 我个人更喜欢后者,因为它明确说明你需要开始输入,这应该可以解决这个问题
据我所知,标签回答的是“什么?”,而占位符回答的是“如何?”。
在这个示例中,标签应该说“你的姓名”(或类似的词语),而占位符应该显示如何填写该字段(姓 + 名? 仅名? 昵称?),通常会提供一个示例,比如“John Smith”。 这就是为什么我们在很多情况下会在占位符前面添加“例如”的原因。
如果我说的没有道理,请有人纠正我。
我想你是对的(因为它毕竟被称为占位符),但我见过很多地方将“标签内容”放在占位符中……我也很喜欢这样 :) 浏览器支持太糟糕了。
无论如何,当我发布这条评论时,页面没有正确刷新,否则我就会看到我的第一个建议与你的建议非常相似。
顺便说一下,这个页面本身就使用占位符作为“标签”(以及一些 polyfill)。 标签用于 UX,只是不可见。
对我来说,半秒钟的延迟没有意义,感觉很奇怪。 我已经习惯了占位符在我点击字段时立即消失。 我认为我并不需要这额外的秒数来识别提示。 我会在开始移动光标之前阅读文本。 由于占位符在 0.5 秒后消失,我感到困惑,因为占位符不像标签那样引人注目,它吸引了太多注意力,打乱了我自己的“节奏”:阅读 - 思考 - 写入。 这可能会让人分心。
没有人注意到,但在 Firefox 中,占位符属性的行为是保留文本,直到用户开始输入,至少在最新的版本中是这样。 如今,针对 WebKit 问题的 WebKit 解决方案(或者应该说是 -webkit 解决方案)似乎不会持续很长时间。
已确认。 唉。
::-moz-placeholder
可能可以用于相同的效果(未测试)。*&^#& 错误链接(哈哈,别问我为什么我的剪贴板里有这个网址)
请编辑?
正确链接:
::-moz-placeholder
(https://mdn.org.cn/en-US/docs/CSS/:-moz-placeholder)抱歉,我知道这真的很偏离主题,但那个 traq 误入的链接是我读过的最有趣的东西……
哈哈!
很高兴看到美国的研究资金投入到*真正*重要的问题上!:D
根据我几分钟前的测试,使用 ::-moz-placeholder 和过渡不透明度,当您将焦点放在输入框时,占位符文本会消失,但它会立即消失,而不是过渡。
这是一个替代的 CSS 过渡解决方案,允许您在从输入框中删除占位符文本的同时,保持占位符文本可见。布局可能需要调整以适应您的表单布局,我建议将其推到输入框下方,用于堆叠的表单布局。
http://codepen.io/anon/pen/GDpBr
请注意,它只在 Webkit 中有效,但我对渐进增强没问题。无论如何,用 JavaScript 复制它会相当简单。
整洁的解决方案,但我认为人们如今过于依赖占位符,而忽略了标签。只要您没有要求奇怪的东西,大多数人都能理解像“电子邮件”或“姓氏”这样的标签。占位符有它们自己的……呃……位置,但说实话,在我看来,当您获得焦点时,应该立即消失。从可访问性的角度来看,标签一直是首选,并且仍然是首选。*耸肩*
同意。占位符应该支持标签。
我对此没有太多偏好。当我第一次看到它没有立即消失时,我觉得很困惑,感觉像是糟糕的编码或类似的东西,但当我开始输入时,它就说得通了。我认为人们从多年填写表格的经验中得知,占位符应该在获得焦点时消失。
我工作的公司绝对不喜欢这个新功能,总是让我在获得焦点时让它消失。我以前总是用 jQuery 做这件事,但我以后一定会使用这种方法。
很多东西一开始对用户来说没有意义,但他们最终会学会。也许这种情况是,增加的功能值得用户进行一小段时间的再培训?
我们还需要记住,许多不同的模式(有些好,有些坏)最终可能会比单一的平庸模式更令人困惑……
我认为这是这里的主要问题之一:人们(太)快地习惯了习惯,但后来却无法轻松地改变它们。他们倾向于坚持他们的旧习。也许这只是时间问题,他们会适应并接受它。
在可用性(设计师一方)和预期(用户一方)之间存在着一条细线。设计师无法单独让这两者一致。
在办公室进行基本的 UX 测试时,我曾遇到过几个人提到占位符文本完全相同的问题。他们说他们没有意识到那是占位符,或者他们可以开始输入。我的偏好是,与其在获得焦点时完全删除占位符,不如将其调暗。保持可读性,以防他们只是盲目地通过表单进行制表,但要清楚地表明他们已经对自己的操作做出了响应。我不确定这是否更好,但我犹豫是否完全隐藏文本。
如今很多人都使用占位符,我认为最终用户可能已经习惯了它们。我认为人们可能已经习惯了他们的浏览器默认设置,而改变它们只会造成更多混乱。我不是说浏览器的做法是正确的,但这可能是用户所习惯的,所以我认为在这种情况下,最好保持原样。
我想知道这是否是一个浏览器供应商对 HTML5 占位符的广泛黑客/误用的问题。
我们的表单有可访问且有效的标签,然后占位符出现,从设计角度来看很漂亮。所以设计师/开发人员会想,啊哈,我们可以省掉标签,为我们的手机视图节省一些空间。
但现在出现了问题 - 一旦用户获得焦点,就没有标签,导致混乱和表单被放弃。所以开发人员开始使用黑客手段,让占位符在获得焦点时保持可见。
-webkit 出现了,它对这种情况做出了响应,占位符在用户开始输入之前保持可见 - 此时他们知道自己在输入什么,不再需要标签。
-moz 接着遵循这种模式。
现在又出现了一个新问题 - 当用户想要输入时,会因为充当准标签的占位符挡在路中间而感到困惑/认知负荷。(我看到人们在填写表格时遇到了这个问题 - 他们认为他们必须删除或选择并覆盖占位符 - 用户担心他们会“破坏”表格或意外提交错误信息。
似乎最好的解决方案是回到使用标签作为标签,以及在获得焦点时消失的占位符。
也就是说,我想知道浏览器供应商是否有可靠的研究表明占位符保持在原位是更好的用户体验,根据我的经验,情况并非如此。
我认为添加淡出或延迟然后淡出或更改颜色(尽管它们一开始看起来很优雅),只会增加混乱,因为它添加了一种用户不习惯的模式。
如果研究是正确的,而且人们因为占位符文本没有消失而感到困惑,那么我将在获得焦点时完全删除占位符文本。
最佳实践是为表单字段添加标签,因此占位符只是对用户的一种“锦上添花”的提示/示例。如果他们在占位符消失时对要填写的内容感到困惑,那么标签就没有发挥应有的作用。
您填写过多少次带有“姓名”、“电子邮件”等的表单,却无法理解需要提供什么类型的数据?显然,示例占位符会让您很好地了解需要提供多少姓名(“John”、“John D”、“John Doe”),但大多数时候,我认为这并不是必需的。
如果,像我现在正在编写的这个表单一样,占位符被用作标签,那么显然它们就成为表单中非常重要的一个方面。不久前我看到一个很好的例子,当字段获得焦点时,占位符以较小的字体移动到字段的右上角。对我来说,这非常有效,当我通过表单进行制表时,我仍然知道字段需要什么,但主要焦点是我正在输入的内容。我不记得在哪里看到的,但这是一个简单的例子:http://cl.ly/image/1F0l2j1B3X2Z.
那些在没有在字段中输入任何内容的情况下单击/点击“搜索”按钮的用户怎么办,他们认为*占位符/提示实际上就是他们要搜索的内容?
那些在字段完全空白时单击/点击“搜索”按钮的用户怎么办?
是的,我必须处理这些分析大约 4-5 年了,我对……某些用户的愚蠢程度感到惊讶**。
长话短说,对于第一个示例,我们通过 JavaScript 使用了“*在此处输入您的词语*”作为占位符(*是的,我知道,对占位符概念的错误使用,但这并不是我们看到这种行为的原因) ,而我们分析中最常搜索的词语是什么?是的,“*在此处输入您的词语*”。
因此我们删除了提示/标签,最常搜索的词语是?……“*(空白)*”。
说真的,WTF。
我现在知道,无论 Web 设计、可用性和 JavaScript 之神对这个
placeholder
标签做了什么,总会有一些用户对其中一种解决方案感到困惑,也会对另一种解决方案感到困惑。**我过去也犯了不少蠢事,现在仍然会 ><
年轻人没问题,但想想老年用户……
我敢肯定那些人会在开始输入之前尝试删除占位符……
淡出效果看起来是一个不错的解决方案
-- 对不起我的英语语法 --
我还没有看到在 IE7、IE8 或 IE9 中实现这一功能的解决方案。如果有的话,请告诉我。否则,此回退将始终在所有浏览器上运行。
input value=”YOUR TEXT HERE” onfocus=”if(this.value==this.defaultValue)this.value=”” onblur=”if(this.value==”)this.value=this.defaultValue”/
文本将在所有浏览器中显示,当用户点击时,文本将消失。 不会平滑淡出,但对我来说这是万无一失的。
伙计们,你们在 Mozilla 上测试过这段代码吗? 因为它在我的 Mozilla 上不起作用……
有什么建议可以让它在 Mozilla 上运行,那将很棒……
它在 FF 中不起作用的原因是它以 -webkit-input-placeholder 为前缀。
看看这个 答案
我们解决问题的一种方法是将占位符文本与文本区分开来,方法是将其放在<>中
非常有趣,完全颠倒。 如果没有别的,如果你倾向于迷恋人,你越深入研究这些东西,你就越意识到有多少种方法可以感知任何事物。
关于这里的建议,所有这些都值得考虑,包括文章本身和评论,就像很多事情一样,它是一个不断变化的目标。
截至 2014 年 4 月 4 日,嵌入的示例在 Mac 10.6.8 上的 Safari 5.1.10 或 FF 28 中不能按原样工作(在文章或评论中),但在 Chrome 33.0.1750.152 中可以工作。
不仅是浏览器,而且是浏览器/操作系统特定。 但那是另一个话题。
无论如何,我可能漏掉了解释和讨论中的某些内容;我承认自己是一个彻头彻尾的新手,与这里所有发表评论的人相比,我怀疑这一点。
我认为浮动标签模式是最优雅的,但我认为这可能会吸引用户开始输入。 文本不仅会跳动,恳求用户互动,而且我使用了“类型”这个词。 除非他们不识字,否则我不知道还有什么比这更清楚了。
http://codepen.io/jamestrenda/pen/uldKB/
我花了 15 分钟注册 CodePen 并试图弄清楚如何嵌入我刚刚链接的分叉笔。 我应该复制粘贴的代码看起来就像一个链接,这不是我想要的。 我在 CodePen 博客上找到了一些稍微有用的信息,这让我相信你只需要粘贴代码,脚本就会用嵌入的代码替换链接。 我在我的家庭服务器上成功测试了这一点。 所以我在这里做到了,然后点击“提交评论”,结果只看到了链接,没有看到嵌入的笔。 哎呀。
嘿,詹姆斯,
很抱歉你在嵌入方面遇到了这么多麻烦。 你遇到的问题是你试图在这个评论线程中使用完整的 HTML 嵌入代码。 你会认为这是可能的,因为这里支持 HTML,完全可以理解。 问题是我们的嵌入代码使用了一个
<script>
,正如你所看到的。 我(以及几乎所有网站)都不允许你在评论中发布任意脚本。 这将是一个重大的安全漏洞。为了解决这个问题,在 CodePen 我们提供 oEmbed,这样你就可以在 URL 中放置一个链接,它就会执行嵌入。
我们将尽力使文档更清晰。
我正在对这个进行一些调整,想知道是否有办法进行反向转换? 即如果用户在不输入任何内容的情况下点击退出,则淡入。 我的情况在这里:http://codepen.io/SimeonC/pen/wsDaH(只需聚焦然后模糊字段)。
不用担心——如果在你不添加和删除的类上添加转换,这会有所帮助。