- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Tue, 04 Jun 2019 15:06:54 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Password reveal pseudo-element and pseudo-class`, and agreed to the following:
* `RESOLVED: input-security: auto|none in UI 4 and applies to input type=password only`
<details><summary>The full IRC log of that discussion</summary>
<heycam> Topic: Password reveal pseudo-element and pseudo-class<br>
<heycam> https://github.com/w3c/csswg-drafts/issues/3934<br>
<fantasai> github: https://github.com/w3c/csswg-drafts/issues/3934<br>
<heycam> fantasai: Greg posted an issue where he wanted to ask for a pseudo-element<br>
<heycam> dbaron: and pseudo clas<br>
<heycam> fantasai: for when passwords have a show the password switch<br>
<heycam> dbaron: [demos what the Windows UI looks like]<br>
<heycam> dbaron: in many cases, users with good 30 char passwords, want to make sure they didn't make a typo<br>
<heycam> ... Edge has this, and it's nice<br>
<heycam> hober: sites work around this by writing terrible scripts to change input type=password<br>
<heycam> emilio: that is a security issue<br>
<heycam> hober: harder for password autofill to work<br>
<fremy> q+<br>
<heycam> jensimmons: is the proposal to create a pseudo to style the two states?<br>
<heycam> AmeliaBR: the proposal is to style it if the UA provides it<br>
<heycam> dbaron: two pieces. one piece is a pseudo class that matches the control as a whole, when the pw is revealed<br>
<chris> Android also has this reveal-password button<br>
<heycam> ... the other is a pseudo element, that matches the toggle thing, so you can use a different image for it<br>
<florian> q+<br>
<heycam> fantasai: my qn is, is it important to make this stylable?<br>
<heycam> Rossen_: that's what we started with. back in IE 10, there was a demand for this, botth the x button on input type text, and the reveal on password<br>
<tantek> the "x" button? is that the "clear field" button?<br>
<heycam> ... and so there was a lot of web sites that started to fight with the pseudo. until they figured out how to use it<br>
<heycam> ... at the time, it was a prefixed impl<br>
<heycam> Rossen_: most sites ended up with two "x"s, or two reveal buttons<br>
<fremy> @tantek: yes<br>
<heycam> ... having a predictable way to turn it off, at least, is why we ended up with this being stlyable<br>
<heycam> fantasai: I'm figuring there's a use case for having it. but is the use case strong for stylable?<br>
<heycam> Rossen_: it's as much as making any other control stylable. should contrls be looking native? stylable?<br>
<jensimmons> q+<br>
<dbaron> (another thing that goes wrong when people use input type=text for things that are actually passwords is that mobile keyboards might try to remember the password for their autocompletion, whereas I think they're pretty good about not remembering things that go in password controls)<br>
<heycam> fantasai: but it should be keying off the font?<br>
<heycam> ... should use the same color and size as the text inside the box<br>
<heycam> Rossen_: by default that's our Edge behavior<br>
<heycam> ... not sure what every author will want<br>
<heycam> ... they might want this google style button with a large eye<br>
<myles_> q+<br>
<fremy> q-<br>
<tantek> "large eye" so is that asking for both dimensions and image customizability?<br>
<heycam> una: every time I see form elements, I can see designers wanting to match brand styling<br>
<heycam> ... makes sense to adjust the element with a pseudo. that's a common pattern, would be good to make it easier for developers<br>
<Rossen_> q?<br>
<AmeliaBR> q+<br>
<Rossen_> ack florian<br>
<heycam> florian: 2 points. I'm confused by the pseudo class, not so much with the pseudo element apart from hiding it<br>
<heycam> ... just changing the color of it sounds weird<br>
<fremy> @Chris__: (to answer your long-gone question, the Edge one used a push-to-reveal as well, but for screen readers, that wasn't possible, so we switched to push-to-toggle-reveal instead so that screen readers can switch to text input)<br>
<fantasai> s/weird/weird if you don't know really what it is/<br>
<heycam> ... second, we have from a year back, a resolution for something that hasn't made it into a spec, which is complementary to this<br>
<heycam> ... opt in for a non-password field to look like a password field<br>
<una> q+<br>
<heycam> ... I think we resolved on something in CSS UI to opt in to the hidden display<br>
<heycam> ... these two thins probably interact<br>
<heycam> dbaron: one thing I missed saying is that the intent of the pseudo element that the things that are stylable are widht, height, background-image<br>
<heycam> Rossen_: and it could have state<br>
<heycam> ... if it's sticky, e.g.<br>
<astearns> yeti peeking at your password UI: https://codepen.io/ankitashodhan/pen/mxxjpY<br>
<Rossen_> q?<br>
<Rossen_> ack jensimmons<br>
<heycam> jensimmons: I agree with una that the use case is strong. replacing the eyeball with an icon that matches the styling of the site is one<br>
<heycam> ... someone might want to put a red border around the input when pw is revealed<br>
<heycam> ... I think CSSWG so far has been reluctant to allow styling of form controls<br>
<heycam> ... but this is a newer one, and i think we're moving towards solving stylability<br>
<Rossen_> ack myles_<br>
<fremy> For people curious, here is when we standardized Apple's proposal:<br>
<heycam> myles_: this idea of the reveal pw icon is a good one<br>
<fremy> RESOLVED: input-security: auto|none in UI 4 and applies to input type=password only<br>
<bkardell_> is it actually a newer control?<br>
<fremy> https://github.com/w3c/csswg-drafts/issues/2495#issuecomment-380397331<br>
<heycam> ... if sites start changing icons, maybe every site will have a different looking passwrod field<br>
<heycam> ... which is harmful for web security<br>
<heycam> ... trains users to type pw into sketchy things<br>
<tantek> q?<br>
<fantasai> myles: good proposal, but replacing image seems problematic<br>
<tantek> But Google does it (changes the icon) so it must be ok right?<br>
<heycam> myles_: on iOS it's a deliberate feature to make input type password look the same as system password entry fields<br>
<fremy> q+ since I'm confused with what myles said<br>
<fremy> q+<br>
<heycam> chris: we don't allow style sheets to change the lock icon in the address bar<br>
<fantasai> Florian^: if all password fields look the same, then users are used to typing into things that looke like that ... if they all look different, then they adapt to typing in the password into anything<br>
<Rossen_> q?<br>
<heycam> fremy: but you're already shipping input-security<br>
<Rossen_> ack AmeliaBR<br>
<fremy> q-<br>
<heycam> AmeliaBR: heard a strong need for something not in the proposal, which is detecting whether the UA will be displaying a pw reveal<br>
<heycam> ... or the clear field button<br>
<heycam> ... argument for styling is more superfluous<br>
<jensimmons> q+<br>
<heycam> ... from usability perspective, having these things look different everywhere isn't necessarily good for users<br>
<heycam> ... I was fighting recently with a site that was breaking the pw reveal button, because the focus kept getting lost<br>
<heycam> ... could imagine all kinds of way s to make the button unusable<br>
<Rossen_> q?<br>
<tantek> "fussy designer could get rid of this usability feature" <-- this<br>
<heycam> ... in general, CSS doesn't mandate good design, authors can shoot themselves in the foot, but when this is a very strong security / usability issue, not sure what the argument is<br>
<florian> q+<br>
<heycam> .. other thing was what Jen brought up; we have this much broader scope of exposing subcomponents of replaced elements, if we do this it should maybe be part of this much larger scope<br>
<heycam> jensimmons: that wasn't my point<br>
<heycam> una: I wanted to speak to AmeliaBR's point<br>
<Rossen_> ack una<br>
<heycam> ... I can see the perspective of wanting similar UX<br>
<heycam> ... right now things look diff because people must reimpl them<br>
<heycam> ... so I think it could help with unification<br>
<heycam> ... having a standard for pw fields<br>
<AmeliaBR> q+<br>
<heycam> ... and could be overridden if the team wants to<br>
<tantek> The pseudo-element does sound like a bit of a footgun, as it burdens webdevs with doing it in such a way that works across input fields on different desktop/mobile OSs/platforms etc. which is a lot more than they may expect they have to do<br>
<heycam> ... to the second point, does this span any replaced element? what about telephone fields? maybe validating want to little check mark in there<br>
<heycam> ... should we be thinking about form elements as a whole?<br>
<heycam> fantasai: that's a good point that that exists<br>
<Rossen_> q?<br>
<heycam> ... placing that check mark and making sure it doesn't overlap the contents of the field. this doesn't solve that<br>
<heycam> ... I would be curious to know, if we have this pw reveal implemented across all browsers, and waited a year, would there still be such a high demand for doing custom ones? or would it be adequate to just let the browser do it?<br>
<heycam> una: I've seen very design system have different designs for these elements, so I think the demand iwll continue<br>
<heycam> Rossen_: so eveyrthing else would look as designed, except hte icon?<br>
<chris> q?<br>
<heycam> fantasai: but these icons don't have a lot of presence<br>
<heycam> una: looking at these 2 examples. the material design one. the second one was the Edge one<br>
<heycam> ... can't really mix and match them<br>
<Rossen_> q?<br>
<Rossen_> ack dbaron<br>
<heycam> dbaron: I had three comments. one, AmeliaBR asked how do you detect this<br>
<dbaron> @supports selector(::reveal)<br>
<heycam> ... one answer is that you could use @supports for this selector<br>
<heycam> ... impls would only suppor this selector if they have a pw reveal mechanism<br>
<heycam> TabAtkins: I don't like that assumption. then they'll have broken style rules<br>
<heycam> AmeliaBR: that already hapepns with pseudos everywhere<br>
<fantasai> ...<br>
<fantasai> dbaron: Somewhat, but also today's impls don't support that pseudo<br>
<florian> q?<br>
<fantasai> dbaron: fremy pointed out that a year ago we agreed to add 'input-security' property that controls whether or not the password shows up<br>
<fantasai> scribeNick: fantasI<br>
<fantasai> dbaron: If that property has influence on whether the reveal pseudo-class matches<br>
<fantasai> dbaron: then we can't do both<br>
<fantasai> dbaron: You can't have a property that controls whether a selector matches<br>
<fantasai> dbaron: This is not a problem for the pseudo-element, though<br>
<fantasai> dbaron: We don't want to create cycles with input:reveal { input-security: ... }<br>
<tantek> FYI: https://github.com/w3c/csswg-drafts/issues/2495<br>
<heycam> ScribeNick: heycam<br>
<heycam> florian: talking about this I said that we had introduced this prop, for arbitrary things, which is not what we resolved. we resolved none and auto, for make it able to turn it off on pw fields<br>
<heycam> ... not to hide it on non-pws<br>
<heycam> fantasai: that problem still applies<br>
<heycam> ... just limited in scope to input<br>
<Rossen_> ack florian<br>
<heycam> dbaron: the 3rd comment is that there was a bunch of discussion baout WG's history of not styling form controls<br>
<heycam> ... some of this is that there was an assumption that really form controls are a big problem to tackle, and there was a bunch of ongoing work that was supposed to help us tackle this problem, which at this point has taken 14 years longer than expected<br>
<heycam> ... Web Components is a thing now<br>
<heycam> ... part of the idea of the origin of WCs is to help us figure out how to expose styling of form cotnrols to the web<br>
<heycam> ... we should at some point think about whta we can do that is still web compatible, we have more compat constraints now<br>
<heycam> bkardell_: it would be helpful to work with people how make custom control libraries<br>
<heycam> ... I want to be in control of these things, but not these things? it's not simple<br>
<Rossen_> q?<br>
<heycam> Rossen_: there will always be native controls<br>
<tantek> Also FYI: https://developer.mozilla.org/en-US/docs/Web/CSS/-webkit-text-security<br>
<Rossen_> ack jensimmons<br>
<heycam> jensimmons: myles_ what you brought up was interesting, keeping UX consistent as a security concern, pulls it out of the rest of the form controls debate<br>
<heycam> ... if we wanted to pull those concerns up, the web should get the pw off the web page, I wonder if the genie is already out of the bottle<br>
<heycam> ... I don't have any answers, but there's something interesting there<br>
<florian> q?<br>
<heycam> ... solving passwords on the web ... not going to happen here<br>
<florian> q+<br>
<tantek> Does the CVV use-case apply here? (e.g. is that a use-case for -webkit-text-security ?)<br>
<heycam> fantasai: I don't think Web Components is the answer to all of this<br>
<bkardell_> my above comment was intended to say that there are orgs and frameworks providing custom elements to other people now, and they seem to have similar challenges as browsers now<br>
<florian> q-<br>
<heycam> jensimmons: we'll get to the form controls eventually, just ship these pseudos for passwords?<br>
<Rossen_> ack AmeliaBR<br>
<Rossen_> Zakim, close q<br>
<Zakim> I don't understand 'close q', Rossen_<br>
<heycam> AmeliaBR: is there any interest in browsers that don't have this feature, adding this feature?<br>
<Rossen_> Zakim, close queue<br>
<Zakim> ok, Rossen_, the speaker queue is closed<br>
<heycam> ... is there any work being done on the HTML side to have this as a state of the input element, that is revealed on a DOM level? rather than just through CSS<br>
<heycam> ... right now, I don't think there is any DOM level way to detect when someone toggles the reveal or not on their native input<br>
<heycam> ... not sure whether it's a security concern, but it would expose info that's not already exposed<br>
<heycam> ... which may be something to consider<br>
<heycam> ... and the discussion maybe should happen at a DOM/HTML level<br>
<heycam> ... on dbaron's concern about circularity, don't think it's an issue<br>
<heycam> ... wouldn't want the revealed state to be based on a css property, but a state maintained by the input element which knows whether it's revealed or not<br>
<heycam> ... and the UA sheet can say do something based on it<br>
<heycam> ... but again that depends on the idea that the input element is able to maintain the state of whether it's in the reveal state, which is an HTML/DOM question<br>
<heycam> myles_: when we discussed text-security a year ago, we spent a lot of time talkingabout the behavior of mobile browsers, where you press a key and it shows for 0.5s<br>
<heycam> AmeliaBR: it's a state that exists only as long as you're pressing the key, vs on or off<br>
<heycam> myles_: it's per character tho<br>
<heycam> AmeliaBR: as you're typing? the char you just typed?<br>
<heycam> myles_: yeah<br>
<heycam> una: I liked AmeliaBR what you said about HTML<br>
<heycam> ... reminds me of the media control state<br>
<heycam> ... it lets them decide whether to show the widget<br>
<heycam> AmeliaBR: so the author could make a custom control that toggles the pw reveal state?<br>
<heycam> una: yes<br>
<heycam> AmeliaBR: currently most impls switch the input type from pw to text, awkward for a11y<br>
<heycam> ... bad for autofill<br>
<heycam> ... if authors could impl a custom pw reveal without changing the fact that it's pw...<br>
<heycam> florian: that's what we resolved 1yr ago, not that it was a DOM prop tho<br>
<tantek> q?<br>
<tantek> q+<br>
<heycam> ... the details of whether it's showing only the last char, or the whole text, that's "auto"<br>
<heycam> ... but only applies to input elements<br>
<heycam> ... we didn't follow up on that, but we did resolve it<br>
<heycam> AmeliaBR: that doesn't let the custom control allow you to turn the revealing on and off<br>
<AmeliaBR> s/allow you to/detect whether the user agent can/<br>
<heycam> florian: should we reopen that 1yr old question to see whether we should have it in HTML/DOM instead?<br>
<heycam> tantek: I think we want this for cvv fields too<br>
<heycam> ... so yes<br>
<heycam> florian: the control we have didn't allow you to hide things. only reveal things which are hidden by default<br>
<heycam> ... didn't want them to make normal text fields look like pw fields<br>
<heycam> florian: the earlier resolution, we decided we only needed auto/none<br>
<heycam> ... when WebKit brought this to the group, was to stop having non-pw fields for pw-ish purposes<br>
<heycam> tantek: that sounds like denial of the use case<br>
<heycam> florian: does sound like we should reopen that issue<br>
<heycam> ... should we be able to hide things revealed by default, and whether it should be a DOM thing<br>
<fremy> @myles @myles_ why did you mention this to me: // text-security was implemented in 2007, 12 years ago<br>
<heycam> myles_: search fields often have a manifying glass image. if this will have an icon thing, it should use the same mechanism<br>
<heycam> Rossen_: in Edge, it's the same mechanism. there's an action pseudo, for clear, search, reveal<br>
<heycam> hober: can't resolve to add the pseudo class but also have input-security<br>
<heycam> tantek: it's not optimal<br>
<heycam> dbaron: needs to be clear what the two things do. it's still possible<br>
<heycam> emilio: could have weird states with non-revealed text but still matching the pseudo<br>
<heycam> fremy: [...] if the user clicks the button it would override what's set<br>
<heycam> dbaron: does input-security control whether there's a reveal button or not?<br>
<AmeliaBR> q?<br>
<heycam> ... someone needs to write down a defn, to check whether the input-security is reasonable, the pseudo is reasonable, and whether they interact well or not<br>
<heycam> AmeliaBR: I think we've brought up a number of issues, would be worth updating the explainer/proposal to hash out these details<br>
<heycam> ... and generalizing to other action buttons. greg's not here, just throwing it back on him...<br>
<heycam> jensimmons: from Greg's tweets sounds like he's diving into stylable controls<br>
<heycam> tantek: 3 interrelated issues, resolving on one will make it harder to make sensible resolutions for the others<br>
<heycam> florian: come back with a complete proposal<br>
<heycam> tantek: hoping the "things that want a reveal button which are not pw fields" use case can be handled<br>
<heycam> -- 15 min break --<br>
<tantek> heycam++<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3934#issuecomment-498712344 using your GitHub account
Received on Tuesday, 4 June 2019 15:06:56 UTC