<dbaron> Meeting: Cascading Style Sheets (CSS) Working Group Face-to-face meeting
<heycam> ScribeNick: heycam
<Rossen_> Rossen Atanassov, Microsoft
<astearns> Alan Stearns, Adobe
<flackr> Rob Flack, Google
<jihye> Jihye Hong, LGE
<oriol> Oriol Brufau, Igalia
<dbaron> L. David Baron, Mozilla
Cameron McCormack, Mozilla
<TabAtkins> Tab Atkins, Google
<AmeliaBR> Amelia Bellamy-Royds, Invited Expert
<stantonm> Stanton Marcum, Amazon
<koji> Koji Ishii, Googe
<jensimmons> Jen Simmons, Mozilla
<tantek> Tantek Çelik, Mozilla
<rachelandrew> Rachel Andrew, Fronteers
<bkardell_> Brian Kardell, Igalia and Open JS Foundation
<dauwhe> Dave Cramer, Hachette Livre
<florian> Florian Rivoal, Invited Expert
github: https://github.com/w3c/csswg-drafts/issues/3821
<iank_> Ian Kilpatrick, Google
hober: we currently have playing
and pause pseudo classes, which media elements match when they
are playing or paused
... the use case is, things like custom media controls, with a
unified play/pause button
... there are a handful of other common media element states
that have a similar rationale for exposing to CSS
... stuff that people are currently using script for
... this issue is the 3 easy ones
... 1 is whether or not the element is muted
... you may have a mute button, styled volume slider
... very similar to playing/paused
... hope it's uncontroversial
... other 2 are a bit weird
... the HTMl spec has a concept of media being stalled
... and you can see examples of custom UI when media is stalled
on popular sites like YouTube, netflix
... the spinner looks different
... if we could provide styling for that it would be nice
... 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
... 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
... just need something in CSS to expose them
... 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
<Zakim> dbaron, you wanted to ask whether :muted would cover tab-level, app-level, or system-level muting (I suspect not, but want to ask)
dbaron: there's ofte na lot of
ways to mute something
... 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 shouldb e tied to the host lang's definition
dbaron: ok so the HTML definition
<Zakim> tantek, you wanted to ask about "buffering" vs. "streaming connection broken" (have seen different UI)
tantek: I like the general
direction of the proposal, +1 on them. even the less common
features
... this shook loose memories of things I worked on right
before Mozilla, doing HTML5 consulting, setting up video
UIs
... took a bunch of notes which I forgot about that
... I needed this in 2010
... the :stalled pseudo class, I've seen different UI between
buffering to show something, vs the network connection is
gone
... even if you're in this "I want to play" state
... wondering if it's worth distinguishing
hober: I agree there's a use case there
<florian> +1 to tantek
hober: I think network state is a little more general. that's going to affect hte page, not just the media elements
tantek: but that's a differnt can of worms
hober: I'd rather tacklet 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
... some HTML spec refactoring is needed anyway, for
stalled
... from our perspective, we'd defer to the host language
<jensimmons> do these apply to <audio> as well as <video>? I’d assume so…
tantek: specifially the HTML media element interface?
hober: yes
emilio: images have differnet set
of states. broken, loaded. Gecko hsa internal pseudos for
these
... I wonder if it is useful to try to expose a common set of
pseudos
fremy: I was going ot suggest the same
hober: in the past when this has
come up, we've agreed we should have more general subresource
state exposing
... was hoping to not get bogged down on that too much
... there's specific use cases for media in custom media
controls
<tantek> note that the HTMLMediaElement does distinguish network state a bit: NETWORK_EMPTY, NETWORK_IDLE, NETWORK_LOADING, NETWORK_NO_SOURCE
hober: I agree it should be
coherent with a more general thing
... so we should keep that in mind
... but the last few times it's come up over 10 years, we end
up not doing it
<dbaron> https://github.com/w3c/csswg-drafts/issues/3134 is about image state pseudo-classes
<Zakim> fremy, you wanted to talk about additional states
fremy: we don't need to standardize pseudos for all possible cases
<jensimmons> anything to make doing this kind of stlying possible, without replacing everything with JS, would be ideal: https://thewebahead.net/110
fremy: you say you're sticking to the HTML spec's state. ther'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.
... in the specific cases for media controls you do want to
know about the network state
... in my initial proposal it was with video in mind. I think
it's a good idea to see how we can map them
... 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
... two specific questions
... 1st, the current definition of playing says it subsumes
seeking and stalled
... keeping that?
hober: yes
TabAtkins: ok cool. 2nd, :muted
is good, do we want a general volume state? low-volume
high-volume?
... currently, if you set the volume from script, and it
doesn't work, you can tell?
hober: yes
<fremy> @hober: `:user-locked-volume` ?
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
... if it did, I would expect it to affect this
AmeliaBR: either way there's a clear defn in HTML? and it's already exposed to script?
hober: yes
... AmeliaBR proposed :adjustable-volume. so it's the opposite
of that
TabAtkins: :volume-locked
... expresses the semantic that you'd style on, doesn't need
:not()
... 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/
hober: on Windows, muted and volume are independent states
:volume( locked || muted || <volume-value> )
<volume-value> = [ '<' | '>' ] '='? [ <number [0,1]> | <percentage [0%,100%]> ]
<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
... but I concede the point it's a system wide thing
jensimmons: request a few quick examples in the thread
<TabAtkins> :volume(locked < 50%), for example
hober: of Tab's syntax, or when you would use this?
<TabAtkins> :volume(muted)
jensimmons: when you'd use it
<hober> div.controls:volume(locked) .volume { display: none; }
TabAtkins: for :volume(locked), you'd display:none your custom volume button
AmeliaBR: should the pseudo refer to the fact that the volume control works or wouldn't work
hober: my case is for the latter
<TabAtkins> `video:volume(locked) + .controls > .volume { display: none; }`
hober: shouldn't display if it's going to be futile
fremy: if you set vol to 0, that stil lmutes the video?
hober: depends on the
platform
... not on Windows. unmuted at volumnet 0
... 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 prev one, wondering if this is practical as a pseudo, given the controls aren't usually a descendant
hober: it's often a sibling
... that's the same as the existing :play / :paused
pseudos
... I really like Tab's locked suggestion. either as the one
off or the general proposal
... 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
RESOLUTION: Add :volume-locked.
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
... to make sure we answer the use cases that exist
... would anyone be interested in working on that with me?
florian: there's a long tail of
something somethin within that are all kind of reasonable. but
not reasonable to have 50 different selectors
... I think there were impls constraints in Gecko that within
is doable, you can do 2 or 3, but not 50
... 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()?
... 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
... do don't need to walk the whole subtree
<tantek> which issue are we discussion?
AmeliaBR: it's the diff between "focus changed, let's focus-within all the ancestors, vs generic selector match start from an ancestor"
fremy: for useful but less frequent, you could have a single bit
emilio: :something-within
fremy: but still have 50 different pseudso
<fantasai> florian: maybe just have an "other" bit that catches everything, and pull out the ones that are populare into their own bits
^ that's two lines up fremy
bkardell_: as an author this was
my #1 frustration
... 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
... people faimilar 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 impl it performantly ...
<tantek> what I'm hearing is: needs incubation
TabAtkins: it will never be performant to do body:has(...)
<tantek> let's punt it to WICG
<fantasai> emilio: you can use memory instead of time...
<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...
<tantek> bkardell: "need a group of people to figure out how to move forward"
fantasai: :has-child is a lot easier to impl, that would solve many use cases still
<tantek> sounds like a WICG effort
https://github.com/w3c/csswg-drafts/issues/3934
<fantasai> 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 clas
fantasai: for when passwords have a show the password switch
dbaron: [demos what the Windows
UI looks like]
... in many cases, users with good 30 char passwords, want to
make sure they didn't make a typo
... Edge has this, and it's nice
hober: sites work around this by writing terrible scripts to change input type=password
emilio: that is a security issue
hober: harder for password autofill to work
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 pw is revealed
<chris> Android also has this reveal-password button
dbaron: the other is a pseudo element, that matches the toggle thing, so you can use a different image for it
fantasai: my qn is, is it important to make this stylable?
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
<tantek> the "x" button? is that the "clear field" button?
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
... at the time, it was a prefixed impl
... most sites ended up with two "x"s, or two reveal
buttons
<fremy> @tantek: yes
Rossen_: having a predictable way to turn it off, at least, is why we ended up with this being stlyable
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 contrls be looking native? stylable?
<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)
fantasai: but it should be keying
off the font?
... should use the same color and size as the text inside the
box
Rossen_: by default that's our
Edge behavior
... not sure what every author will want
... 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
... makes sense to adjust the element with a pseudo. that's a
common pattern, would be good to make it easier for
developers
florian: 2 points. I'm confused
by the pseudo class, not so much with the pseudo element apart
from hiding it
... just changing the color of it sounds weird if you don't
know really what it is
<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: second, we have from a
year back, a resolution for something that hasn't made it into
a spec, which is complementary to this
... opt in for a non-password field to look like a password
field
... I think we resolved on something in CSS UI to opt in to the
hidden display
... these two thins probably interact
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
Rossen_: and it could have
state
... if it's sticky, e.g.
<astearns> yeti peeking at your password UI: https://codepen.io/ankitashodhan/pen/mxxjpY
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
... someone might want to put a red border around the input
when pw is revealed
... I think CSSWG so far has been reluctant to allow styling of
form controls
... 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:
myles_: this idea of the reveal pw icon is a good one
RESOLUTION: input-security: auto|none in UI 4 and applies to input type=password only
<bkardell_> is it actually a newer control?
<fremy> https://github.com/w3c/csswg-drafts/issues/2495#issuecomment-380397331
myles_: if sites start changing
icons, maybe every site will have a different looking passwrod
field
... which is harmful for web security
... trains users to type pw into sketchy things
<fantasai> myles: good proposal, but replacing image seems problematic
<tantek> But Google does it (changes the icon) so it must be ok right?
myles_: on iOS it's a deliberate feature to make input type password look the same as system password entry fields
chris: we don't allow style sheets to change the lock icon in the address bar
<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
fremy: but you're already shipping input-security
AmeliaBR: heard a strong need for
something not in the proposal, which is detecting whether the
UA will be displaying a pw reveal
... or the clear field button
... argument for styling is more superfluous
... from usability perspective, having these things look
different everywhere isn't necessarily good for users
... I was fighting recently with a site that was breaking the
pw reveal button, because the focus kept getting lost
... could imagine all kinds of way s 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
... 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
... I can see the perspective of wanting similar UX
... right now things look diff because people must reimpl
them
... so I think it could help with unification
... having a standard for pw fields
... 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 validating want to little check mark in there
... should we be thinking about form elements as a whole?
fantasai: that's a good point
that that exists
... placing that check mark and making sure it doesn't overlap
the contents of the field. this doesn't solve that
... 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?
una: I've seen very design system have different designs for these elements, so I think the demand iwll continue
Rossen_: so eveyrthing else would look as designed, except hte 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
... can't really mix and match them
dbaron: I had three comments. one, AmeliaBR asked how do you detect this
<dbaron> @supports selector(::reveal)
dbaron: one answer is that you
could use @supports for this selector
... impls would only suppor this selector if they have a pw
reveal mechanism
TabAtkins: I don't like that assumption. then they'll have broken style rules
AmeliaBR: that already hapepns with pseudos everywhere
<fantasai> ...
<fantasai> dbaron: Somewhat, but also today's impls don't support that pseudo
<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
<fantasai> scribeNick: fantasI
<fantasai> dbaron: If that property has influence on whether the reveal pseudo-class matches
<fantasai> dbaron: then we can't do both
<fantasai> dbaron: You can't have a property that controls whether a selector matches
<fantasai> dbaron: This is not a problem for the pseudo-element, though
<fantasai> dbaron: We don't want to create cycles with input:reveal { input-security: ... }
<tantek> FYI: https://github.com/w3c/csswg-drafts/issues/2495
<heycam> ScribeNick: 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
... not to hide it on non-pws
fantasai: that problem still
applies
... just limited in scope to input
dbaron: the 3rd comment is that
there was a bunch of discussion baout WG's history of not
styling form controls
... 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
... Web Components is a thing now
... 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
... we should at some point think about whta 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
... I want to be in control of these things, but not these
things? it's not simple
Rossen_: there will always be native controls
<tantek> Also FYI: https://developer.mozilla.org/en-US/docs/Web/CSS/-webkit-text-security
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
... 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
... I don't have any answers, but there's something interesting
there
... solving passwords on the web ... not going to happen
here
<tantek> Does the CVV use-case apply here? (e.g. is that a use-case for -webkit-text-security ?)
fantasai: I don't think Web Components is the answer to all of this
<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: we'll get to the form controls eventually, just ship these pseudos for passwords?
AmeliaBR: is there any interest
in browsers that don't have this feature, adding this
feature?
... 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
... 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
... not sure whether it's a security concern, but it would
expose info that's not already exposed
... which may be something to consider
... and the discussion maybe should happen at a DOM/HTML
level
... on dbaron's concern about circularity, don't think it's an
issue
... 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
... and the UA sheet can say do something based on it
... 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 talkingabout 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 char you just typed?
myles_: yeah
una: I liked AmeliaBR what you
said about HTML
... reminds me of the media control state
... it lets them decide whether to show the widget
AmeliaBR: so the author could make a custom control that toggles the pw reveal state?
una: yes
AmeliaBR: currently most impls
switch the input type from pw to text, awkward for a11y
... bad for autofill
... if authors could impl a custom pw reveal without changing
the fact that it's pw...
florian: that's what we resolved
1yr ago, not that it was a DOM prop tho
... the details of whether it's showing only the last char, or
the whole text, that's "auto"
... but only applies to input elements
... 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
... so yes
florian: the control we have
didn't allow you to hide things. only reveal things which are
hidden by default
... didn't want them to make normal text fields look like pw
fields
... the earlier resolution, we decided we only needed
auto/none
... when WebKit brought this to the group, was to stop having
non-pw fields for pw-ish purposes
tantek: that sounds like denial of the use case
florian: does sound like we
should reopen that issue
... should we be able to hide things revealed by default, and
whether it should be a DOM thing
<fremy> @myles @myles_ why did you mention this to me: // text-security was implemented in 2007, 12 years ago
myles_: search fields often have a manifying 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?
... 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
AmeliaBR: I think we've brought
up a number of issues, would be worth updating the
explainer/proposal to hash out these details
... 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 pw fields" use case can be handled
-- 15 min break --
<tantek> heycam++
<dbaron> github-bot, end topic
<TabAtkins> ScribeNick: TabAtkins
astearns: The jan meeting is set for Spain, as I understand?
dbaron: Dates?
<bkardell_> here's a thing with the venue https://webengineshackfest.org/2019/#venue
Rossen: So Igalia hosting, location is A Coruña
dbaron: There's a moz all-hands
the following week, if we use the Jan 20-24 dates
... But Moz people thus can't do the following week. Either
week before or after.
jensimmons: Yes plz don't leave an empty week before Moz Berlin all-hands and this meeting...
<chris> TPAC 2020 Tentative dates 26-30 October 2020
TabAtkins: Probably no Houdini, we'll have talked at TPAC.
AmeliaBR: So W-F leading into Moz the next week seems best?
Rossen: So tentatively 22-24.
RESOLUTION: Jan 22-24 for A Coruña meeting, pending final approval from Igalia.
bkardell_: Igalia confirms that 22-24 works.
[Spring meeting will be at Apple, tess and myles will confirm room availability)
dbaron: How many meetings this next year? 13ish months between TPACs, tentative wiki plans are for 3 meetings now.
[discussion about france in August]
[definitely not doing Tokyo during olympics]
<rachelandrew__> the spring meeting - do we have rough dates? I have conference organisers to get back to
hober: We might be able to do two next year, haven't hosted in forever. We'll see.
florian: Maybe do Spring in Japan, then somewhere else in August.
una: ... Could probably do NYC Google.
astearns: I could host in 2021 in
Noida, India
... In Spring, the best time to go there
<br type=lunch dur=1hr>
fantasai: We're now on Echidna,
so we can publish in about 5min normally.
... ONe of the goals of that was to publish more
frequently
... I think when we have signif changes we shoudl check with
the WG to make sure everyon'es on board,
... But there are a lot of things where I think the editor
should just be able to publish. Particularly editorial
changes.
... So I propose we allow the editor to just push that to
TR.
... Or other obvious bugfixes.
florian: Probably also if we've resolved toa ccept specific wording
fantasai: Yes
... But if there's a change that should be reviewed by
somebody, like we resolved on a decision but not specific
wording, and it's non-trivial, that should probably also still
go thru the WG.
... But for editorial changes, trivial bugfixes, and
resolutions with acceptance of specific edits, we should let
people push
chris: Up to editor's discretion?
fantasai: Editor is fine for me. Could push thru chairs, just not waiting for the WG call.
<fantasai> has to be very very trivial, though!
AmeliaBR: Is there an intermediate state, where you ping people first?
astearns: I think if you're
concerned, this isn't one of those cases.
... I'd like a ping when things are published.
<fantasai> TabAtkins: Echidna can CC an address or ML when publication is succesful
TabAtkins: Echidna now has a cc feature, pass `-cc=email@example.org` to the bikeshed command to ping it when publication is successful
<Zakim> tantek, you wanted to request that we have a requirement of adding to the Changes section, and preferably even an HTML diff as well, just because that *should* look minimal for
tantek: Strongly
supportive.
... The more we can desync publishing and make it rapid is a
good thing.
... Only request is that if you publish what you think are
editorial changes, you still include changes about that,
preferably with a link to a diff.
TabAtkins: W3C has a nice htmldiff tool useful for this, too
chris: This is for WD, reqs for updating other things stay the same
dbaron: one possible concern,
sometimes we get into big arguments where the result of "we
can't agree on anything" is "therefor we make no change"
... I don't want this to have too much implication for that, in
that "therefore we make no change" should stay "therefore we
stick with the previous resolution".
florian: Agree, but think that's
a chairing issue.
... If there's disagreement, chairs can decide that we should
stick with a particular wording.
TabAtkins: That seems to fall under the intended rule of "don't make non-trivial changes under this process"
florian: Other types of changes allowed here is adding examples and inline issues.
fantasai: Those are editorial
florian: Technically not true under W3C process, but let's stick with the definition of "non-normative, non-controversial" as the dividing line
fantasai: yes
astearns: Do you think you should still have one person review? I've made "editorial" edits that still cause problems.
???: It's fine, people can review after the fact and then just push the fix.
AmeliaBR: Yeah, and the faster update cycle can fix issues we've had in the past with markup errors sticking around for a long while.
tantek: Adding non-trivial informative changes, like adding examples, could probably *use* some review, but we shoudln't require it in the process.
fantasai: As my goal I just wanna close the distance between ED and TR, so TR becomes more of a useful resource.
astearns: I want to avoid ahving this quick process meaning you hold off on normative changes bc you want to publish the editorial.
fantasai: I don't think that'll generally happen.
tantek: In the interest of not blocking on that, do we already have a custom of letting people be first in the telcon agenda if you have a pending publication?
astearns: Yeah, nearly
always
... So proposal is to allow editors to publish to TR at will,
when the only changes are non-normative/editorial and
non-controversial.
[discussion over difference between "uncontroversial" and "non-controversial", concluded that when there's a difference it should be considered controversial]
fantasai: And must include in the Changes section that the only changes are non-normative, with a link to the diff.
astearns: And ping www-style with
the publication.
... Anyone object?
fantasai: Also allowed: substantive changes when the WG has already approved the exact wording
RESOLUTION: Allow editors to publish at-will, under the discussed caveats.
RESOLUTION: WDs with only editorial changes, non-normative non-controversial changes, and/or substantive changes with exact wording approved by the WG may be published by the editor straight to /TR without explicit approval, providing that a diff of changes is linked and www-style is pinged.
fremy: This is mostly editorial, but I still want to run thru the group.
fremy: Gonna explain the changes.
fremy: Second, skipping ahead,
question was around % for height of table cells
... Mosty this change just moves text around.
... Previous section was called "computing the table height",
but it had details about resolving %s and other stuff
... Hard to find that text, not in a good spot.
... So I just lifted it to a new section so it's more
clear.
... Just wanted to bring it up if someone wants to review and
make sure I didn't change anything.
Rossen: LIne 1896, that's a normative change...
fremy: Ah no, that's already implicit in the rest of the spec.
Rossen: But it's not just moving around.
fremy: Yeah, it's a clarification.
Rossen: My point is that here you're defining an algo that says something has no effect. That's not just an editorial change.
fremy: It's editorial in the sense that it's already normative in the spec elsewhere. This shouldn't be a behavior change, I'm just summarizing the effect of other stuff in the spec.
florian: New text, but no new requirements.
<tantek> editorial vs. substantial vs. normative are all different things, please don't try to collapse any two
astearns: It's often good in those situations to just link to the section saying that, rather than duplicating.
AmeliaBR: These are literally consecutive paragraphs, in one subsection
fremy: First link, actually adds
something.
... In spec there was a sectiond defining positioning of
everytrhing inside the table
... Described for each of them the left/top/width/height.
... I assumed it was obvious this was the bounding box, but
that wasn't obvious in the spec.
<fantasai> tantek, https://www.w3.org/2019/Process-20190301/#correction-classes
fremy: So I've officially defined that this is the dimensions of the box, returned get gBCR().
florian: What's the alternative interpretation of this?
fremy: Like, the tech was only necessarily about visual stuff. Not clear that it affected the .offsetLeft, etc.
<tantek> fantasai: I agree with those distinctions, glad to see that there are *four* made explicit
<fantasai> tantek, yeah, the resolution above was only wrt to #1/#2 -- unless exact text for #3/#4 was WG-approved already
fremy: Also clarified what border-spacing means with spanning cells, etc. Obvious in formula, but made it clear in prose.
<Zakim> dbaron, you wanted to ask about table wrapper versus table
dbaron: In the first bit, I'm a little nervous about "which means they are accessible via..." because of table vs table wrapper box, because only one of those is accessible to the OM
fremy: Which is used for those APIs is already specified.
dbaron: Yes, but then your
statement of fact there is slightly wrong.
... You give bounding rects for both table and table wrapper,
but only of those is accessible via the OM, so the statement
that the definition "makes them accessible" is technically
wrong.
... Perhaps add a parenthetical about the boxes that aren't
OM-accessible.
fremy: Sure
... And the third diff is Elika's editorial changes to the
propdef tables, to be consistent with the rest of the CSS
specs.
astearns: I'm hearing no objecteions to publication
RESOLUTION: Publish new WD of Tables 3 with the reviewed changes.
<fantasai> I've updated https://wiki.csswg.org/spec/publish with the blanket publication resolution
<fantasai> fwiw
<astearns> github: https://github.com/w3c/csswg-drafts/issues/3739
emilio: Browsers have minimum
font-size settings for a11y
... And they work differently in WK-based vs Firefox
... WK-based browsers, it affects the font-relative
units.
... In Firefox they do not.
... So I was considering implementing min-font-size, and that
affects the computed value of font-size, I would assume
... So first, the a11y setting in Blink can break
websites
... I'd also like min-font-size to work the same as the a11y
setting.
fantasai: Reason it affects computed and not just used font size is that if you were using ems correctly (for the purpose of making something relative to text size), then everything should scale and match the size of text.
AmeliaBR: How much would things break if we declared a different computed value for inheritance vs font-relative units?
dbaron: Which is what I thought Gecko did, and maybe what it did pre-servo
fantasai: That would be fine and would honor the constraint we want
emilio: Would it?
[Amelia re-explains their proposal]
<fantasai> TabAtkins: So on any given element, 1.2em would still be 120% size of the text
emilio: That would still break websites if we used this to ipmlement the a11y setting
<fantasai> dbaron: people use the root font size to create a unit that's not really related to the font size, and that breaks if you apply font size minimums to it
dbaron: I think this is also significantly problematic because of people misusing rem to get a custom-sized unit
jensimmons: And they want nice math, yeah
myles_: So it sounds like users are getting min-font-size via the UI settings; could you just keep that separate from min-font-size property?
emilio: Yeah, we could. But it would still mean the minimum font size setting is magical; you couldn't override that in a user stylesheet.
dbaron: Also one of the underlying principles of CSS is that it explians how author and user expectations work with each other. Settings/prefs are usually explained as part of the user stylesheet.
myles_: Right. There just might be a distinction between an author saying they want to scale up a font size, and the user saying they can't see text smaller than a certain value.
dbaron: Also, minimum font sizes don't seem to work well in practice anyway, many pages break. So maybe this isn't the most useful anyway.
fantasai: So if authors do understand the unit and use things correctly, things should still scale correctly.
jensimmons: So to clarify,
there's a min/max-font-size, and maybe you set font-size with a
calc(vw) or whatever.
... So if you hit a min or a max, and we cap it when you hit
the limit, should that propagate to the 'em' unit, that's the
question, right?
<chris> yes, exactly
[yes]
jensimmons: It doesn't even make sense to me that it wouldn't transfer over.
<florian> +1 to jensimmons
<Zakim> AmeliaBR, you wanted to talk about author use of min/max-font-size
<fantasai> /So/CSS provides a variety of units to allow authors to express the why of their sizes through relative measurements, against the font or the screen or the container or the pixels, etc. Authors who understand these units will use font-relative units when they want things to scale with the font, so/
AmeliaBR: So while CSS gives people the tools to use things properly, we have to recognize that some people won't use it correctly.
<fantasai> jensimmons gives an example of e.g. gmail which doesn't handle the scaling of text correctly, so zooming in creates a suboptimal layout -- but this is a case of the author not choosing to use the correct units ; breaking the connection between ems and font-size would make it impossible to fix
dbaron: I think I agree that making 'em' honor min/max is the only thing that makes sense. It's not clear to me which to go with inheritance, as it depends on use-case
fantasai: There was a comment from Fred Wang, where if min/max clamped the value before inheriting, you'd have a size in the multi-step process that gets messed up and messes up all subsequent sizes.
<leaverou> Agreed with dbaron. Authors use ems assuming they correspond to actual used font size. If that assumption breaks, a lot of UIs would too.
<fantasai> fantasai: So I agree with Amelia that the computed / inherited font-size should not be affected by the min/max, but that the min/max should factor into not just the used font size but also the resolution of font-relative units
<fantasai> fantasai: We would be doing authors a disservice if we did not ensure that the font-size and 1em matched.
<chris> I agree with that proposed solution
<chris> ... otherwise things end up double-applied, growing too much
dbaron: I think this is a reasonable conclusion, I think it doesn't work well for Jen's use-case, but I think what does work well for that is using min()/max() inside of font-size.
<chris> ... clamping should happen as late as possible
dbaron: Because you want clamping to happen at a particular point, not to be inherited down further into the tree. So you'd use `font-size: clamp(10px, ..., 36px);`
AmeliaBR: Right, and that would be bad for min-font-size, as then a `<small>` child would also get clamped and not get smaller. While clamp() works properly
chris: THis has been interesting. Not sure I could reproduce this aftera few days. I want some examples in the spec of what you should use each with.
<AmeliaBR> +1 to examples!
<fremy> (side note for people interested in this and would love examples, Jason Pamental talk at cssconf this year is a great resource)
TabAtkins: I think we're leanign toward the properties being designed purely for the a11y/settings use-case, and if you want to just clamp a value in a range, you should always use the math functions.
iank_: Currently the way we do this in Blink for a11y isn't via a property because the font-size clamping we do applies on a per-region basis.
myles: Ours is also complicated,
probably in a different way.
... It seems like dbaron was saying the function of CSS was to
explain browser features. It sounds like this feature shouldn't
be explained in CSS, and it should remain magic.
emilio: It sounds like Ian is talking about the text auto-sizing actually?
myles: Ah, but I wasn't in
mine.
... We have a lot of systems that interact to produce a text
size.
... I've spent a long time trying to increase readability,
and...
... The issue is "I want to use this CSS feature to do a11y,
but things break", then we just shouldn't use that feature.
florian: So what are we using these for?
<fantasai> myles: These were added before my time...
myles: These predate me, there was just a note in the spec and I started implementing
TabAtkins: These predate the math
functions; they were meant to implement the "keep vw-based font
sizes from getting too big/small"
... So we can just drop the properties, then
chris: I was looking at history; this looks like something that was dropped from Fonts 3, and Myles dropped it into Fonts 4 two years ago.
<tantek> agreed with TabAtkins
<tantek> proposal: drop the properties because not implemented anywhere
astearns: So these aren't implemented in a user-facing way anywhere, and we're not convinced they're good for any use-case...
<tantek> jensimmons: responsive typography is what the use-case is called, you can search for it
<fantasai> https://lists.w3.org/Archives/Public/www-style/2014Jun/0187.html
<AmeliaBR> `font-size: clamp(12px, 10vmin, 24px)` vs `font-size: 10vmin; min-font-size: 12px; max-font-size: 24px;`
astearns: So looks like we have consensus to remove these properties, until we have a use-case that min()/max()/clamp() don't serve.
AmeliaBR: And replace the section with an example of how to use clamp()l.
<tantek> aside: how do we do copy-fitting
RESOLUTION: Remove min-font-size and max-font-size from Fonts 4, replace with an example of using clamp() to handle safe responsive typography.
heycam: The effect of these properties on the computed value of font-size... still worth resolving on how these browser settings affect things?
<fantasai> ChrisL: Example of broken is page with <html style="font-size: 1px">. Answer is, don't do that.
<fantasai> TabAtkins: The way it inherits separately is a problem for designing a font hierarchy relative to a base size, tho
<fantasai> AmeliaBR: Should we give advice to browsers on whether font-relative units should be affected by browser settings?
<fantasai> myles: Arguments on both sides
<fantasai> myles: If we don't expose to authro, they don't know what happened to their page
<fantasai> myles: I don't think it should be specced
TabAtkins: Note tho that h6 defaults to smaller than standard font size. If min-font-size is set to standard-font-size (both 16px, say), and you defined your hX hierarchy by starting from h6 size and then calc()ing up the higher values, the Chrome behavior would mess things up; starting from h1 and calc()ing down would be fine. So it's not *all* pathological cases.
dbaron: To respond to myles
there's another tradeoffs around a11y
... Some users that need a11y are concerned about privacy, and
are willing to have the feature not work as well to keep secret
that they're using it.
TabAtkins: For this feature, no matter how you do it it'll be page-exposed tho
dbaron: Also, the browser minimum
isn't *really* a minimum.
... If you specify a min of 10px to font-size:1px, you get 10px
font. But applied to font-size:0px, you get 0px. That's very
important. So it's not a strict "minimum" anyway.
<fantasai> myles: Example is layout with inline-blocks, set font-size: 0px so that the gap below the baseline is zeo.
TabAtkins: Myles, wanna capture that 0px point in the spec? If everyone agrees something is needed for webcompat, it should be captured
myles: In a note, sure
<astearns> github: https://github.com/w3c/csswg-drafts/issues/3906
<fantasai> ACTION myles Add a note about the font-size: 0px vs min font-size web-compat issue
<trackbot> Created ACTION-879 - Add a note about the font-size: 0px vs min font-size web-compat issue [on Myles Maxfield - due 2019-06-11].
myles: I don't think we can get rid of the fact that monospace is special, for webcompat
chris: So this is really about
the fact that Courier looks too big.
... And browsers also noticed that CJK fonts can look too big
at 16px by default
emilio: in gecko we do this based on the generic family specified.
myles: So "a, b, serif" gets a different font size than "a, b, monospace"
dbaron: Yes, because of the assumption that those fonts are probably monospace as well
fremy: As I recall that's not what was implemented by browsers...
myles: In WK, we only adjust if
you say *only* "monospace"
... So using font-family to dictate font-size is fundamnetally
broken, we all agree
[we all agree]
myles: So the question is if we shoudl write down exactly how it's broken. it sounds like everyone does it differently
dbaron: Given there's incompatibility, there's maybe room to improve this
<fantasai> [emilio describes some details of how this works]
dbaron: AT one point I had part
of a plan to replace with with font-size-adjust
... Probably not web-compatible, but maybe... Would require new
values.
fremy: Last I recall Edge didn't do any adjustments, but at some point we got a bug and added new UA rules that only targeted elements that get monospace by default. We don't apply it to the *monospace value* tho.
<fantasai> TabAtkins: We should capture in the property that extra bit of information captured about whether size was specified as a size
<fantasai> TabAtkins: because browsers seem to do something special in that case
<fantasai> AmeliaBR: Keywords are a bit vague anyway
<fantasai> TabAtkins: No flexibility in that they convert to a <length>
<fantasai> TabAtkins: You honor a <length> as a <length>
<fantasai> TabAtkins: But that's not how browsers work
<fantasai> TabAtkins: We might need to keep it underdefined, but at least that there's some thing special going on
<fantasai> fremy: We have interop, so let's spec that
<fantasai> TabAtkins: OK, but let's capture there's something
<fantasai> emilio: Gecko code... when you have multiple families, we behave like WebKit
<fantasai> emilio: Yay interop!
<fantasai> AmeliaBR: so weird behavior, but cross-browser consistent
<fantasai> chris: So how are we resolving?
dbaron: The thing this was solving is really a use-case for font-size-adjust
<fantasai> dbaron: Like to say that the thing this was soliving is a use case for font-size-adjust
dbaron: I'd like to encourage the negine that doesn't ipmlement f-s-a to do that.
<fantasai> dbaron: Would like engine that doesn't implement font-size-adjust that doesn't implement it to fix it
<fantasai> dbaron: It's ugly because it's designed to be compatible with its non-existence
<fantasai> dbaron: It's a way of saying "i want to specify font-size in terms of x-height instead of font-size"
<chris> https://developer.mozilla.org/en-US/docs/Web/CSS/font-size-adjust#Browser_compatibility
astearns: So it sound slike
proposal is to acknowledge reality in font-size property that
it makes font-sizes strange.
... And at minimum capture "it's strange" in the spec.
<dbaron> oh, actually, font-size-adjust may be behind the experimental web platform features flag in Chrome...
<fantasai> TabAtkins: Let's capture that keywords come with extra bit of info
<fantasai> TabAtkins: And also investigate if there's compat, andif so spec that
<fantasai> myles_: sgtm
astearns: Is there someone volunteering to do the investigation?
fremy: I volunteer.
astearns: proposal: acknowledge reality that font-size keywords have some weirdness with particular generic font families.
RESOLUTION: Capture that font-size keywords carry an additional bit of information having some (unspecified) interaction with some font families.
astearns: Second is to deputize françois to try and capture what the weirdness is
RESOLUTION: François does compat research on the effect of font-size keywords and generic font-families, and report back on interop.
<astearns> github: https://github.com/w3c/csswg-drafts/issues/3746
bkardell_: In doing Chromium impl
of mathml, and trying to explain the mathml magic in a way
that's part of the platform, there are some funky areas
... So we want to get that funky added to CSS.
<AmeliaBR> Explainer link: https://mathml-refresh.github.io/mathml-css-proposals/math-script-level-and-math-style-explainer.html
bkardell_: One is math-style. As
part of layout, takes into consideration whether your math
equation is happening inline in text or as a block; aligns
baselines differently and tries to minimize vertical size in
inline, etc.
... If we have that, this is one more thing that becomes a UA
stylesheet rule.
... math-script-level is in my mind a lot like counters. It
lets you scale up or down font-size
emilio: So when you nest an
element that's a subscript or superscript, or part of a
fraction, the font-size shrinks.
... But in CSS it affects the computed font-size, which is
annoying.
fantasai: This effects the font-size. Why is it called script-level, and why is separate from font-size?
bkardell_: This is how I think it's similar to counters, it carries info about nesting.
AmeliaBR: So elika's question is why not do this with relative font sizes. I think reason is to give browsers some more flexibility...
fantasai: We can have math-larger and math-smaller...
fremy: If you have a fraction, 1/2. You can nest, 1/(1/2). But third level of nesting, switch to a side-by-side fraction.
bkardell_: Even within that context, you can have sub/superscripts too.
AmeliaBR: There definitely needs
to be a new property. Math fonts have a property saying how
much you scale down as you go down a script level.
... Do you need to be able to absolutely set "3 sizes down from
normal", or is it always single steps?
bkardell_: These map stragiht from MathML attributes. I know the name isn't great, but
emilio: Figuring out which nodes need to incrmeent or decrement the script level is pretty tricky
<AmeliaBR> `font-size-math-adjust`???
emilio: It would be good to see if we can decouple the script-level from font-size, because it becomes much easier, add an "auto" value and figure it out doing layout or something
AmeliaBR: Does nesting level have effects other than font-size?
myles_: fremy said yes
<una> what about `font-size-math-adjust: <nesting-level>`
fantasai: So then you'd want to
*select* based on that level. So then that info must be in the
DOM.
... We've had similar cases in the past of things thought to be
in CSS that we pushed back and said "no, this needs to be in
the DOM".
... Like directionality.
<fremy> (yep, for the record I agree with fantasai)
dbaron: I think one of the
reasons for this is that mathml has attributes that specify
both the ratio of font-size for each change in script level,
and the min font-size at which you stop changing it.
... script-size-multiplier and script-min-size
fantasai: Does this mean we're adding font-min-size back?
myles_: There have been a half-dozen or so of these proposals. How do these affect existing elements outside of MathML?
bkardell_: Some people do indeed think that <math> isn't great, and math layout should be a normal part of CSS.
<una> `font-size-math-adjust: <max-nesting-level> / <min-font-size>`
florian: I think we want the
building blocks of math in normal CSS. And I've heard the
argument that MathML is bad for math; mathjax people will do
that.
... So mathjax renders math into HTML or SVG, but they're
missing some tools that make it subpar.
myles_: So what's the criteria here: hsould math layout be dumped in whole-hog?
<chris> https://www.w3.org/TR/MathML3/chapter3.html#presm.mstyle.attrs
bkardell_: We're trying to find
the mathml core and eliminate as much as possible.
... So far we've been doing good at that.
... Reusing CSS stuff well.
<chris> also https://www.w3.org/TR/MathML3/chapter3.html#presm.scriptlevel
astearns: I hear this as a request from another group, like the timed text people, to get something that they can't currently do in CSS.
<fantasai> TabAtkins: Is the goal that you can implement math layout with <div>s, or are we saying that mathml is a special layout form, like SVG, that can have its own specialized CSS without influencing arbitrary text layout
dbaron: There are two different groups in w3c working on diff solutions here
myles_: So if this is a generic layout mechanism, you need to be able to put flexbox inside of it
florian: I don't think we want to be able to take naive markup and get good math out of it.
<fantasai> TabAtkins: Are we intending that you can make a fraction, and the nuerator is a flexbox?
<fantasai> TabAtkins: If so, you can nest flexbox into it. If not, then you can't.
<fantasai> TabAtkins: But need to know which way we're going so we can figure out how to interact with it
<fantasai> chrisl: ...
<fantasai> TabAtkins: We'd make a Math layout spec
iank_: So basically mathml is
already in this state where you can nest CSS layout inside of
it
... And it uses CSS layouts to ahcieve some of its
layouts
... so <mtable> uses css tables
... The text inside of mathml is just text layout, it can do
floats/etc
... This was the feedback we gave to the group: you need to
define how this interacts with all of CSS.
myles_: ARe you saying that philophically that's how this shoudl be designed, or that it's just a quirk of impl.
Rossen: So support rich layout that allows math, and interacts nicely with the rest of css.
astearns: A detail is that some requirements, we may not get to. LIke western typography, some details we never get to.
myles_: So the intention is that we end up with display:math at some point?
AmeliaBR: display:fraction, perhaps, like display:ruby : some specialized focused layouts as necessary
<dauwhe> this is a w3c strategy funnel issue https://github.com/w3c/strategy/issues/43
fremy: So math-level.
... If you want a layout that's different depending on the math
level, that's fine. We could do that.
<dauwhe> https://www.w3.org/community/knowledge-domain/
fremy: But the way I see this is
that math-level is changing other properties, in some weird
interaction.
... So my mental model matches fantasai, this is at the DOM
level.
... And if we go the "you should do math using divs", that
doesn't work.
... My impression from when I worked on this, is that this is
complex to put in a CSS property.
... But if our goal is to allow everything in CSS, I don't see
how it's a markup thing.
... So question is we need mathml markup, or is there a
simplified markup that would provide the grouping/level/etc
that we could provide the levels on top of.
myles: So let's say we do wanna
go on this path where we induct math layout into CSS.
... When we write CSS specs we have to describe layout
exactly.
... Do you envision that this group would make those decisions,
or that MathML would do it and deliver them to us and we'd put
them into our docs?
bkardell_: Right now they're
trying to get that defined.
... Huge criticism right now is that it's super
underdefined.
iank_: As part of our launch process we require interop-capable specification.
<tantek> FYI: https://caniuse.com/mathml
iank_: And the two impls
currently aren't remotely interoperable, especially
layout.
... I spent two or three hours one day and created a list of
issues where Firefox and WebKit differ.
fantasai: If mathml is going to
define a layout model closer to css, they should def interact
with us more than what's happening currently.
... So we can make sure it's compatible with css layout and all
the interactions with othe rproeprties.
<tantek> Is there an opportunity for CSS/MathML joint meeting at TPAC?
fantasai: Just because of where the expertise lies.
astearns: I would really like to see more stuff in the explainer. Righ tnow it looks like a reiteration fo the proposal. It has some markup examples without intended renderings, etc.
fantasai: SAme, I don't really
understand what it's trying to do currently. So I can't even
comment on whether they're doing it right or not.
... So somebody came up with a solution to a problem, but I
don't udnerstand the problem, or why this is the best solution
to that problem.
... Would love to advise them, but can't right now.
florian: Back to fremy's point, for those trying to solve math with css, i don't think the goal is markup that resembles mathml and uses display:fraction, display:sqrt, etc. I think it was to start from a mathml-ish markup that is processed into a pile of divs, then rendering fractions with a vertical flexbox, etc. Only a few lacking aspects would need to be added.
fremy: I don't disagree, that's also an option. But if that's the goal then you don't need the math-script-level property.
myles: Agree. We already have SVG then.
TabAtkins: SVG doesn't quite solve it - we still need a few small things, like baseline control, stretchy characters. Talked about this at last TPAC. But it's pretty minimal.
AmeliaBR: So wrapping up, we have
some requests for Brian's team at Igalia about how we want
communication to happen, better explainers. larger
comprehensive use-cases, rather than one proposal at a
time.
... Would be useful if this group gave feedback about how we'd
like to be communicated with.
... And then there's further concern about where things should
live, CSS vs DOM, etc.
dbaron: elika was asking about
the problem to be solved. There is a political disagreement
about the problem.
... In that, there is the question of whether mathml is the way
forward.
... A few years ago when it was in Firefox only and we thought
we might remove it, everyone thought MathML wasn't the right
way to do it; do it in CSS instead, etc.
... And add to CSS to improve mathjax output.
... Now we're somewhat surprisingly getting to a world where
mathml is supported across browser engines.
... So question is whether mathml is, like html, something that
needs CSS to reflect on things in it.
... ARe we concerned with MathML backcompat such that CSS needs
to care about its legacy mechanisms.
... Or do we have substantial flexibility to change things as
necessary.
... So three possibilities:
... 1. MathML is in browser engines, CSS has to be compatible
with that.
... 2. MathML is in browser engines, but we might make
substantial changes in the process and can adjust it to CSS
better.
... 3. MathML isn't the right path forward, and math should be
taking this up the path.
... Path to making this decision right now is very
uncoordinated and not based on principles, but rather on lots
of small decisions where people might not be aware of the
larger path they're supporting.
... Possible we should be discussing this more
epxlicitly.
... I think before we decide waht we're trying to solve, we
might want to have that discussion.
bkardell_: Before I went to
Igalia, I spent a lot of time thinking about this.
... My own thought were between 2 and 3.
... HTML isn't very perfect semantically either, it's focused
on text.
... So it has no starting point. It's not like SVG, where we
all agree what SVG is.
... Thirty years the community has been working on something,
lots of back and forth.
... When we got to HTML5 and mathml was codified into the
parser, now it's in a special weird place.
... If there's something I'd personally advocate, it's that we
need to find a starting point or we can't have this
convo.
... So back with corp hat on, the core-math group is trying to
find the minimal bits that hold things together.
... I don't want to personally be like "mathml is the best
thing ever", I dunno. I want to be malleable here.
<br dur=20min>
myles_: Minutes of the Math session during last year's tpac: https://lists.w3.org/Archives/Public/www-style/2018Nov/0008.html
<dbaron> github-bot, end topic
<dbaron> https://twitter.com/tpsoperations/status/1135982093631152128
<fremy> ScribeNick: fremy
<emilio> koji: https://bugzilla.mozilla.org/show_bug.cgi?id=1418472
<astearns> github: https://github.com/w3c/csswg-drafts/issues/3988
rachelandrew______: there was a
resolution before I joined the group to mark percentages in
column-gap at risk
... but Firefox implemented it, and now the property applies on
grid and flexbox as well
... so they asked if the at-risk could get removed
astearns: do we have implementation report?
rachelandrew______: yes
astearns: does any other
implementation want to get it removed?
... I assume not since we resolved to allow it?
florian: yeah, I'd agree to remove because sometimes implementors are afraid to implement it
AmeliaBR: yeah, at-risk should be redefined to be less scary
florian: yeah, that's just the
name though, the description is already encouraging
implementation
... it would be nice to change the name at the w3c level, but
this hasn't happened yet
AmeliaBR: do we have tests to back this up?
rachelandrew______: yes, and on top of that we have tests for grid as well, where it is implemented
astearns: any objection to remove the at-risk commned?
iank_: there is only one test,
and that is a bit low
... we would need tests for intrinsic sizing etc
... but I'm ok to remove the at-risk
astearns: resolved then
RESOLUTION: remove at-risk percentages on column-gap (and add some tests)
<astearns> github: https://github.com/w3c/csswg-drafts/issues/3641
rachelandrew______: we define
column-gap in multicol and box alignment
... authors were discussing how confusing that was
... I'd rather define column-gap in alignment, and just mention
the specificities of column-gap for columns in multicol
florian: we kinda did the same thing for break properties, where they usually were defined in multiple places, and now we consolidated in css-break and we added notes to the other places
AmeliaBR: we should consider REC progress though, so we don't get stuck
fantasai: css-align is really
close to CR, so I don't think that would be an issue
... the only remaining significant source of issues is baseline
alignment
... and we could move that to the next level
AmeliaBR: then that seems fine
rachelandrew______: suggested edit is to add an heading to explain how column-gap works in multicol, but define in box-alignment only
astearns: any objection?
RESOLUTION: add an heading to explain how column-gap works in multicol, but define in box-alignment only
(and link between them)
fantasai: since christian raised
this issue, it would be good to have him on the line when we
discuss this?
... (this was a question)
astearns: we could move to the next one to see if we can get christian on the line?
<fantasai> cbiesinger: ping
iank_: (pinging christian on slack)
(cbiesinger dialing in)
<br type="technical" /> ;-)
astearns: cbiesinger can you summarize the issue?
cbiesinger: there was a change in
css-sizing spec
... now min-content does the same as the initial value
<astearns> github: https://github.com/w3c/csswg-drafts/issues/3973
cbiesinger: which is great for
height
... but for min-height for instance, this is a change in
behavior
... and in flexbox with auto, you can't get a specific effect
that you used to get before
... so we should probably redefine it again so that it does a
different thing by property
fantasai: makes sense to me
dbaron: the assumption is that it
was defined before
... but before it wasn't clear to me what it was actually
supposed to do
... you have block size that is derived from the content
... but it doesn't say which inline size is used to get that
layout done
... so in the general case, what would be that inline
size?
... is that a function of something else? how does it get
passed in to this?
cbiesinger: yay, that's
true
... the definition of the min-content block size still exists
in the spec though
... and it has this issue, so we need to fix this no matter
what
dbaron: sure, but I'm not sure we should have this in the spec at all
<AmeliaBR> min-content block size definition: https://drafts.csswg.org/css-sizing-3/#min-content-block-size
cbiesinger: in the common case in a column-flexbox, it defaults to min-height, min-content
dbaron: and how do you determine what that height is?
cbiesinger: you use the inline size you derive from the sizing properties
dbaron: so it's not really an
intrinsic size, it's a specific size that depends on the layout
you are in the middle of doing
... so we don't really need this concept for that case
... but for othogonal flows, you'd allegedly need the general
case?
fantasai: for orthogonal flows, you have to pick a size anyway
dbaron: so, ok, regardless, we need to define very precisely that inline size
iank_: is it true that in our implementation, the value is (...) ?
cbiesinger: yes, the post-layout size is (...)?
iank_: in our implementation, min-content and max-content were the same, and were the post-layout block size of this element, as if no other constraints were applied
^ clarifying the ... above
iank_: and it works thanks to the clamping
fantasai: I think it's very clear
to me that the change was not correct anyway
... so we should revert this edit anyway
... but I agree we should also make sure we get things defined
explicitly
... and maybe think whether min-content and max-content should
be the same
dbaron: and even if they are the
same, we need to define what they are
... but if we don't have a first-layout pass, sometimes it
happens?
iank_: for min-height/max-height you do, because you clamp an existing height
fantasai: so, yeah, using the
default value is wrong because sometimes auto is not
min-content
... I can't think of a reason for blocks to want min-content !=
max-content
... but for grid, we could trigger the different distributions
algorithms for them
... we should think about that
<fantasai> It's less clear that they should be different in this case, because there are different space distribution rules for each
astearns: so, I hear that we want
to revert, and try to get a definition for this
... even if there is some scepticism we can get a definition
that works
dbaron: I would also not want to
call them intrinsic if they are not intrinsic anymore
... it seems to me we are defining something else
entirely
... doing some of these things require major changes in some
algorithms, and I'm not sure what the use cases are
cbiesinger: min-height:min-content seems useful
dbaron: it is not impossible that
this could take a year for us to implement, and I'm not sure
this is worth
... there are some existing implementations, but did we check
that they match, and not are just superficially similar
... I am not sure
... so I don't want to take this lightly
... so I would rather have a full proposal
... so I can evaluate complexity, and evaluate the cost/benefit
ratio
... there are things that happen in gecko when you specify
these things of course, but are we interop? probably not?
emilio: I don't think we have impelemnted to block size that works in the block axis
TabAtkins: (pointing another case that seems wrong in gecko, even in the inline axis)
cbiesinger: agrees that some cases are difficult in the inline cases
TabAtkins: we do use an
approximation here, that was better than gecko that assumes a
single-column
... Edge had a good implementation
... but regardless, we didn't
... so I tend to agree that intrinsic isn't always as
"intrinsic" as the name implies
... it sometimes requires full layout
fantasai: how about changing the
spec to say that we want to match the `auto` height
... but in the sense of `auto` that computes an height based on
the content size, rather than filling the container etc.
... not like in grid where `auto` sometimes means `stretch`
etc
astearns: can we resolve of reverting?
dbaron: I'm uncomfortable going back to undefined
astearns: but other engines don't want that current spec text
dbaron: ok, but this is a can of
worms
... (snarky comments about multiple engines)
cbiesinger: I'm optimistic we could get this interoperable
iank_: for the cases that
cbiesinger described, it would be easy to implement the correct
behavior for that subset
... and we think it's useful
astearns: as you implement subset, it would be nice to describe things in details, so we could find out if interop is possible
fantasai: technically, the
behavior we want should already exist in the engine, it might
not just be called in that specific scenario
... but the keyword would allow to tap in the computations that
exist
... possibly there are cases where you would need much more
layout than engines are willing to do, e.g. for the width of a
multiline column flexbox
... but there are a lot of reasonable cases
... and for those cases we should figure out what should happen
and standardize that
astearns: basically dbaron hesitates due to lack of precise details
cbiesinger: is there a particular
case you think would be very hard?
... so we could find out if we could solve that one?
dbaron: intrinsic size depending
on the inline, it could depend on layout optimizations
... and there might be cases where we try to figure out block
before inline
... and all those cases seem intricate
fantasai: yeah, grid has two
passes for that reason
... (explains how these metrics are computed already today, she
thinks)
dbaron: I'm worried it uses a
value from late in the system, early in the system
... gladly calc doesn't allow to make computations based on
those values usually
... but there might be cases where we do this accidentally in
the algorithm
... and it might cause instability/ec
cbiesinger: I understand the
concerns now
... I'm still inching towards it's sufficiently useful
dbaron: is is sufficiently useful that you would be willing to write a spec?
TabAtkins: (proposed to meet next time he was in new-york to work on it, but cbiesinger is not based in NY)
cbiesinger: I will write
something
... I can try writing a spec
astearns: so, first resolution attempt, can we revert what's in the spec now?
<fantasai> https://github.com/w3c/csswg-drafts/issues/3973#issuecomment-498062046
(can we get a link to the change)
dbaron: do we know why we made the resolution that let to this changeset?
TabAtkins: I don't recall
dbaron: what I don't like is that
the revert will trigger chrome to revert
... and that revert will be unspecced but people will rely on
their behavior
florian: we could have an issue in the spec
Rossen: that seems overkill, we
have an issue on github seems enough
... I think it would be better to first get a strawman of the
chrome behavior, and we can resolve the revert at that time
cbiesinger: ok, sounds fine
any objection to this way forward?
RESOLUTION: cbiesinger will document chrome's behavior and we will revisit
<astearns> github: https://github.com/w3c/csswg-drafts/issues/3323
TabAtkins: I don't think it
shouldn't
... this property is already weird and magic
florian: there is a trend however towards removing the magic
TabAtkins: it's ok, we will then spec this case
dbaron: we usually had outlines
around descendants
... and that caused issues
iank_: in chrome there is a difference between focus and normal outlines
bkardell_: can you clarify that?
iank_: not correctly
florian: when outline-style is
auto, browsers can do even more magic than the other values,
which already are permissive
... focus outline in chrome is even more special than auto, I
think, but it's not clear this is a requirement or historical
accident
TabAtkins: what if required to be the bounding box of all descendants
florian: that's too much
... we still want fragment outlines
... I think it's ok to just say that for that special cases we
will support the children
... we will spec later
una: but we would still render an outline around the element, right?
TabAtkins: for display:contents there is no box for the element
AmeliaBR: if we define an algorithm that creates a set of polygons based on the descendants, that would be fine, but if we want to use a box, this won't work
TabAtkins: sure, but I would want to special case this in this very specific case
AmeliaBR: also for other cases, or just display contents
TabAtkins: obviously people don't like it, so maybe just for display:contenents
iank_: enabling outlines on
display:contents is very difficult for our implementation to
do
... so I
'd prefer not to go down that path
iank_: I'm a little bit concerned about the accessibility case
emilio: my comment was in the
same direction
... drawing something keyed off that doesn't exist in the tree,
is tricky
... focus on these elements is already something that is weird
already
... I'm afraid it wouldn't be interoperable
TabAtkins: well we could define this
emilio: for the bikeshed cases, we could add a css rule
like a:focus > * { outline: auto }
TabAtkins: yeah, and if I had subgrid I woudln't need it either way, maybe that's fine
emilio: and for the a11y tree, I think we resolved they would be in the tree
fantasai: yes, they are in the tree, we resolved on this
TabAtkins: so for bikeshed, I can
add the rule, and use subgrid later, it's fine
... you can already tab to them
<fantasai> fremy: That's not true yet
dbaron: saying these elements
have an outline is like poking a hole in the model
... it's a bit weird, at what point are we not opening a can of
worms?
<jensimmons> subgrid will lessen the desire to use `display: contents` to make grandchildren into grid items — but the usecase for Flexbox is the same. To make a flexbox grandchildren into flex items
dbaron: like, people might want to ask other stuff like background
TabAtkins: I think this is very specific though
<leaverou> fwiw, it looks like elements with display: contents elements don't receive focus right now in either Chrome or Gecko (not sure if that's related to the bug mentioned): https://codepen.io/leaverou/pen/oROLQm
TabAtkins: like you can focus or interact with something, and outline is needed to show that, but it's very specific
una: so you use display:contents and still want to interact, what is the use case?
TabAtkins: explains the use case (bikeshed)
una: so, you definitely want outlines here right?
TabAtkins: yes!
... and I believe this is the only hole we want to make
fantasai: can we get bikeshed to stop doing this while a11y is not fixed everywhere though?
TabAtkins: ok, fine
astearns: so, can we resolve on this?
florian: I think it's fine to let authors have to supply the rule?
emilio: I would like that
TabAtkins: it woudln't work by default though
emilio: yes, I think
(discussion about the fact we might get a few outlines next to each other)
TabAtkins: I think it's fine
florian: And we want a note to make sure authors are aware if we don't do this?
TabAtkins: ok, I'm fine with
this, authors can use :focus-visible
... I'll put a note and a remark about subgrid
astearns: so, proposal, is to not change the spec, outlines do not apply, but we add an example to the spec
<emilio> fremy: I had a proposal for the outlines for the children itself
<emilio> fremy: that doesn't sound weird
<emilio> fremy: when you're focusing something you add an outline to it
<emilio> fremy: not sure if it's complex
<emilio> florian: I think it's complex
<emilio> fremy: but I'd set the outline property on the child box
<fantasai> emilio: At least in Gecko, those outlines are added via CSS
emilio: at least in gecko, those outlines are added via css
<fantasai> emilio: It's effectively via :focus-visible { outline: 1px dotted }
so we use :focus-visible { outline... }
<fantasai> emilio: so you cannot speical-case on the value of display
<fantasai> florian: Was saying it'd be based on used value
<fantasai> emilio: Focusing an element changes the value of descedant elements?
and we cannot special case because selectors cannot depend on values
<fantasai> heycam: If it's up to the authors to specify outline on the children ...
fremy: ok, I understand the concern
<fantasai> heycam: There's no way to do that if only a text node child
<fantasai> TabAtkins: No real use case for 'display contents' in that case
<fantasai> dbaron: What about two pieces where some are text
<fantasai> dbaron: e.g. link with plaintext and a span
<fantasai> TabAtkins: We need a pseudo-element for naked text then
<fantasai> fremy: If you do that, then yo ucan add another span
<fantasai> heycam: Check if parent is display contents?
<fantasai> ScribeNick: fantasai
heycam: flattened tree parent
emilio: that's awkward
jensimmons: Any use cases for 'display: contents' besides lack of subgrid or maybe flex?
TabAtkins: Probably, but subgrid's the only one I've used personally
jensimmons: Why did we invent display: contents?
AmeliaBR: To have layout modes depending on parent-child relationships not disturbed semantic wrapper markup
TabAtkins: Before grid, was for flexbox
hober: weird flex but okay
rachelandrew______: Forms have a
ton of markup
... so would want to use it there
... to get rid of things like box around fieldset, etc.
... once a11y issues are solved
jensimmons: We've eliminated the
box, but the desire wasn't to eliminate the box but to have a
flattened layout model with hierarchical markup
... Maybe 'display: contents' was the wrong solution, too
general
... what we wanted was subgrid
... now we've eliminated the box, and dealinng with
fallout
... but there wasn't a good reason to eliminate the box, except
lack of flexbox
TabAtkins: Well, in flexbox, still want to be able to reorder things
dbaron: If you want the box back,
you have to figure out where the box is
... by eliminating box, don't have to define where box is
... you make the element disappear so you can deal with the
children individually
... so layout hasn't assigned a position for it, so can't draw
the box if you don't know where it is
TabAtkins: So if shadow-including parent is 'display: contents' but should have an outline drawn on it, draw on children instead
AmeliaBR: How does that definition work if you have 'display Contents' inside 'display contents', how do we propagate this?
emilio: Recursive
... not a big deal
... but if should have an outline at paint time, that's
vauge
... has to count for visiblity, bunch of other stuff
heycam: accounting for visibility
is annoying
... ...
AmeliaBR: You can have a
focusable element with visibility :hidden and some children
that are visible
... don't see an outline
...
myles: Why don't we apply this
logic to other CSS properties?
... I don't think that's a road we wnat to go down
astearns: When parent has visibility: hidden?
florian: If you have 'display: contents; visibility: hidden' can you focus it?
AmeliaBR: Most browsers won't focus such a thing
fremy: we draw it in Edge...
astearns: Does sound like
model-breaking behavior
... Defining whether box can be fousable based on CSS
properties we should ignore
<una> Test case to play with (nested display:contents) forked from Rachel's pen: https://codepen.io/una/pen/joRMEL
fremy: If you're visiblity:
hidden, you cannot be focused anyway
... So this issue isn't relevant
<bkardell_> display: schrodinger-cat;
astearns: Two options I've
heard
... 1) Don't draw an outline. Stylesheet can try to style
children or something
... 2) Have UA figure out something to do with 'display:
contents' things that shoudl have an outline
... We have one possible definition of how that could
occur
... I'm unclear as to whether there's enough motivation to
figure out UA magic to get this done
AmeliaBR: I prefer solution that requires authors to do less a11y-aware work, since lots of authors won't bother
fremy: Also govt' requirements, so browsers should do it by default
astearns: Cameron, do we need to evaluate conditions for outlining?
heycam: I don't know, if you had opacity: 0...
AmeliaBR: Then you wouldn't see it on the children either
TabAtkins: Aside from "don't draw this element", won't get focus outline
dbaron: But if you're display: contents, opacity has no effect
florian: Painting outlines on
elements not in rendering tree
... Usually you don't iterate over tree to paint an
element
... This is not the case for focus, you don't have to evaluate
the entire tree to find focus
... We know if a focused element is focused
AmeliaBR: Much more narrow case
dbaron: There's another option
along those lines, which is to say ... maybe you can't do that
because selector-property dependency
... was going to say was if you're display: contents and you're
focused, focus-visible aplies to descendants but cna't do
that
fantasai: I think what heycam said was the simplest solution
emilio: I still think they're
hacks
... It's not impossible, just feels like a layering
violation
florian: iank_ You were saying it's hard?
iank_: I believe our focus outlines get painted differently from normal ones
florian: What would be hard about normal ones
iank_: Don't have anything to
hook up to invalidation logic
... We'd need to introduce this backing to layout tree
fremy: The children draw the outline, so children invalidation
florian: but if you change the property on the parent, you need to know that the children have to be invalidated
emilio: It's a hack
heycam: We'd have to propagate a change hint to the children. Not impossble.
emilio: Nothing is impossible
heycam: Sure, but also doesn't seem too hard
astearns: It is slightly better to introduce hack into UA than to expect authors to have the same hack in their CSS
<leaverou> wouldn't drawing outlines on children be confusing if an element only had one child, which was focusable? Tabbing would produce no visible difference
fremy: If we have in the platform 'display: contents' then it's our responsibility to provide a11y support, putting it in the tree and providing outlines is part of that
emilio: Whether propagating outline , and someone mentioned browsers don't focus visibility hidden elements even if you have visibile children
florian: Because you can't focus them
emilio: link with 'display:
contents' we say has to be focused
... but link with 'visibility: hidden' we don't focus, and it's
OK
TabAtkins: I consider it a bug. That I don't care about
florian: ...
TabAtkins: Nobody has brought up
that as a problem in the 20+ yrs
... whereas within 6 months we had bugs filed against 'display:
contents' for not being focusable
leaverou: If we draw outlines on
children, might be confusing if only one child that is also
focusable
... there would be no visible difference
<heycam> fantasai: there's already no difference if you have an unstyled box wrapped around a child
<heycam> ... the outlines will look the same
<heycam> ... it's not a new problem. whether the box is unstyled with no pbm, or it's display:contents, it makes no difference whether the outline is on the parent or child
<heycam> AmeliaBR: comes down to a design issue
florian: Back to earlier point,
difficulty in invalidation logic
... you could reduce to focus case
fantasai: I think that's harder
emilio: think it's harder for
us
... First one you would implement display: contents with
outline changed, go down the tree and invalidate other elements
inside it
... but in the other case would also need to evaluate focus.
More special-casy
iank_: Can't speak with authority
for us
... The thing that scares me is potentially if outline is
painted by the children, how do you make sure the outline is
contiguous
florian: You don't
... You just make it on the children and whatever
fremy: That's the proposal
florian: If youre existing logic merges outlines, then do that. otherwise don't
emilio: That's not quite
similar
... You also have to check outline on parent vs child
... If have different outline properties...
AmeliaBR: What if say children treated as have 'outline: inherit'
fremy: Just check if 'outline-style' is 'none', and if parent s 'display: contents' draw parent's outline
dbaron: Or draw two
outlines?
... and don't worry about those conditions?
una: I think it's more confusing
to have simultaneous outlines
... if you're tabbing into the children ...
<heycam> fantasai: only draw the outline if it's specified
<heycam> ... if you happen to specify 3 outlines on the 3 different elements, you'd draw all of them
<heycam> ... might just be drawing because one is focused, because you've got outline specified, ...
<heycam> ... not dissimilar to how you handle borders for example, layer them all and paint them
<heycam> ... if they fall on top of each other, you won't see the ones underneath
dbaron: In the normal case for
focus, if you have a box 'display: contents' with three
children
... you tab to parent, you see all three outlined, and then
each one outlined individually as you tab through them
florian: Don't see how to do better than that, the children could be anywhere not necessarily adjacent
fremy: We're defining a
default.
... Not preventing authors from doing better
... Just saying by default, we show an outline
... Not required to be pretty. pretty would be great, but ppl
already change outlines on focus all the time
... to make it prettier
... But by default we want there to be an outline so it will be
accessible
... doesn't have to be pretty
emilio: it's still a hack
fremy: The goal is everybody at
least gets an outline to show the focus
... if someone doesn't like it, you can refine it
... not prevent that, but at least provide something that
works
florian: if outlines that are
drawn for non-focused elements are not drawn, that's OK
... But for focus case should do it
AmeliaBR: So UA must propagate outline if it was caused by a focus change, but?
florian: Either do it always, or do it only for focus-triggered outlines, whichever is easier to implement
fremy: My guess is display:
contents is much harder ot implement than what we are
discussing now
... we're just going the last mile to make it great
AmeliaBR: Can we make a tentative resolution that we will at least support the a11y use case and ask implementers to give feeback on which would be easier to implement: special-case for focus, or any outline?
emilio: display:contents make
sense conceptually, this thing we are discussing makes no
sense
... it's a hack
... in any browser implementing it's a hack
fremy: Users > web authors > implementers
emilio: I won't oppose but I will be very upset to implement this
TabAtkins: make Cameron do it :)
astearns: So deciding whether to draw only for focus?
Rossen: at least
<TabAtkins> I don't disagree that it's a hack.
<TabAtkins> It's just a necessary hack for a11y.
bkardell_: Are we positive you need to be able to set focus on display: contents element?
TabAtkins: Yes
<una> When authors use hacks, its our responsibility to make that experience more accessible
<rachelandrew______> CSS is making people sad again.
TabAtkins: because there are use
cases to display: contents a link, an dyou need to be able to
activeate the link if you're a keyboard user
... And when focusing you need to be able to see that it's
focused
<AmeliaBR> Real world example: `<article class="slide"><a href="..." style="display: contents"><h2>article title</h2><img src="thumbnail"/></a><p>description</p></article>`
bkardell_: Can we just say you can't display: contents a link?
<AmeliaBR> (where the slide has flex or grid layout)
florian: There are use cases for it, though
AmeliaBR describes her use case
AmeliaBR: Want to lay out this article as three separate items in your layout
<emilio> AmeliaBR: why not making the link the flex container?
AmeliaBR: when someone tabs to that link, wnat to be able to see somehting is focuse
<una> Amelias example: https://codepen.io/una/pen/ZNZprm
florian gives a use case for page numbers or something
iank_: I'll have to check with implementers. I will project their sadness.
astearns: So proposed resoution is we paint outlines on the children of a display: contents element
florian: ... special-case focus?
fantasai: I'm pretty sure it's easier to not special-case.
iank_: unsure
astearns: OK, but this is the case we want to support for a11y
TabAtkins: You can come back and
say "no, it's really too hard"
... I don't want us to give up just because it's a little not
great so we made it inaccessible
astearns: So any objection to make this change and get implementer feedback
RESOLUTION: Outline of 'display: contents' is propagated to children for painting (for a11y on focus); implementers should give feedback on it
<dbaron> github-bot, end topic
Meeting closed.
<dbaron> trackbot, end meeting
This is scribe.perl Revision: 1.154 of Date: 2018/09/25 16:35:56 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Succeeded: s/JS Foundation/Open JS Foundation/ Succeeded: s/a few/request a few/ Succeeded: s/fremy/florian/ Succeeded: s/weird/weird if you don't know really what it is/ Succeeded: s/allow you to/detect whether the user agent can/ Succeeded: s/unde rW3C/under W3C/ Succeeded: s/florian/fremy/ Succeeded: s/First/Second, skipping ahead,/ Succeeded: s/eh/in one subsection/ Succeeded: s/.../people use the root font size to create a unit that's not really related to the font size, and that breaks if you apply font size minimums to it/ Succeeded: s/mostly/also significantly/ Succeeded: s/Lang/Wang/ Succeeded: s/bkardell said yes/fremy said yes/ Succeeded: s/are we still using mathml but .../are we saying that mathml is a special layout form, like SVG, that can have its own specialized CSS without influencing arbitrary text layout/ Succeeded: s/requests from/requests for/ Succeeded: s/anymore/yet/ Succeeded: s/REC/CR/ Succeeded: s/issue/significant source of issues/ Succeeded: s/astearns: suggested/rachelandrew______: suggested/ Succeeded: s/maybe/but/ Succeeded: s/height/height based on the content size, rather than filling the container etc./ Succeeded: s/to do/to do, e.g. for the width of a multiline column flexbox/ Succeeded: s/it's/a11y is/ Succeeded: s/florian/fremy/ Succeeded: s/by markup/semantic wrapper markup/ Succeeded: s/Basically grid or flex/weird flex but okay/ Succeeded: s/btter/better/ Default Present: leaverou, tantek, chris Present: leaverou tantek chris dauwhe rachelandrew jihye heycam astearns myles jensimmons flackr TabAtkins AmeliaBR bkardell_ una florian fremy oriol hober dbaron Found ScribeNick: heycam Found ScribeNick: fantasI WARNING: No scribe lines found matching ScribeNick pattern: <fantasI> ... Found ScribeNick: heycam Found ScribeNick: TabAtkins Found ScribeNick: fremy Found ScribeNick: fantasai Inferring Scribes: heycam, fantasI, TabAtkins, fremy, fantasai Scribes: heycam, fantasI, TabAtkins, fremy, fantasai ScribeNicks: heycam, fantasI, TabAtkins, fremy, fantasai WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 04 Jun 2019 People with action items: WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]