[CSSWG] Minutes Toronto F2F 2019-06-04 Part I: Selectors [selectors-4]

  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.


  - RESOLVED: Draft :muted, :seeking, and :stalled pseudos. (Issue
              #3821: Additional resource state pseudo-classes for
              media elements)
      - The definitions of exactly when these apply needs work.
      - There was a desire to also have the ability to style for a
          buffering state, but there was no clear HTML property to
          hook into for that case.
  - RESOLVED: Add :volume-locked. (Issue #3933: “effective media
              volume is mutable” pseudo-class for media elements)
      - There was some further discussion of merging :volume-locked
        and :muted into a functional :volume() pseudo-class.

  - There is still feedback that implementing :has() will not be easy
      or performant. There was some suggestion of breaking off a more
      limited section like has-child but that causes concern that
      it'll lead to 50 different pseudos to do everything scoped into

  - The issue to allow for styling of password reveal via a
      pseudo-element and pseudo-class (Issue #3934) generated a lot of
      discussion around usage. The class matches the control as a
      whole when the password is revealed and the element matches the
      icon to click in order to see the password.
      - The use case for the element is to allow the show password
          icon to be consistent with branding, however that raised
          concerns that it would train users to put passwords in any
          type of yield instead of only password ones.
      - There was an additional use case to detect if a browser will
          already insert the symbol.
      - There are other use cases beyond passwords that are by default
          hidden and may want a show option, such as CVV fields.
          One argument was that these should be considered password fields.
      - This proposal needs to be considered in conjunction with the
          previous resolutions for input-security to come up with one
          consistent approach, even if it means changing the original
          input-security resolution from last year.
      - This proposal also needs to be considered in conjunction with
          other use cases for widgets and icons inside the input field,
          e.g. for clearing the input or annotating validation state.


Agenda: https://wiki.csswg.org/planning/toronto-2019

  Rachel Andrew, Fronteers
  Rossen Atanassov, Microsoft
  Tab Atkins, Google
  L. David Baron, Mozilla
  Amelia Bellamy-Royds, Invited Expert
  Oriol Brufau, Igalia
  Tantek Çelik, Mozilla
  Dave Cramer, Hachette Livre
  Elika Etemad, Invited Expert
  Rob Flack, Google
  Jihye Hong, LGE
  Koji Ishii, Google
  Brian Kardell, Igalia and Open JS Foundation
  Ian Kilpatrick, Google
  Una Kravets, Google
  Chris Lilley, W3C
  Stanton Marcum, Amazon
  Cameron McCormack, Mozilla
  Theresa O'Connor, Apple
  François Remy, Invited Expert
  Florian Rivoal, Invited Expert
  Jen Simmons, Mozilla
  Alan Stearns, Adobe
  Lea Verou, Invited Expert

Scribe: heycam


Additional resource state pseudo-classes for media elements
  github: https://github.com/w3c/csswg-drafts/issues/3821

  hober: We currently have :playing and :paused pseudo classes, which
         media elements match when they are playing or paused
  hober: The use case is, things like custom media controls, with a
         unified play/pause button
  hober: There are a handful of other common media element states that
         have a similar rationale for exposing to CSS
  hober: stuff that people are currently using script for
  hober: This issue is the 3 easy ones
  hober: 1 is whether or not the element is muted
  hober: You may have a mute button, styled volume slider
  hober: very similar to playing/paused
  hober: hope it's uncontroversial
  hober: Other 2 are a bit weird
  hober: The HTML spec has a concept of media being stalled
  hober: and you can see examples of custom UI when media is stalled
         on popular sites like YouTube, netflix
  hober: the spinner looks different
  hober: If we could provide styling for that it would be nice
  hober: The 3rd one is: media elements have a seeking state, which is
         useful for cases like when you are displaying custom
         controls, but seeking is happening due to other controls
  hober: Maybe seeking with a remote control, but you want you custom
         control to do a different thing
  <tantek> FYI:
  hober: So the HTML spec has the right hooks here
  hober: just need something in CSS to expose them
  hober: So 3 proposed pseudo classes: muted, stalled, seeking

  florian: What is seeking as a state
  hober: While you're seeking. If you using the scrubber
  AmeliaBR: Like an active state

  dbaron: There's often a lot of ways to mute something
  dbaron: My guess here this ignores your tab is muted, hardware
          control is muted, is that right?
  hober: I think that's right. but I'm not sure. I think this should
         be tied to the host lang's definition
  dbaron: Okay so the HTML definition

  tantek: I like the general direction of the proposal, +1 on them.
          even the less common features
  tantek: This shook loose memories of things I worked on right before
          Mozilla, doing HTML5 consulting, setting up video UIs
  tantek: Took a bunch of notes which I forgot about that
  tantek: I needed this in 2010
  tantek: The :stalled pseudo class, I've seen different UI between
          buffering to show something, vs the network connection is
  tantek: even if you're in this "I want to play" state
  tantek: Wondering if it's worth distinguishing
  <florian> +1 to tantek
  hober: I agree there's a use case there
  hober: I think network state is a little more general. That's going
         to affect the page, not just the media elements
  tantek: But that's a different can of worms
  hober: I'd rather tackle that as a different thing
  tantek: I'm saying I'd rather not, since it is a can of worms
  hober: Could you propose another pseudo for this?
  tantek: Do you want one pseudo that means either of that? two for
          the specific states?
  hober: I'd be happy to delegate this to HTML
  hober: Some HTML spec refactoring is needed anyway, for stalled
  hober: From our perspective, we'd defer to the host language
  tantek: Specifically the HTML media element interface?
  hober: Yes.

  <jensimmons> do these apply to <audio> as well as <video>? I’d
               assume so…

  emilio: Images have different set of states. broken, loaded. Gecko
          has internal pseudos for these
  emilio: I wonder if it is useful to try to expose a common set of
  fremy: I was going to suggest the same
  hober: In the past when this has come up, we've agreed we should
         have more general sub-resource state exposing
  hober: I was hoping to not get bogged down on that too much
  hober: There's specific use cases for media in custom media controls
  hober: I agree it should be coherent with a more general thing
  hober: so we should keep that in mind
  hober: but the last few times it's come up over 10 years, we end up
         not doing it
  <tantek> note that the HTMLMediaElement does distinguish network
  <dbaron> https://github.com/w3c/csswg-drafts/issues/3134 is about
           image state pseudo-classes
  <jensimmons> anything to make doing this kind of stlying possible,
               without replacing everything with JS, would be ideal:

  fremy: We don't need to standardize pseudos for all possible cases
  fremy: You say you're sticking to the HTML spec's state. There's
         already an error state in there
  hober: I'm happy for someone to propose those
  fremy: Seems reasonable to want to style them differently if you're
         on the network, etc.
  fremy: In the specific cases for media controls you do want to know
         about the network state
  fremy: In my initial proposal it was with video in mind. I think
         it's a good idea to see how we can map them
  fremy: if you end up in an error state, you want to show that in the

  TabAtkins: hober's list of things are video specific
  TabAtkins: Two specific questions
  TabAtkins: 1st, the current definition of playing says it subsumes
             seeking and stalled
  TabAtkins: keeping that?
  hober: Yes
  TabAtkins: ok cool. 2nd, :muted is good, do we want a general volume
             state? low-volume high-volume?
  hober: I think it's fairly common for there to be a separate mute
         button. And it doesn't seem harmful to have this
  TabAtkins: Not saying as a replacement
  hober: Think it totally make sense. The other proposal is related to
         volume, but it's a bit weirder than what you are proposing
  TabAtkins: I'll file a separate issue

  jensimmons: Would this apply to audio?
  hober: It will
  TabAtkins: But not all resources in general
  jensimmons: +1

  <tantek> I'd like to consider splitting :stalled into :buffering and
           :stalled distinct states, where :buffering means there is
           still some data coming from the network, just not enough to
           play, and :stalled is actually stalled including not
           getting data from the network

  tantek: Nitpick, but is :seeking while they're dragging? not when
          they let go?
  hober: Yes

  tantek: The specific request then is to split stalled into buffering
          and stalled
  tantek: As a webdev, that's the two states I want to hook into
  hober: I can't remember off hand if they are distinct states in HTML
  hober: anything you can reasonably map it makes sense
  florian: I think the stalled state, when it means buffering, is a
           variant of playing
  florian: it's a "trying to play" state
  tantek: It's not playing
  florian: The play/pause button is in the play state
  hober: There's all sound like issues to file in the HTML spec

  AmeliaBR: Overall my main concern is there needs to be clear
            definitions of what all these mean
  AmeliaBR: shouldn't be exposing things that aren't exposed other ways
  AmeliaBR: I assume most of these there are events you can listen to
            when these states change
  AmeliaBR: If that's not true, don't want to make people poll for
            pseudo state matching
  hober: I tried to limit to the state that is already exposed
  hober: People are already doing this with script, but perhaps a few
         frames behind
  florian: Not saying we should differ from HTML. but just not naively
           expose every state

  AmeliaBR: tantek brought up a point, if you want to get more
            granular, a general stalled class, then can add a
            parenthesized one later
  tantek: Since we only have 2 states would like to keep them
  tantek: and looking at the HTML spec now, it's more granular than we
  <tantek> HTMLMediaElement does have both networkState and readyState
           which are finer grained
  tantek: Per your request, I believe this information is available to
          script right now, but you need to combine readyState and
          networkState to figure out what's going on
  tantek: I'm saying let's expose a higher level state concept to UI
  tantek: HTML has these states already, but as a developer you need
          to check those combinations
  tantek: I'm saying CSS should simplify that
  <florian> +1 to tantek
  bkardell: Why only in CSS?
  tantek: We want to solve use cases, not plumbing
  AmeliaBR: Can you write up a table with the combinations?
  hober: Can you file an issue for buffering?

  florian: I'm confused about resolving on stalled before knowing what
           it maps to
  hober: It's just the HTML stalled state
  florian: My understanding there are low level bits, and the one
           called stalled covers more than one use case
  florian: if there are two bits maybe we don't want to expose these
           two things separately?
  bkardell: We shouldn't overload them with the same name...
  hober: The name stalled in CSS should be the same as stalled in HTML
  <AmeliaBR> `:stalled` vs `:buffering` and `:broken-stream`
  florian: Then maybe we should have two different ones, not called
  tantek: Are you asking for new HTML specs rather than new property
  hober: I'm not asking for anything in HTML
  hober: The 3 things I've proposed map to existing concepts in HTML
  tantek: Buffering is exposed, but there's no event for it
  hober: I think it would be weird to have a straightforward way to
         look for buffering in CSS and not have corresponding APIs
  tantek: There is
  hober: But you have to be clever by combining state
  tantek: DOM APIs are meant to be minimal and fine grained. but not
          for CSS
  hober: You should propose the :buffering pseudo, it sounds great

  florian: I'm also hearing that the stalled concept, if we're going
           to have :buffering vs not having it
  hober: I don't think it impacts that at all. stalled has a clear
         definition in HTML, that's what it should be
  AmeliaBR: You're still arguing it for it to be the superclass
  florian: I am arguing to go from use cases
  florian: and if it maps to several bits in HTML, that should be ok,
           but not name them confusingly
  florian: but whether it's useful to expose a single bit just
           because, we shouldn't
  <tantek> HTMLMediaElement summarizes stalled event as "The user
           agent is trying to fetch media data, but data is
           unexpectedly not forthcoming. "
  <tantek> which reflects the meaning that I'm proposing
  <tantek> and is not inclusive of :buffering
  hober: I'm not proposing that
  hober: I'm saying netflix has stalled UI, it's a common UI pattern,
         we have a definition in the spec
  <tantek> Netflix has both stalled and buffering UIs - they're
  <tantek> Netflix puts up an error when stalled (sorry no data or
           something), while buffering it shows a spinner and %
  florian: What is the use case? does HTML solve that use case already?
  florian: From the use case PoV, the buffering/stuck things are
  hober: So propose a buffering thing
  hober: I'm trying to do the opposite of stop energy here. If you
         propose it, I'll +1 it
  florian: If the stalled class means either buffering or stuck ...
  <tantek> To be clear I am supportive of :stalled as defined in HTML
           because it is NOT inclusive of :buffering

  Rossen: The stalled event in HTML has a clear definition
  <AmeliaBR> From HTML:
  <AmeliaBR> The stall timeout is a user-agent defined length of time,
             which should be about three seconds. When a media element
             that is actively attempting to obtain media data has
             failed to receive any data for a duration equal to the
             stall timeout, the user agent must queue a task to fire
             an event named stalled at the element.
  Rossen: The proposal here is to map a pseudo to this
  Rossen: That is all that is being proposed, the same way we're
          proposing for :muted, and :seeking
  Rossen: If there are other states in the media element that need to
          be exposed through events that will eventually map to
          pseudos, that's great. File HTML issues to add events so
          script and CSS can benefit from them
  Rossen: What we have right now satisfies the use cases brought
  fremy: Your summary is why I'm confused. You're saying what's in the
         spec solves the use cases, but I haven't seen the proof of
  fremy: but I will trust hober on this
  hober: I apologize for the argument from authority, I'm not the one
         working on this, I took this from media engineers from
         Mozilla, Google and Apple, and agreed to write it up for them

  emilio: :muted has a clear definition, since there's is
  emilio: :stalled only says when to fire the event, not when to
          remove it
  hober: Yes I need to follow up with an HTML issue to expose a spec
         hook to latch on to
  hober: It would be an editorial change to HTML

  RESOLVED: Add :muted, :seeking, and :stalled pseudos.

  <tantek> hober :buffering (or :waiting) proposed (add same time as
           :stalled please)

Mutable-Volume Pseudo-class

  hober: This one is similar to the other cases. It's a bit weird
  hober: In the HTML spec, media elements have a volume. Which you can
         set from JS
  hober: It can also be set by native controls
  hober: If you look at the algorithm for determining what the
         effective volume is, there is a clause that is a short
         circuit that allows for platform conventions to be followed
  hober: At least one case where this matters, on iOS, there is no
         software-controlled volume
  hober: It can't be changed from script. You can change it on the
         element, but that clause applies.
  hober: So we short circuit at step 1 of that algorithm
  hober: This is a feature that users like. They have control of
         volume, pages can't screw with that
  hober: I think there's another impl that does this? can't remember
  hober: People are doing UA sniffing to hide the volume button in
         media controls on iOS
  hober: I'd rather they be able to know that the effective volume
         won't be affected by the JS prop
  hober: The other difference is I don't know what to name this
  hober: the HTML spec doesn't have a name for it
  <jensimmons> `volume-effectiveness`?
  <dbaron> :can-control-volume ?
  <fremy> @hober: `:user-locked-volume` ?

  AmeliaBR: Before the name, I want to confirm this is
            uncontroversial. Not exposing new information?
  AmeliaBR: Currently, if you set the volume from script, and it
            doesn't work, you can tell?
  hober: Yes
  AmeliaBR: If I mute the whole laptop, is that included in this?
  hober: I don't know if system muted state on desktop OS affects that
  hober: If it did, I would expect it to affect this
  AmeliaBR: Either way there's a clear defined in HTML? and it's
            already exposed to script?
  hober: Yes

  hober: AmeliaBR proposed :adjustable-volume. so it's the opposite of
  TabAtkins: :volume-locked
  TabAtkins: Expresses the semantic that you'd style on, doesn't need
  TabAtkins: but given other suggestion for a volume pseudo, you could
             merge this into a pseudo that takes a keyword
  <TabAtkins> https://www.irccloud.com/pastebin/rPsIGCzk/
        :volume( locked || muted || <volume-value> )
        <volume-value> = [ '<' | '>' ] '='? [ <number [0,1]> |
            <percentage [0%,100%]> ]
  hober: On Windows, muted and volume are independent states
  <fremy> +1 on TabAtkins's proposal

  florian: I don't think this varies per element. Maybe a MQ is better?
  hober: I think the use case is tied to media controls
  florian: But you can't have one media element which is locked and
           one is not?
  hober: I think it makes sense to be symmetric with the other pseudos
  hober: but I concede the point it's a system wide thing

  jensimmons: Requesting a few quick examples in the thread
  hober: of Tab's syntax, or when you would use this?
  <TabAtkins> :volume(locked < 50%), for example
  <TabAtkins> :volume(muted)
  jensimmons: When you'd use it
  TabAtkins: For :volume(locked), you'd display:none your custom
             volume button
  <hober> div.controls:volume(locked) .volume { display: none; }
  <TabAtkins> `video:volume(locked) + .controls > .volume { display:
              none; }`

  AmeliaBR: Should the pseudo refer to the fact that the volume
            control works or wouldn't work?
  hober: My case is for the latter
  hober: Shouldn't display if it's going to be futile

  fremy: If you set vol to 0, that still mutes the video?
  hober: Depends on the platform
  hober: not on Windows. unmuted at volume at 0
  hober: on iOS you can mute audio tracks on media elements
  fremy: Using volume 0?
  hober: Using .muted
  chris: When you unmute you want to go back to the old volume

  florian: For this one and the previous one, wondering if this is
           practical as a pseudo, given the controls aren't usually a
  hober: It's often a sibling
  hober: That's the same as the existing :play / :paused pseudos

  hober: I really like Tab's locked suggestion. Either as the one off
         or the general proposal
  hober: Since we resolved on :muted. I'm happy to resolve on
         :volume-locked, and discuss merging later
  AmeliaBR: For the parenthesized idea, volume(max/min) might also be
  TabAtkins: Are min/max different from 0% / 100%?
  AmeliaBR: Do we want to expose %s in a selector?
  emilio: We don't have any other pseudos with numeric values inside
  hober: I think it's a good argument for going with the one off for

  RESOLVED: Add :volume-locked.

:has and :within selectors
  document: https://gist.github.com/bkardell/dbf5812c5a29fbb2f7ddf7575013cc14

  bkardell: We had 100 proposals to get around not having these.
            They're all happening in their own worlds, would be good
            to have some of us try to wrangle those into something
  bkardell: to make sure we answer the use cases that exist
  bkardell: Would anyone be interested in working on that with me?

  florian: There's a long tail of something and something within that
           are all kind of reasonable. But not reasonable to have 50
           different selectors
  florian: I think there were impls constraints in Gecko that :*-within
           is doable, you can do 2 or 3, but not 50
  florian: so should we fit which things are more worthy, but if we're
           going to do :has() ...
  emilio: Doing :has() seems harder than adding more bits
  bkardell: Is there a limited thing that's not :has()?
  bkardell: To cover enough use cases?
  AmeliaBR: A simple selector inside?

  emilio: The reason within is more reasonable is you know what you're
          going to match against
  emilio: so don't need to walk the whole subtree
  AmeliaBR: It's the difference between "focus changed, let's
            focus-within all the ancestors, vs generic selector match
            start from an ancestor"
  florian: For useful but less frequent, you could have a single bit
  emilio: :something-within
  fremy: But still have 50 different pseudos
  fremy: maybe just have an "other" bit that catches everything, and
         pull out the ones that are popular into their own bits

  bkardell: As an author this was my #1 frustration
  bkardell: If we know we can't do it, let's admit it
  TabAtkins: Was my impression that generic :has() we don't expect to
             be possible to impl reasonably
  AmeliaBR: I think there's agreement on the authoring use case,
            constraint is the impl side
  AmeliaBR: People familiar with selector matching engines should get
            together to hash out what's practical
  fantasai: It's doable, just not easy
  florian: Not performantly enough
  fantasai: If someone were to figure out how to implement it
            performantly ...
  TabAtkins: it will never be performant to do body:has(...)
  emilio: you can use memory instead of time...
  <tantek> what I'm hearing is: needs incubation
  <tantek> let's punt it to WICG
  <dbaron> (There's also the side question of whether :subject might
           be more implementable than :has()...)

  AmeliaBR: The other side to attract. if the way forward is with
            dedicated something-within selectors, we should know from
            author side what the demand is

  bkardell: I just want to know how to move forward
  emilio: If someone wants to impl :has I'm happy to mentor...
  fantasai: :has-child is a lot easier to impl, that would solve many
            use cases still
  <tantek> sounds like a WICG effort

Password reveal pseudo-element and pseudo-class
  github: https://github.com/w3c/csswg-drafts/issues/3934

  fantasai: Greg posted an issue where he wanted to ask for a
  dbaron: and pseudo class
  fantasai: for when passwords have a "show the password" switch
  dbaron: [demos what the Windows UI looks like]
  dbaron: In many cases, users with good 30 char passwords, want to
          make sure they didn't make a typo
  dbaron: Edge has this, and it's nice
  hober: Sites work around this by writing terrible scripts to change
         input type=password to input type=text
  emilio: That is a security issue
  hober: Also harder for password autofill to work
  <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)

  jensimmons: Is the proposal to create a pseudo to style the two
  AmeliaBR: The proposal is to style it if the UA provides it
  dbaron: Two pieces. One piece is a pseudo class that matches the
          control as a whole, when the password is revealed.
  dbaron: The other is a pseudo element, that matches the toggle
          thing, so you can use a different image for it
  <chris> Android also has this reveal-password button

  fantasai: My question is, is it important to make the icon stylable?
  Rossen: That's what we started with. back in IE 10, there was a
          demand for this, both the x button on input type text, and
          the reveal on password
  <tantek> the "x" button? is that the "clear field" button?
  <heycam> tantek yes
  <fremy> @tantek: yes
  <tantek> thanks fremy heycam
  Rossen: and so there was a lot of web sites that started to fight
          with the pseudo. Until they figured out how to use it
  Rossen: At the time, it was a prefixed impl
  Rossen: most sites ended up with two "x"s, or two reveal buttons
  Rossen: having a predictable way to turn it off, at least, is why we
          ended up with this being stylable
  fantasai: I'm figuring there's a use case for having it. But is the
            use case strong for stylable?
  Rossen: It's as much as making any other control stylable. should
          controls be looking native? stylable?
  fantasai: But it should be keying off the font?
  fantasai: Should use the same color and size as the text inside the
  Rossen: By default that's our Edge behavior
  Rossen: not sure what every author will want
  Rossen: They might want this Google style button with a large eye
  <tantek> "large eye" so is that asking for both dimensions and image
  una: Every time I see form elements, I can see designers wanting to
       match brand styling
  una: Makes sense to adjust the element with a pseudo. That's a
       common pattern, would be good to make it easier for developers

  <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)

  florian: 2 points. I'm confused by the pseudo class, not so much
           with the pseudo element apart from hiding it
  florian: just changing the color of it sounds weird if you don't
           know really what it is

  florian: Second, we have from a year back, a resolution for
           something that hasn't made it into a spec, which is
           complementary to this:
  florian: opt-in for a non-password field to look like a password
  florian: I think we resolved on something in CSS UI to opt in to the
           hidden display
  florian: these two things probably interact

  dbaron: One thing I missed saying is that the intent of the pseudo
          element that the things that are stylable are width, height,
  Rossen: And it could have state
  Rossen: if it's sticky, e.g.

  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
  jensimmons: Someone might want to put a red border around the input
              when password is revealed
  jensimmons: I think CSSWG so far has been reluctant to allow styling
              of form controls
  jensimmons: but this is a newer one, and i think we're moving
              towards solving stylability

  <fremy> For people curious, here is when we standardized Apple's
  <fremy> RESOLVED: input-security: auto|none in UI 4 and applies to
          input type=password only
  <fremy> https://github.com/w3c/csswg-drafts/issues/2495#issuecomment-380397331

  myles: This idea of the reveal password icon is a good one
  myles: If sites start changing icons, maybe every site will have a
         different looking password field
  myles: which is harmful for web security
  myles: Trains users to type password into sketchy things
  myles: good proposal, but replacing image seems problematic
  myles: On iOS it's a deliberate feature to make input type password
         look the same as system password entry fields
  Florian: If all password fields look the same, then users are used
           to typing into things that look like that ... if they all
           look different, then they adapt to typing in the password
           into anything
  chris: We don't allow style sheets to change the lock icon in the
         address bar
  fremy: but you're already shipping input-security
  <myles> fremy: -webkit-text-security: disc | circle | square | none
          <=== doesn't allow arbitrary images

  AmeliaBR: I heard a strong need for something not in the proposal,
            which is detecting whether the UA will be displaying a
            password reveal
  AmeliaBR: or the clear field button
  AmeliaBR: argument for styling is more superfluous
  AmeliaBR: From usability perspective, having these things look
            different everywhere isn't necessarily good for users
  AmeliaBR: I was fighting recently with a site that was breaking the
            password reveal button, because the focus kept getting lost
  AmeliaBR: Could imagine all kinds of ways to make the button unusable
  <tantek> "fussy designer could get rid of this usability feature"
           <-- this
  AmeliaBR: 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
  AmeliaBR: 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
  jensimmons: That wasn't my point
  una: I wanted to speak to AmeliaBR's point
  una: I can see the perspective of wanting similar UX
  una: Right now things look different because people must
       re-implement them
  una: so I think it could help with unification
  una: Having a standard for password fields
  una: and could be overridden if the team wants to
  <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

  una: To the second point, does this span any replaced element? what
       about telephone fields? maybe when validating want to have a
       little check mark in there
  una: Should we be thinking about form elements as a whole?
  fantasai: That's a good point that that exists
  fantasai: Placing that check mark and making sure it doesn't overlap
            the contents of the field. This doesn't solve that

  fantasai: I would be curious to know, if we have this password
            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
  una: I've seen very design system have different designs for these
       elements, so I think the demand will continue
  Rossen: So everything else would look as designed, except the icon?
  fantasai: But these icons don't have a lot of presence
  una: Looking at these 2 examples. the material design one. the
       second one was the Edge one
  una: can't really mix and match them

  dbaron: I had three comments. one, AmeliaBR asked how do you detect
  dbaron: One answer is that you could use @supports for this selector
  <dbaron> @supports selector(::reveal)
  dbaron: Implementations would only support this selector if they
          have a password reveal mechanism
  TabAtkins: I don't like that assumption. Then they'll have broken
             style rules
  AmeliaBR: That already happens with pseudos everywhere
  dbaron: Somewhat, but also today's impls don't support that pseudo

  dbaron: 2nd, fremy pointed out that a year ago we agreed to add
          'input-security' property that controls whether or not the
          password shows up
  dbaron: If that property has influence on whether the reveal
          pseudo-class matches
  dbaron: then we can't do both
  dbaron: You can't have a property that controls whether a selector
  dbaron: This is not a problem for the pseudo-element, though
  dbaron: We don't want to create cycles with input:reveal {
          input-security: ... }
  <tantek> FYI: https://github.com/w3c/csswg-drafts/issues/2495
  <tantek> Also FYI:
  florian: Talking about this I said that we had introduced this
           proposal, for arbitrary things, which is not what we
           resolved. We resolved none and auto, for make it able to
           turn it off on password fields
  florian: not to hide it on non-passwords
  fantasai: The problem still applies
  fantasai: just limited in scope to input

  dbaron: The 3rd comment is that there was a bunch of discussion
          about WG's history of not styling form controls
  dbaron: 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...
  dbaron: Web Components is a thing now
  dbaron: Part of the idea of the origin of WCs was to help us figure
          out how to expose styling of form controls to the web
  dbaron: We should at some point think about what we can do that is
          still web-compatible; we have more compat constraints now
  bkardell: It would be helpful to work with people how make custom
            control libraries
  bkardell: I want to be in control of these things, but not these
            things? it's not simple
  Rossen: there will always be native controls
  <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

  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
  jensimmons: If we wanted to pull those concerns up, the web should
              get the password off the web page, I wonder if the genie
              is already out of the bottle
  jensimmons: I don't have any answers, but there's something
              interesting there
  jensimmons: solving passwords on the web ... not going to happen here
  fantasai: I don't think Web Components is the answer to all of this
  jensimmons: We'll get to the form controls eventually, just ship
              these pseudos for passwords?
  <tantek> Does the CVV use-case apply here? (e.g. is that a use-case
           for -webkit-text-security ?)

  AmeliaBR: Is there any interest in browsers that don't have this
            feature, adding this feature?
  AmeliaBR: 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
  AmeliaBR: 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
  AmeliaBR: not sure whether it's a security concern, but it would
            expose info that's not already exposed
  AmeliaBR: which may be something to consider
  AmeliaBR: and the discussion maybe should happen at a DOM/HTML level
  AmeliaBR: On dbaron's concern about circularity, don't think it's an
  AmeliaBR: 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
  AmeliaBR: and the UA sheet can say do something based on it
  AmeliaBR: 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

  myles: When we discussed text-security a year ago, we spent a lot of
         time talking about the behavior of mobile browsers, where you
         press a key and it shows for 0.5s
  AmeliaBR: It's a state that exists only as long as you're pressing
            the key, vs on or off
  myles: It's per character tho
  AmeliaBR: As you're typing? the character you just typed?
  myles: Yeah

  una: I liked AmeliaBR what you said about HTML
  una: Reminds me of the media control state
  una: it lets them decide whether to show the widget
  AmeliaBR: So the author could make a custom control that toggles the
            password reveal state?
  una: Yes
  AmeliaBR: Currently most impls switch the input type from password
            to text, awkward for a11y
  AmeliaBR: bad for autofill
  AmeliaBR: if authors could impl a custom password reveal without
            changing the fact that it's password...
  florian: That's what we resolved 1yr ago, not that it was a DOM prop
  florian: The details of whether it's showing only the last char, or
           the whole text, that's "auto"
  florian: but only applies to input elements
  florian: We didn't follow up on that, but we did resolve it
  AmeliaBR: That doesn't let the custom control detect whether the
            user agent can turn the revealing on and off
  florian: Should we reopen that 1yr old question to see whether we
           should have it in HTML/DOM instead?

  tantek: I think we want this for cvv fields too
  tantek: so yes
  florian: The control we have didn't allow you to hide things. Only
           reveal things which are hidden by default
  florian: didn't want them to make normal text fields look like
           password fields
  florian: The earlier resolution, we decided we only needed auto/none
  florian: When WebKit brought this to the group, was to stop having
           non-password fields for password-ish purposes
  tantek: That sounds like denial of the use case
  florian: Does sound like we should reopen that issue
  florian: Should we be able to hide things revealed by default, and
           whether it should be a DOM thing

  myles: Search fields often have a magnifying glass image. If this
         will have an icon thing, it should use the same mechanism
  Rossen: In Edge, it's the same mechanism. There's an action pseudo,
          for clear, search, reveal

  hober: Can't resolve to add the pseudo class but also have
  tantek: It's not optimal
  dbaron: Needs to be clear what the two things do. it's still possible
  emilio: Could have weird states with non-revealed text but still
          matching the pseudo
  fremy: [...] if the user clicks the button it would override what's
  dbaron: Does input-security control whether there's a reveal button
          or not?
  dbaron: Someone needs to write down a definition, to check whether
          the input-security is reasonable, the pseudo is reasonable,
          and whether they interact well or not
  AmeliaBR: I think we've brought up a number of issues, would be
            worth updating the explainer/proposal to hash out these

  AmeliaBR: and generalizing to other action buttons. greg's not here,
            just throwing it back on him...
  jensimmons: From Greg's tweets sounds like he's diving into stylable
  tantek: 3 interrelated issues, resolving on one will make it harder
          to make sensible resolutions for the others
  florian: Come back with a complete proposal
  tantek: Hoping the "things that want a reveal button which are not
          password fields" use case can be handled

  -- 15 min break --

Received on Saturday, 6 July 2019 20:56:14 UTC