- From: Dael Jackson <daelcss@gmail.com>
- Date: Sat, 6 Jul 2019 16:55:17 -0400
- To: www-style@w3.org
=========================================
These are the official CSSWG minutes.
Unless you're correcting the minutes,
Please respond by starting a new thread
with an appropriate subject line.
=========================================
Selectors
---------
- 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
:has()
- 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.
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/toronto-2019
Present:
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
Selectors
=========
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:
https://html.spec.whatwg.org/multipage/media.html#htmlmediaelement
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
gone
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
pseudos
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
state a bit: NETWORK_EMPTY, NETWORK_IDLE, NETWORK_LOADING,
NETWORK_NO_SOURCE
<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:
https://thewebahead.net/110
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
UI
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
orthogonal
tantek: and looking at the HTML spec now, it's more granular than we
need
<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
stalled
tantek: Are you asking for new HTML specs rather than new property
values?
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
different
<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
different
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
forward
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
that
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
HTMLMediaElement.muted
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)
https://github.com/w3c/csswg-drafts/issues/3821#issuecomment-498688636
Mutable-Volume Pseudo-class
---------------------------
https://github.com/w3c/csswg-drafts/issues/3933
hober: This one is similar to the other cases. It's a bit weird
though
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
that
TabAtkins: :volume-locked
TabAtkins: Expresses the semantic that you'd style on, doesn't need
:not()
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
descendant
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
useful
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
them
hober: I think it's a good argument for going with the one off for
now
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
coherent
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
pseudo-element
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
states?
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
box
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
customizability?
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
field
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,
background-image
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
proposal:
<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
it?
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
this
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
matches
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:
https://developer.mozilla.org/en-US/docs/Web/CSS/-webkit-text-security
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
now
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
issue
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
tho
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
input-security
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
set
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
details
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
controls
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