– DRAFT –
Cascading Style Sheets (CSS) Working Group Teleconference

<Lionel_Wolberger> fantasai: +1 to having well articulated use cases

<Lionel_Wolberger> matatk: We are understanding, the primary blocker is lack of written use cases.

Worth noting that we expect to get some issues against the spec once someone tries to implement and runs across questions or unaddressed use cases.

But we have very few open issues atm, just waiting on implementer engagement.

<Zakim> tink, you wanted to respond to Mathew

<Lionel_Wolberger> tink: I have presented CSS Speech often, and have had an overwhelmingly positive response from audiences

<Lionel_Wolberger> ... on the other hand, browser development teams seem worried that screen reader makers will object

<PaulG> https://www.1edtech.org/standards/data-ssml

<Lionel_Wolberger> nigel: In the subtitle and caption space, people think TTS is everything

<Lionel_Wolberger> ... but a proper captioning also describes non-speech sounds

<Lionel_Wolberger> ... e.g., waves crashing on a beach

<Lionel_Wolberger> ... so I wish to point out, it's not all about speech

<Lionel_Wolberger> ... this may have seemed impossible just yesterday, but now seems possible

Issues

[css-display-4] Should the reading-order-items property apply to tables in addition to flex and grid layouts? w3c/csswg-drafts#9922

<astearns> github-bot, take up w3c/csswg-drafts#9922

[css-display-4] Should the reading-order-items property apply to tables in addition to flex and grid layouts?

<github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/9922.

<astearns> PaulG: I’m in favor

TabAtkins: Current thread has folks suggesting not to apply to tables, because screenreaders have robust handling of tables

[AdrianRoselli also said this]

PaulG: It could be helpful for responsive tables, where the rendering changes

PaulG: if author has control over the flow

PaulG: That may be something to spend time on a demo

fantasai: One possible way forward would be to not apply if <table> rendered as table, but if rendering as grid/flex apply it

<PaulG> Adrian's responsive table https://adrianroselli.com/2017/11/a-responsive-accessible-table.html

gregwhitworth: Do you get accessibility of tables using table display on DIVs?

TabAtkins: no

matatk: I understand what Paul's saying about consistency and those cases, but also understand what Adrian's saying about having a well-defined model for this

matatk: we don't want to get into a situation where devs think they have to put reading-order on everything
… and they're duplicating what the system could do better than they can
… don't want to reinvent that
… Elika, your solution sounds reasonable ; but what if it looks like a table but done differently?
… from our perspective, we have several different edge cases to think about
… also some reasonable connections for a11y testing and AT industry
… so can ask people about it
… also in-house we have ARIA WG
… APA's role would be to coordinate that broader review
… lots of good points on all the sides; but could be an impactful change
… so give us some homework :)

zcorpan: What is the screenreader behavior if you have a <table> element but you change the CSS to display: something else
… do they still use table mode to navigate that, or do you get whatever reading mode of the display type?

matatk: excellent question

tink: I believe unless 'display: none', has no impact on a11y tree

matatk: what about for grid?

matatk: we'll need to investigate

zcorpan: I think that would inform what to do here
… because if behavior is still using table mode, then reading-flow shouldn't apply

<TabAtkins> fantasai: I think the default value of reading-flow should continue to do what we do today, so if display changes it has no effect

<TabAtkins> fantasai: If you style it with display:flex *and* apply reading-flow, we could consider it having an effect

<TabAtkins> fantasai: I could see reasons to restyle <table> with Grid Becuase you wanna do something fancy, but want to preserve the a11y affordances from it being a table

gregwhitworth: For tables done without an actual <table> element, how often are they giving the expected AT experience?
… Do thinks make it worse?

matatk: Question is, if you make a custom table out of DIVs and aria, what experience do you give?

gregwhitworth: How commonly would people do that in practice, using DIV-based tables + ARIA?

PaulG: Common in my work because we deal with very large virtualized tables.
… don't know how common across the Web, but in FinTech it's quite normal

gregwhitworth: Do people do it correctly from a11y standpoint, in your experience?

PaulG: Lots of walled gardens, can't see in them ; but in ours we try our best

matatk: it's certainly doable, and works pretty well when done properly

gregwhitworth: 5yrs from now, could we deprecate <table>?
… responsive tables is a common ask
… how can we help authors fall into the pit of success?
… because more people will lean into this over time

kizu: Cases where there's a table with display: flex or grid
… usually done at transition point, or to use features of a grid
… sometimes authors had to apply role to element because browsers would lose it otherwise
… a lot of issues
… sometimes browsers lose this role, especially with 'display: contents'
… It would make a table display: grid or flex, then change order of rows
… with reading-flow we might want to reorder rows or columns

<Zakim> fantasai, you wanted to ask why it's done

fantasai: I think if we need more capabilities for responsive tables, we should add those capabilities
… not require shifting to DIVs with ARIA because that's hard to get right

[css-display-4] Define how reading-flow interacts with focusable display: contents elements. w3c/csswg-drafts#9230

<astearns> github-bot, take up w3c/csswg-drafts#9230

<github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/9230.

TabAtkins: [summarizing] Current spec proposes any 'display: contents' element doesn't participate in reading flow, appended to the end
… and they also scope the children, which then end up at the end
… but that's not great behavior
… especially since no-op where DOM order and visual order match, now we have everything at the end

TabAtkins: new proposal is that 'display: contents' doesn't get moved to the end. Instead, children get ordered according to visual order
… and 'display: contents' element itself gets placed immediately before its first child in visual order

TabAtkins: further question, which we wanted to ask you are, does it still need to scope its children?
… when you hit 'display: contents' item, do you recurse and do all of its children first, or do you follow an interleaved order (if that is what visual order is)?

<Zakim> matatk, you wanted to ack the definition of display:contents

TabAtkins: argument for scoping is that a11y tree will match
… all of the children will be contiguous
… Argument for not scoping is that it matches visual order
… and tabindex already jumps in and out of a given eleent, if that's how you wrote your HTML

TabAtkins: so the question to you is, is the tabindex behavior horrible and not good to duplicate
… or is it more important to match visual order, even if you jump in and out of tree

matatk: Thanks for explanation.

<zcorpan> (I found 0 pages with `<div role="table">` in httparchive sample_data (10k pages). So at least not common enough to show up in a 10k random subset of 12m pages.)

<TabAtkins> fantasai: To make i tmore concrete, say I have a tree with siblings A, B, C

<TabAtkins> fantasai: B has children B1 and B2

<TabAtkins> fantasai: in tree order I get A B B1 B2 C

<TabAtkins> fantasai: if I set display:contents on B

<TabAtkins> fantasai: I get the items as A B1 B2 C

<TabAtkins> fantasai: If I reorder them, I could visually reorder them as A B1 C B2

<TabAtkins> fantasai: Which interleaves them

<TabAtkins> fantasai: So, because B1 and B2 are under the B parent, in the a11y tree structure

<TabAtkins> fantasai: Should the reading order A B1 B2 C (keeping them contiguous)

<TabAtkins> fantasai: Or should it be A B1 C B2 (matching visual order)

<TabAtkins> fantasai: If B was display:contents but focusable, it would be A B B1 C B2

<TabAtkins> (in strict visual)

<TabAtkins> fantasai: Or we could cause the display:contents to strictly scope, giving A B B1 B2 C

<TabAtkins> fantasai: So do we force the containment, or match the visual order, when things are interleaved

matatk: You described previous change, and new change, what's happening now?

TabAtkins: All under discussion

PaulG: my instinct is that visual order should be strict
… we tell devs not to use tabindex above zero
… [too quiet]
… if I had the choice between strict visual order or using tabindex to enforce the order, I woudl want strict visual order
… don't want to use tabindex, since we coach devs not to use it

TabAtkins: dilemma wans't use tabindex or not. There's an existing behavior where tabindex jumps across tree boundaries.
… question is, is that behavior acceptable here to match strict visual ordering?

PaulG: Not a disservice to enforce strict visual order
… avoid people using tabindex for that purpose

matatk: My thought is, what would be really helpful is if you could flag APA with the result of that PR
… that would be helpful

matatk: Some of the examples were relating to custom controls using templates and shadow DOM.
… does it work no matter what the context?

TabAtkins: slightly different if using components, because <slot> is strict scoping container for tabindexing
… all things in a <slot> are grouped

matatk: I think we lean towards an accessibility view on it; but would be helpful to track 'display: contents'

[css-view-transitions] Users need to be able to disable view transitions w3c/csswg-drafts#10267

<astearns> github: w3c/csswg-drafts#10267

matatk: We discussed in APA, idea of being able to do some kind of reduction on View Transitions we thought would be helpful
… but also acknowledge that there is a subtle, but big, difference between reducing and disabling motion
… wrt motion, there is good infrastruction for reducing but not disabling
… so consistency issues
… We're generally in favor of some sort of control, but wondering what is the latest from CSSWG

vmpstr: We can respect prefers-reduced-motion and set up different default animation that doesn't have motion and does a cross-fade
… but if authors customize, then that's a regular CSS animation -- they are responsible at that point

khush: There's another issue where flackr had a proposal for a forced no-motion mode
… that would disable all CSS animations completely
… that seems better path for a CSS-wide fix for it
… didn't want to do something specific for View Transitions

khush: one detail is that we do something generic for animating position and size
… can adjust the defaults for that accordingly

<Zakim> matatk, you wanted to ask about 'one-sided' transitions

matatk: if moving between documents and ...

vmpstr: Animation runs on one page only. The outgoing page doesn't control the animation in any shape or form
… just specifies which parts will participate
… incoming page controls the animation, so that's where prefers-reduced-motion would take effect
…

matatk: OK, we'll take as homework on what to recommend

vmpstr: We can resolve now I guess
… in cases of prefers-reduced-motion we will construct a cross-fade animation by default, without size/position animation

vmpstr: Thoughts? Objections?

chrishtr: removing animation completely would be a separate feature

kbabbitt: Do we need to be concerned about whether this is detected as a user preference through timing or something?

fantasai: it's a media query

khush: by design, want authors to adapt to it

kbabbitt: but do we want the info to be detectable (concern wrt fingerprinting)

gregwhitworth: If mapping to prefers-reduced-motion, you can already get that info via JS

matatk: if document doesn't give an alternative, then you'd use the default cross-fade?
… another option would be to not run the normal one, but that's not reducing it
… I think that would surprise authors

khush: Firefox disables marquee animations in this mode already, so there's some precedent

chrishtr: UA stylesheet would normally do cross-fade + transform
… with the second rule for prefers-reduced-motion would only do cross-fade
… author's rules would always override

<TabAtkins> fantasai: Whatever we put in the default UA stylesheet

<TabAtkins> fantasai: Unless we specifically make it an override, it'll get overridden by the author

<TabAtkins> fantasai: so if they create a custom animation, it'll work in both modes. They'll have to create their own reduced one.

<TabAtkins> fantasai: This'll just change the default animation

matatk: So up to us to say if we think this is a good idea

<PaulG> +1 for the default

matatk: Motion doesn't come just from CSS
… if the user says prefers-reduced-motion, is there any browser engine looking into reducing other forms of motion?

fantasai: prefers-reduced-motion is a MQ that the author has to adjust for; UA can oly adjust it's defaults
… if adding a forced mode, we would take more heavy-handed approach to suppressing author-specified motion

matatk: [missed]

flackr: smooth scrolling can get turned off, small example

emilio: we do that too

emilio: it's interesting to have different heuristics here, but similar to forced colors
… if it was a need (not just a preference) then we could take more aggressive measures
… but right now no standard way to expose
… so would need different settings or different browsers
… may or may not be solveable
… ideally we do something like that, where we have a forced-reduced-motion mode
… but I don't think we're there yet

khush: Not all browsers have setting, try to infer from OS settings
… e.g. Android no animations gets mapped to prefers-reduced-motion
… so what was in the OS vs what's in the browser don't match very well

<astearns> proposed resolution: in cases of prefers-reduced-motion the UA stylesheet wil define a cross-fade animation by default, without size/position animation

RESOLUTION: in cases of prefers-reduced-motion the UA stylesheet will define a cross-fade animation by default, without size/position animation

<vmpstr> o/

End

<TabAtkins> TabAtkins, Chrome

<masonf> Mason Freed, Chrome

<rachelandrew> Rachel Andrew, Chrome

<ydaniv> Yehonatan Daniv, Wix

<kbabbitt> Kevin Babbitt, Microsoft Edge

<dbaron> David Baron, Google Chrome

<florian> Florian Rivoal, Invited Expert

<miriam> Miriam Suzanne, Invited Expert

<zcorpan> Simon Pieters, Mozilla

<kschmi> Kurt Catti-Schmidt Microsoft Edge

<Di> Di, Chrome

<astearns> Alan Stearns, Adobe

<flackr> Rob Flack, Chrome

<jarhar> Joey Arhar, Google

<past> Panos Astithas, Google Chrome

<ntim> Tim Nguyen, Apple

<vmpstr> Vladimir Levin, Google

<hdv> Hidde de Vries, Dutch government (technically Invited Expert at CSSWG)

<moonira> Munira Tursunova, Google

<jyasskin> Jeffrey Yasskin, Google Chrome & TAG

<kizu> Roman Komarov, DataDog

<oriol> Oriol Brufau, Igalia

<astearns> github-bot, take up w3c/csswg-drafts#10908

[css-ui] Pseudo-elements for checkmark and dropdown icon for appearance:base `<select>`

<github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10908.

jarhar: on the issue there is some discussion on the UA stylesheet for checkmark next to option elements and the dropdown icon

jarhar: ::check or ::arrow, something like that

jarhar: in my last comment on the issue there I gave a few suggestion

jarhar: one is to consider a new pseudo element

jarhar: question two: what would the behaviour be?

jarhar: question three: what should there names be?

jarhar: does everyone agree we should have new pseudos instead of using before/after?

dbaron: I have mixed feelings

<TabAtkins> I'm totally neutral on this.

dbaron: argument for before and after is that they are something developers are somewhat familiar with

dbaron: doesn't say that makes them a good API design for a web platform feature, but def something to consider

emilio: was going to argue for the opposite

emilio: we generally don't have them on replaced elements, checkbox is an exception

gregwhitworth: is it checkbox or checkmark on the option?

dbaron: the checkmark thing would be what makes the checkmark at the beginning of the option

masonf: we're talking about two different pseudos here

masonf: the icon for the checked state of the selected option and the down arrow the select

emilio: is there a strong reason for using pseudos?

masonf: I'm in support of new pseudos

masonf: what if the developer wants to use before/after on the element?

<flackr> +1

annevk: you'd have to define where boxes are relative to one another

ntim: re developer using before/after… if we use ::before for the checkmark they'd have to override three options

ntim: if we have separate pseudos there's no overriding

<ydaniv> +1

<kbabbitt> also like the idea of reserving ::before for separate non-checkmark "before content" content

ntim: so I am in favour of separate pseudo elements

gregwhitworth: would these work with :checked and :not(:checked)?

gregwhitworth: to remove these would just display none so that I can use my own

jarhar: my intention is to make it easy for author to remove it

emilio: don't agree with the argument that you need to reset a lot with ::after/::before

<ntim> 1 property to override still worse than 0 :)

<emilio> You'd need to set `content` anyways to make `::before` work tho ;)

fantasai: I think we should definitely do custom ones here

annevk: I just looked at the HTML spec and we do use ::before/::after for the q element so there is precedent

<zcorpan> I agree with fantasai

fantasai: there's a lot more than text which is what before/after are designed for

<oriol> +1 to elika

<emilio> Gecko also uses `::before` for `optgroup[label]` fwiw

<emilio> But yeah it's probably not a good precedent

fantasai: we had a design ith a checkbox and big and small text and could be an image even

ntim: I think width and height would be set because you want to allocate space on unselected options

jarhar: every option has ::before on it and then has some padding

ntim: so it is not just content

annevk: I think I never had the mental model of before/after being just for text

ntim: content property was designed just for text

annevk: but can add backgrounds and all

annevk: I was just nitpicking

annevk: not disagreeing

<dbaron> CSS 2.0 did try to use ::before for lists too: https://www.w3.org/TR/1998/REC-CSS2-19980512/generate.html#q11

TabAtkins: the argument of precedent doesn't apply here… there was the possibility of it being targeted in the past. This one is a brand new context, is impossible for it to be targeted in the past

<jarhar> proposed resolution: create new pseudo elements for checkmark and dropdown icon for base appearance select instead of using ::before and ::after in the UA stylesheet

astearns: web platform has been around long enough that I think we can probably find any precedent

<lea> coming to this late but a new pseudo leaves before/after open for further customization. I think it makes sense to leave these up to authors to the extent possible.

ntim: there are two things we're introducing: checkmark for the selected option and the entire row

<gregwhitworth> +1 to fantasai

fantasai: I think this should be a pattern to use for all features we're adding

astearns: so could be in our principles?

fantasai: yes, the principle of don't do hacky things

rachelandrew: the principle was to be consistent

<ntim> (this was jensimmons, not jensimmons)

emilio: does marker go before ::before?

RESOLUTION: create new pseudo elements for checkmark and dropdown icon for base appearance select instead of using ::before and ::after in the UA stylesheet

astearns: now let's talk about how we render these things

jarhar: would do it exactly how before/after work… if authors want to manipulate it, let's allow for that

<gregwhitworth> +1 to jarhar because complex SVGs will want to be used

jarhar: any thoughts on this?

lea: what's the alternative? what restrictions would we introduce?

jarhar: the `::marker` pseudo is an example of one that has restrictions

lea: seems reasonable to use `::before`/`::after` not sure why we would do it different

kbabbitt: do we need to define some consistent ordering for all the pseudos?

<fantasai> Can put it in the css-pseudo spec

kbabbitt: probably the new pseudo, then marker, then before

emilio: the question of making it like before/after or not… not sure if it's only one way or the other but it does matter

masonf: I would have thought that `::before` comes before the new thing so you could do something before the checkmark

flackr: re what alternatives are there… one thing about how `::before` behaves is that it is part of the content box before it, this changes whether background would go around the checkbox or not

dbaron: a few thoughts about it being part-like… what makes it hard for `::before` to be part like is that it only exists some of the time, it exists as a function of the styles. i think that's not the case here

dbaron: it's not immediately obvious that being part like poses a particular ordering constraint. I think it does?

dbaron: another question we need to answer, particularly if we are making it part-like… does the pseudo element exist for all options, and we use styles to make it invisible for the ones that aren't checked, or does it only exist for the ones that are checked?

dbaron: I think jarhar was suggesting it's for all options

jarhar: yes I think it makes sense for it to exist for all options… I use visbility:hidden on the ones that aren't checked

TabAtkins: as long as the ::checked is around it's just philosophical whether it is actually there or not

<lea> it could also facilitate styling like e.g. faded out checkmark for not checked, more obvious checkmark for checked

ntim: if we make it part-like, then `::checked::before` and `::checked::after` would work?

TabAtkins: depends if it is a replaced element or not?

<dbaron> I hope this is `::check` rather than `::checked` (which is too much like `:checked`)!

emilio: if you use content url on something that is not before / after, does it turn it into a replaced element?

emilio: if you set content url on an element you get a replacement, but not on a pseudo?

TabAtkins: in webkit you would

TabAtkins: we had significant arguments over that at previous CSSWG meetings

<zcorpan> Demo https://software.hixie.ch/utilities/js/live-dom-viewer/saved/13114

<annevk> https://software.hixie.ch/utilities/js/live-dom-viewer/?%3Cstyle%3Ep%3A%3Abefore%20%7B%20content%3Aurl(image)%3B%20height%3A500px%20%7D%3C%2Fstyle%3E%3Cp%3E

annevk: I can't override the height though in my demo

TabAtkins: did this change? my mind is blown

<Zakim> zcorpan, you wanted to comment on the ordering

<oriol> I think this is w3c/csswg-drafts#2657

zcorpan: re ordering… if I pretend to be an author, I would expect `::before` to be after the new elements and after the marker, so that it works like on list items… if I put text before my option it would appear before the text and not before the checkmark… that seems useful to me, would seem broken for it to appear before the checkmark

<fantasai> +1 zcorpan

<flackr> +1

<miriam> +1

<masonf> Ok, +1

<sanketj> +1

<lea> +1

jarhar: I think I prefer to not to a part like pseudo element, lots of questions re how the rendering works

<emilio> +1

jarhar: if we did a part like pseudo, you would presumably not be able to use the content attribute and maybe use some other CSS property?

annevk: you can use the content property on arbitrary elements

emilio: I think what jarhar argues for would be fine… if it had to be backed by a real element, I think that enforces the ordering

<masonf> +1 to non-part-like pseudo. Like ::before

emilio: seems fine to make it before/after like

<sanketj> +1 to making these "tree abiding pseudo elements"

gregwhitworth: to jensimmons's and fantasai's point; how do we decide between making something part-like or before/after-like… when we start defining more controls, how do we make these kinds of decisions in a way we won't regret later?

jarhar: for customisable select we have a pseudo element for popover, it needs to function like a first class element

jarhar: for this checkmark I think before makes sense, I literally made the prototype using before

gregwhitworth: should we define how we decide how to decide it in the future?

TabAtkins: if there is a underlying real element, it almost certainly should be part-like… because you want full styling capability. If it is a small leaf note for decoration purposes, it can just be before/after like

<masonf> +1

TabAtkins: there is a bit of gray area in between, but these would be general rules

dbaron: on the agenda for Friday afternoon figuring out some of the classification issues… I mostly agree with what TabAtkins says

jensimmons: makes sense to make sure there is cohesiveness

jensimmons: that's why Apple has advocated for not one element at the same time but think about it holistically across all elements

astearns: we can table this until ntim's presentation and then get back to it

<jarhar> proposed resolution: make the new pseudo-elements behave like before and after. the new pseudo-element for the checkmark on option elements will be rendered before ::before and after ::marker

ntim: we can use design principles we resolved on last time to see what rendering model would best fit those design principles

astearns: we can resolve first and revisit after ntim's presentation?

jensimmons: would like to not look at checkbox in isolation but also look at other form controls like range

ntim: we could go through design principles and see what rendering model works best

masonf: I don't know if, having seen ntim's presentation, it would change a lot about this specific issue

ntim: it needs to be consistent across controls, and the way they work in code… that could guide what rendering model is used for this pseudo element

ntim: another one is that it needs to be easily customisable

ntim: not sure what rendering model would make it more customisable, outcome seems similar

annevk: I think I'm not sure what the differnece is between part-like and tree-eh?

TabAtkins: tree-abiding

annevk: would they respond to hover?

TabAtkins: yes

dbaron: tree-abiding elements have a limited amount of pseudo-elements that can go after them

dbaron: part-like elements have @@@2

annevk: so if it was part-like it would also support before/after?

dbaron: yes and a bunch of other things

annevk: that seems like a risk that we'd make decisions arbitrarily

dbaron: I think the design criterion there is whether it is a pseudo el for something that has stuff inside of it

dbaron: if it is a pseudo element for something that has a slot inside of it or gets stuff slotted inside of it, that's a strong indicator that it is part like

dbaron: whereas if iti s leaflike, it probably isn't

annevk: in this case the determining factor why jarhar argued for before/after-like as nog so much it being a tree abiding node, that was not stated until now

oriol: theoretically we could allow nesting in some way

annevk: I think jensimmons 's point is that we're looking for doing things like naming and behaviour in a consistent way… when you look at it that way you get discussions like this one on tree-like / part-like

annevk: the hope is that this time when we do styling of form controls we actually get it right and get web developers something that works for them

masonf: one of the things we've discovered working on <select> at Open UI… it's very hard to generalise. we learned a lot about how to make this work, a lot of iterations in which we learned a lot.

masonf: the first one can be a model for the rest, rather than to design them all at the same time

annevk: I don't mind having this resolution first with an asterix, but am not sure about using one as the example for the next few, rather than doing them in parallel as much as we can

annevk: so that we can have more harmony

jensimmons: agree with annevk… it's important to go into the details and understand all the nuance

jensimmons: what we want in the end is a solution that is so much better than how we used to solve them in the 90s… we want to make this as easy for authors as possible and as simple as possible

jensimmons: maybe this one control can be very easy, but these kinds of decisions are very hard to do in isolation

jensimmons: I appreciate the progress around deepdives, but I hope folks also see that we at Apple have been working on it and look at the whole set of components at once

ntim: maybe how we could approach this discussion is @@@

ACTION: Tab and fantasai to make better words for this in the css-pseudo spec

gregwhitworth: what TabAtkins defined you'll talk about on Friday, that will hopefully have a name then, then we can take an action next week and make a spreadsheet to compare 3-4 elements and look at the pseudos needed for them

form control styling update from Webkit

ntim: looking at UI controls, we want an incremental approach and look at the problem holistically at the same time

ntim: the way we want to do this is through the appearance property

ntim: we have come up with a number of different principles for the base UA stle

ntim: we'd like the styling to be identical in every browser

ntim: we'd like the controls to be recognisable and usable on their own

ntim: styling has to be accessible, and consistent across controls

ntim: we'd like tcontorls to be easily customisable without needing complex resets

<fantasai> Design principles we resolved on last week

[shows slide comparing three different apperances]

<florian> /op astearns

ntim: appearance: auto is basically like Windows 95 style … you can't really apply styles on top and it looks different across all browsers

ntim: so this is probably not a good route going forward

<dbaron> I think it's much more Windows 98-era than Windows-95 era :-)

ntim: `appearance: none` then is quite messy… it uses system colours

ntim: `appearance: base` is a possible proposal for the UA stylesheet, still in draft

ntim: the background is transparent, font inherits, and border is currentcolor

ntim: there are also different variations, for instance the placeholder is currentcolor with 50% opacity

ntim: the next part of the equation are in-page pseudo elements

ntim: we'd like to cover the most reasonable use cases, use consistent naming schemes and structure and for them to be consistent with each other

ntim: and we want pseudo elements to inherit appearance from their originating elements

ntim: [shows example of slider-like controls]

ntim: we have a well defined tree structure for pseudo elements

ntim: for text based inputs we have `::field-text`

ntim: the reason for that they can be reordered

ntim: we are planning to take this work to CSS Form Stylng Module 1

ntim: then we also looked at styling pickers

ntim: pickers are the part that pop out, in the case of a select it's the dropdown menu, in the case of a date picker it's the calendar

ntim: for this we want to introduce the `::picker()` pseudo element

ntim: developers can use this with an @supports rule

ntim: to opt in to CSS styling of pickers you have to set `appearance: base` on the pseudo element (`::picker(select)`)

ntim: it doesn't pop out out of window bounds because of security reasons

ntim: on watch screens, the UA could force the picker to have the native appearance with `appearance: auto !important`

ntim: we're currently waiting on approval before publishing the spec

ntim: and WebKit is currently prototyping

masonf: is the spec that is coming one for all of these things? does it answer the pseudo questions?

ntim: some of them, not all

annevk: we have a pretty complete proposal for all form controls, we need to do some internal review before we can share it

ntim: it doesn't cover all but we're going to incorporate what the WG discusses

ntim: the CSS forms in GitHub is like a scrapbook now and ntim's suggesting to take over that file

chrishtr: why shouldn't we solve now what should go on the spec?

annevk: seems reasonable

annevk: this is an initial proposal…

fantasai: we have to tease out where everything goes later (CSS, HTML), having it in one document now is easier

chrishtr: seems reasonable

ntim: we'll probably move some things around

chrishtr: are you proposing all form control pseudos would go into this one spec so that we could have a deep understanding of all form controls (rendering and styling) in one place?

<fantasai> Proposed scope of css-forms-1 (for now): design principes, `appearance: base`, pseudo-elements and structure for each form control, default UA stylesheet

ntim: we can do that after or before publishing, don't feel storngly

annevk: initially some of the rendering details that should be in HTML would be in this draft for the sake of making reviewing easier. Long term there probably needs to be a defined contract between CSS/HTML

khush: when the browser has to use the native widget, so then you won't get this pseudo element tree?

fantasai: author would still be styling page controls, but then when you click on the picker that may be a user agent picker… there may be some platforms where you don't trust the author to define that part

khush: so then the browser would want you to use the native widget?

fantasai: yes

<Zakim> lea, you wanted to ask about ::picker()

lea: great to be targeting this holistically… some Q re the picker pseudo element… is the idea that we use that same construct to style individual parts of the picker?

fantasai: eventually we want to do more with that picker… but that's a much bigger project and harder to tackle, so want to do one at the time

fantasai: so it'll probably be a keyword that matches that type of control

fantasai: so at first select would be a valid value for picker, and later we could add more

ntim: the picker pseudo would target the picker container… styling individual parts of the picker would probably be in HTML

<Zakim> zcorpan, you wanted to ask if meter and progress elements are in scope

annevk: for certain widgets there would actual elements on page to style, for others there aren't and then we need to introduce pseudos for those to be styled

lea: for something like a date picker that would be a lot of pseudos

annevk: we can share a proposal soon

zcorpan: The appearance property applies to the meter and progress elements. Are they in scope?

annevk: one thing we haven't looked at for this is details, but I think dbaron has

florian: brief point on spec wrangling, would support to move things to different spec, moving appearance out of css-ui

astearns: how much of this has been informed by what has already been discussed in Open UI CG?

astearns: is this entirely new?

astearns: or a summary of what has been discussed so far?

annevk: I think Open UI focused more on introducing new elements not styling existing

masonf: also discussed range and checkbox a lot

<masonf> https://open-ui.org/

<jarhar> the "active proposals" here is what you want: https://open-ui.org/

jensimmons: Apple wasn't able to join Open UI until later… it would be helpful if someone could provide links so we can make sure we don't miss anything

astearns: great if someone can volunteer, maybe after the proposal

Domenic: was there consideration of tech debts around appearance:none

ntim: one thing we have been thinking about, is aliasing none to base for some controls, to the extent compat allows

<Domenic> Regarding OpenUI outputs, I've always found it very confusing what was intended by pages like https://open-ui.org/components/checkbox/ and https://open-ui.org/components/checkbox.research.concepts/ ... translating those into concrete inputs of the type that might result in an appearance: base spec would be interesting.

masonf: we'll wait for the spec to come out and am ok not resolving regarding the pseudos

fantasai: maybe we can resolve on they are at least tree-abiding

annevk: for all form pseudos?

<jensimmons> Yes, of course we all know about open-ui.org. There is no clear documentation summarizing ideas about form control styling there. There is fantastic research into what frameworks are doing, that's helpful. But if there's other docs — like this debate about tree abiding vs part-like, and how that might apply, etc....

<dbaron> It's not controversial, but also somewhat low value due to obviousness?

TabAtkins: it's probably not controversial

<fantasai> Proposed scope of css-forms-1 (for now): design principles, `appearance: base`, pseudo-elements and structure for each form control, default UA stylesheet for form controls

<fantasai> Proposed scope of css-forms-1 (for now): design principes, `appearance: base`, pseudo-elements and structure for each form control, default UA stylesheet for form controls; some parts of this will move to the HTML spec eventually

<fantasai> Proposed scope of css-forms-1 (for now): design principles, `appearance: base`, pseudo-elements and structure for each form control, default UA stylesheet for form controls; some parts of this will move to the HTML spec eventually

<masonf> +1

<chrishtr> +10000

<jensimmons> :D

<hdv> +1

<jeroen> +1

<florian> +1

<sanketj> +1

<flackr> +1

RESOLUTION: scope of css-forms-1 (for now): design principles, `appearance: base`, pseudo-elements and structure for each form control, default UA stylesheet for form controls; some parts of this will move to the HTML spec eventually

<astearns> github-bot, take up w3c/csswg-drafts#10908

[css-ui] Pseudo-elements for checkmark and dropdown icon for appearance:base `<select>`

<github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10908.

<fantasai> PROPOSED: forms pseudo-elements are at least tree-like (open issue wrt whether part-like)

<masonf> +1

<dbaron> tree abiding

RESOLUTION: forms pseudo-elements are at least fully styleable tree-abiding (open question about whether part-like)

<flackr> +1

break

<astearns> The hotel power cut out at the beginning of the break, and is not yet back on. We are not likely to resume on time

<astearns> Expected resolution in 4 hours :) https://www.anaheim.net/2829/Electric-Outage-Map

<dholbert> yikes!

<dbaron> those are usually pessimistic

<dbaron> but someone should make loud announcements on the Lanai deck if the power returns

<dbaron> many of us are outside on the assumption that there's no meeting now

<dbaron> fantasai, do you know if there's HVAC in the room?

<leaverou2> Can someone post the link to the slides?

<astearns> There is no meeting now, but we are having a minuted side conversation on tooltips and hover cards we will report on and return to in a future meeting

<fantasai> Slide deck

<fantasai> Archived slide deck

<dholbert> RE slide 18 in that hover-card (hover-like actions for touch-screens, and relation to the built-in long-press context-menu): I reduced a testcase for a bug that was reported on Firefox-for-Android recently in this space, which spawned https://bugzilla.mozilla.org/show_bug.cgi?id=1919411

<dholbert> (learnings in that bug: if you long-press a link Chrome-on-Android activates its :hover pseudoclass slightly earlier than when it activates its long-press context menu. So it essentially has a "medium-press" sort of action where you can activate the hover-state and then let go, to expand some of the page's own UI, without having to get the overhead of the whole native context-menu)

<dholbert> (whereas Firefox-on-android activates :hover atomically with the context menu appearing)

<dholbert> (I'm not sure to-what-extent the Chrome "medium-press" hover behavior is intentional vs. inadvertent. There's a pretty short time-window during which you can release or drag your finger to prevent the context-menu from appearing.)

<dholbert> (I also don't have easy access to an iOS device so I'm not sure how mobile Safari behaves on that bug's testcase, but that would be interesting to see too)

<TabAtkins> Minutes from Mason's presentation about solving the tooltip/hovercard/etc problem:

<TabAtkins> mason: Been working on APIs realted to this one set of usecases, wanted to bring them together and talk about them.

<TabAtkins> mason: a lot of ideas here, wanted to get things together to discuss, no resolutions yet

<TabAtkins> mason: We've had five or so meetings dedicated to these issues

<TabAtkins> mason: [reads outline]

<TabAtkins> mason: use-cases, tooltips, hover cards, and peripherally hover menus

<TabAtkins> mason: many terms used here, but for "tooltip" i mean auxiliary info not required fo rhte user

<TabAtkins> mason: same with hover card

<TabAtkins> mason: tooltips aren't interactive, basically just text. hover card can contain interactive stuff

<TabAtkins> mason: both are used often to remove non-critical information, reduce the info density of a page

<TabAtkins> mason: third use-case that sounds unrelated semantically is a hover menu - hover over a menu button, it shows up

<TabAtkins> mason: diff is you can usually click/tab to the menu to show it

<TabAtkins> lea: diff between the first two again?

<TabAtkins> mason: tooltip is just text, icons, decoartive stuff. nothing really interactive.

<TabAtkins> mason: a few things important. need APIs for these usecases, I think they're common.

<TabAtkins> mason: there shoudl be a declarative wya to trigger it, easy to get things wrong in JS

<TabAtkins> mason: a11y, of course

<TabAtkins> mason: and it should work for everybody, even if you're not using a mouse

<TabAtkins> mason: a lot fo examples. github has a lot of examples, almost every link can be hovered.

<TabAtkins> mason: facebook uses it a lot

<TabAtkins> mason: they're even nested [shows a hovercard, which shows a tooltip, which has a tooltip]

<TabAtkins> mason: wikipedia too, every link shows a hover preview of the next page

<TabAtkins> mason: the GAP website, interesting case - there'a a selector for the quantity in the cart. Hovering it the menu, you can bring up a menu while the number picker is still open

<TabAtkins> emilio: is that actually intended?

<TabAtkins> mason: I think so

<TabAtkins> tabatkins: being able to look at tooltips while a dropdown is open is common enough in game UIs

<TabAtkins> emilio: I had some example in Firefox and I was told that behavior was a mistake

<TabAtkins> emilio: typing into the URL bar

<TabAtkins> mason: whether it's a good idea or not, it's a common example in the wild

<TabAtkins> annevk: these are all desktop examples

<TabAtkins> mason: yes, that's what I want to solve

<TabAtkins> keith: wikipedia has an ios app, they have page previews feature

<TabAtkins> keith: there was a study, using the preview cards increased clicks

<TabAtkins> keith: a lot of websites like github can't do the hovering stuff on mobile, it loses you the context menu, which you need (to like open in new menu)

<TabAtkins> keith: but native apps, like wikipedia, do both - they can show the preview *and* bring up the context menu

<TabAtkins> chrishtr: keith, coudl you screenshot that and share it later?

<TabAtkins> keith: check the wikipedia app in ios, long press a link

<TabAtkins> mason: one of the definitions of htese is that they're "auxiliary", you dont' *need* them to navigate the page.

<TabAtkins> mason: but that's contextual - if i'm authoring something in github and want to know someone's name, i need to hover them

<TabAtkins> mason: Okay so hovercard, it displays on top, next to the triggering item. it's light dismissed

<TabAtkins> mason: it's activated somehow, depending on device

<TabAtkins> mason: APIs that do this: 1) popover, 2) anchor positioning, 3) not too much detail here, but popover hint="" attr

<TabAtkins> mason: makes separate stacks of popovers, so hover card doesn't close other pickers

<TabAtkins> mason: and another thing we're talking about today, interest invokers

<TabAtkins> mason: there is a proposal for this, shape is open to discussion

<TabAtkins> mason: but idea is simple attribute on the element, with an IDREF to the thing you want to open

<TabAtkins> mason: when user "shows interest" in the first thing, popover shows up; when they stop, it goes away

<TabAtkins> mason: the "how" is the open question

<TabAtkins> mason: going thru design systems, they all have a hovercard/tooltip of some kind

<TabAtkins> mason: universally they work with the mouse, you hover or stop hovering

<TabAtkins> mason: most try and provide good AT support, with varying success

<TabAtkins> mason: some build things for keyboard, they're all different. lots of time and energy spent on trying to get this "right"

<TabAtkins> mason: meaning good for the user, not annoying, etc

<TabAtkins> mason: almost no design system i've seen does anything for touch, they punt, so mobile doesn't get it

<TabAtkins> mason: and nothing does other inputs, so like playstation or vision

<TabAtkins> mason: so, mouse is easy. some questions and options like safe triangles, hover delays, etc

<TabAtkins> mason: but interesting is keyboard and touch

<TabAtkins> mason: you can show hovercard when focus reaches the element. tab to it, it shows up. maybe with a delay.

<TabAtkins> mason: some people do an additional icon next to the thing, and (i) or something. you can tab to it or click, it shows the hovercard

<TabAtkins> mason: final is a hotkey, press it to show a hovercard

<TabAtkins> mason: does anyone know how to activate hovercards on gh with keyboard?

<TabAtkins> [literally no one except the GH employee]

<TabAtkins> lea: how does tabbing *into* the hovercard work?

<TabAtkins> mason: for popover that's solved, the contents get inserted into the tab order

<TabAtkins> mason: dialog also immediately focuses the right thing

<TabAtkins> flackr: and that's potentially an argument agaisnt focus activation, you tab to it and it immediately opens the hovercard and you have all the stuff in your tab order now

<TabAtkins> lea: or argument for delay or key activation

<TabAtkins> mason: the hovercard itself could say "press Option-Up to tab into this"

<TabAtkins> mason: one thing we heard is that adding into the tab order is annoying

<TabAtkins> mason: two things, if you're tabbing thru the document, having it pop up is annoying. stealing focus is bad

<TabAtkins> mason: that's still the case with delays, hard to discover, and can still trigger by accident

<TabAtkins> lea: in some cases there's a natural intent, so delay is good

<TabAtkins> mason: yeah, similar to mouse, sometimes hovering and getting a popup is annoying but something it's right

<TabAtkins> mason: the focusable icon is also annoying, it adds to the tabstops, it's visual clutter

<TabAtkins> mason: the last actually seems to work, hotkey

<TabAtkins> mason: problems: it's not discoverable

<TabAtkins> mason: and it's not universal

<TabAtkins> tabatkins: which is part of the discoverable problem

<TabAtkins> mason: so I think the best idea i've seen so far is hotkey

<TabAtkins> mason: some ideas for discoverability.

<TabAtkins> mason: if you focus an item with interest target, maybe a tooltip shows up telling you the hotkey, provided by the UA

<TabAtkins> mason: not wonderful tho, other ideas open

<TabAtkins> ntim: only when focusing via keyboard?

<TabAtkins> mason: yes, only keyboard

<TabAtkins> lea: problem is as soon as they're introduced, authors will want to style it

<TabAtkins> annevk: and maybe if user has seen this X times, we can stop showing it

<TabAtkins> mason: we also aleady have some examples, like accesskey (which doesn't work great)

<TabAtkins> mason: maybe browsers could have a hotkey cheatsheet UI, pages could say what their hotkeys are

<TabAtkins> ntim: firefox has UI to show the accesskey on buttons

<TabAtkins> emilio: built-in buttons and menus, not author-provided stuff

<TabAtkins> emilio: we use a special 'content' value that creates the accesskey, and generates the right sort of underlined text

<TabAtkins> keith: a lot of the cahllenges for shortcuts on github, it's tough and we're still iterating on it

<TabAtkins> keith: i'd lvoe accesskey to work, or declarative way to make shortcuts work

<TabAtkins> keith: accesskey, the modifiers are different *per browser* even on the same OS

<TabAtkins> keith: key events are complicated, etc etc

<TabAtkins> florian: If you find a way to tell the browser there's a hotkey "for this", how do you localize it?

<TabAtkins> florian: presuambly want it in the UA language, not site language

<TabAtkins> keith: in github, we have data-accesskey; JS generates the cheatsheet and can localize

<TabAtkins> mason: i should have mentioned the github cheatsheet, too

<TabAtkins> lea: are we trying to converge on key combo for showing this? i think there are cases for other things, hover interest for more important things, but key combos for less important things

<TabAtkins> lea: like for github link hovers, those are pretty important

<TabAtkins> lea: maybe need some user choice, with a well-chosen default

<TabAtkins> mason: possible. hard to make that per-site

<TabAtkins> keith: i think there's a distinction between the tooltip and the "rich tooltip" or hovercard

<TabAtkins> keith: tooltip used a lot in just plain buttons. aria lable announces it, but if you're tabbing it you dont' want another key just to show the label

<TabAtkins> keith: so the simple tooltip you want on tab, but rich tooltips are disruptive

<TabAtkins> keith: maybe okay to display on focus, but not be traversable on focus

<TabAtkins> mason: good point on tooltip vs hovercard maybe wanting different activations

<TabAtkins> mason: let's move on

<TabAtkins> mason: touch screen, not great examples in the wild

<TabAtkins> mason: native apps, methodology is long press, pretty universal

<TabAtkins> mason: doesn't exist on the web because longpress either takes over and you can show hovercard *or* users can have context menu

<TabAtkins> mason: a lot of design systems aren't willing ot amke that choice

<TabAtkins> mason: on wikipedia, i might want to see the hovercard preview *or* copy the url. i shoudln't have to choose, i'll be annoyed either way. but no way to avoid that choice today on the web.

<TabAtkins> fantasai: could we add something to the context menu?

<TabAtkins> mason: great question, hold that thought

<TabAtkins> ??: if I long-press on my laptop, i get both shown

<TabAtkins> keith: I think because you're emulating touch on the laptop

<TabAtkins> emilio: also a distinction - if you longpress you get hovercard, longpress again you get context menu

<TabAtkins> kirt: does pen strictly match mouse? you *can* hover with it

<TabAtkins> mason: i think if you can hover it's basically mouse, yeah

<TabAtkins> mason: the other example i think kinda works is the (i) icon, but everyone dislikes it

<TabAtkins> mason: so basically no design system does mobile well

<TabAtkins> mason: ideas

<TabAtkins> mason: one is just adding to the context menu

<TabAtkins> mason: a little extra. downside is you longpress and then choose something else

<TabAtkins> mason: maybe a little annoying, but you *can* get to it

<TabAtkins> hidde: is the text author provided or UA?

<TabAtkins> mason: good question, hopefully way for author

<TabAtkins> mason: wikipedia longpress shows the preview above the menu, maybe we can let you hook into that

<TabAtkins> keith: note you can sniff the preview window based on UA sniffing

<TabAtkins> annevk: the UA is the same if you share a link in imessage, that's fraught

<TabAtkins> florian: note we're talking about the absence of hover *and* the presence of touch, and those are usually connected but there are othe exotic combos

<TabAtkins> florian: we're talking about the absence of hover

<TabAtkins> florian: can have a pen device with touch *and* hover

<TabAtkins> mason: right, absence of hover

<TabAtkins> mason: note that sometimes you wouldn't even ahve a context menu originally, we can just show the hovercard

<TabAtkins> mason: third option is what emilio said, show the hovercard, but provide a way (second longpress, option somewhere) that shows the UA menu

<TabAtkins> mason: kinda a decision of which shoudl be harder for users

<TabAtkins> annevk: what if you position the card over the button?

<TabAtkins> mason: UA could bring up some UI elsewhere to expose it

<TabAtkins> lea: what if you show both?

<TabAtkins> mason: problem is positioning, you don't know where it is. in iOS, the context menu takes over the screen, there's no space for the hovercard

<TabAtkins> keith: depends on the app how it's handled

<TabAtkins> flackr: variation on two-tap, could ahve a second timer. as you hover you see hovercard, a UA tooltip could say "keep hovering", pop up the system menu instead

<TabAtkins> mason: really depends on the number you choose for the delay, yeah

<TabAtkins> mason: brief slide on other things

<TabAtkins> mason: i think we shouldn't try to standardize the things on this list, just the three common ones i've gone over

<TabAtkins> mason: we can decide these are auxiliary, it's okay

<TabAtkins> mason: so i just wanted to percolate ideas, we got that

<TabAtkins> mason: these things are real, they're all over, they're hard to build and leave users out, so we should solve them

<TabAtkins> florian: to bridge device categories, with MQ we're not doing devices it's functionalities - do you have hover, do you have keyboard. just a few axises, let devices sort themselves out.

<TabAtkins> mason: I agree with that. I have an ipad which has a touchscreen, and an attached keyboard off to the side that i'm not using right now

<TabAtkins> florian: we haven't solved the keyboard yet, yeah

<TabAtkins> keith: this is part of the interest thing, if the UA can register "interest", we can abstract over things like hover

<TabAtkins> keith: every device should have interest, it's device-dependent and the user has to learn it, but we can mandate the existence of interest

<TabAtkins> annevk: kinda counter to how things usually go, we usually standardize something already being done.

<TabAtkins> annevk: here we're inventing something new, webdevs might dislike it

<TabAtkins> annevk: but for the past 18 years people haven't been doing this on the web

<TabAtkins> mason: disagree, on native apps you definitely get these things

<TabAtkins> keith: yes, in github, we have hovercards on mobile *because* we have fine control. we can't do them on web because of lack of functionality.

<TabAtkins> annevk: the way longpress works, if there's a primary activation you get that on press and then hovercard on longpress. you don't get that on <p>

<TabAtkins> keith: yes, interesttarget only works on link and button currently, so the basic activation is alreayd there

<past> Hey folks, it appears that the room (4 Concourse Level - Laguna) is unused for the next 2 hours. Are you up for continuing with our agenda?

<dbaron> I am if others are

<lea> I am

<emilio> I am, there in 15/20 mins

<dbaron> sounds like the plan is to try to start at 14:30

<lea> We have critical mass (12 people so far) and will start at 14:30. Would be good to have Apple in the room too, @fantasai

<lea> We have critical mass (12 people so far) and will start at 14:30. Would be good to have Apple in the room too, @fantasai?

<sanketj> openui/open-ui#1088 (comment)

Extend popovertarget to support custom elements

github: openui/open-ui#1088 (comment)

sanketj: use case we're looking to enable is popovertarget on custom elements

sanketj: allow authors using custom element to ?? without any script

sanketj: we believe the proposal can be extended to other types of form control behavior

sanketj: proposal leverages element internals

sanketj: give the cusotm element button-type button behavior, support things like popovertarget/action

sanketj: also a11y things, if no role defined

sanketj: easy opt-in to communicate to the browser that this custom element should have button-type behavior on the page

chrishtr: so if clicked, will open popover?

sanketj: behavios just like <button>, so if popover defined

chrishtr: so when click bubbles up it would be the default action?

sanketj: yes. can be preventDefault'ed

lea: what is current behavior?

sanketj: nothing. it does nothing

annevk: it's only an attribute for buttons

sanketj: you'd have to write script to call popover methods in JS

lea: are we limiting to custom elements with [limits] or any element?

sanketj: you'd have to give it type of button

sanketj: today, button regardless of type, can launch popover regardless

sanketj: maybe if extended later ???

sanketj: custom element needs to resemble the type of the native element it's emulating

lea: [missedq]

sanketj: set internals, and there you say it's emulating a button

lea: other values?

sanketj: none yet, but could do submit or others

lea: why not use computed role?

annevk: roles don't have API around them. They're only used for reflection to AT.

annevk: they're not semantic

annevk: all of ARIA is just affecting the accessibility tree; intentionally no other side-effect

<Zakim> Domenic, you wanted to talk about disabled=""

Domenic: Makes sense. one thing to keep in mind is interaction with disabled

Domenic: if form-associated, can be disbled

Domenic: so will need to check that the same way

sanketj: good point

keithamus: lots of subtle differences wrt e.g. activation via spacebar or enter etc.

keithamus: working inside a form or outside a form, should have consistency. but might be confusing to developers

Domenic: spacebar thing is interesting. would adding this make spacebar cause click events?

sanketj: for behaviors, have we discussed in WHATWG?

keithamus: We resolved that if it's a form participant, needs to have type=button as content attribute

keithamus: and has to be a tag of button (or exception for this case)

keithamus: so we should make provisions the same

sanketj: so strictly needs to be of type button if form-associated, but if not they could be of type reset or submit as well?

sanketj: We want this behavior to also extend to ??? things like commandtarget

sanketj: ideally work the same

keithamus: lots of small assitive pieces like spacebar that have implicit ????

annevk: is that what we do for form-associated elements?

Domenic: web devs add own keyboard/click listeners

Domenic: if it is going as far as behavior, then maybe it should do the spacebar->click translation also
…

sanketj: proposal is if you set type=button, and no explicit role set anywhere, then it gets implicit role of button

sanketj: if element-internal role, then those take precedence

lea: I agree ARIA should not produce side-effects, but what about the other way?

lea: would type=button cause ARIA to compute to button?

Domenic: different about ??, but should reflect in AT

keithamus: we already have the different levels

annevk^: do we want that many layers of abstraction?

annevk: not reflecting in element internals

keithamus: I consider that part of raw computation. Another lookup in the if-chain

keithamus: aria-reflected will always be whatever content attribute is

annevk: idk if it matters about table

annevk: but I think we can just put it on the internals

Domenic: element.internals role is to define its default role

Domenic: if designing button from scratch, would set it

Domenic: now saying you can set type

Domenic: but could also set internals

Domenic: but C++ elements don't have this third way

Domenic: For every built-in element there's C++ dfeault role, and there's content attribute. Now we're adding third one.

keithamus: we have third raw computation already

Domenic: which element?

keithamus: I believe there's code that computes roe

annevk: but that's just flattening the role, if multiple are specified in the attribute

annevk: but that's still only one level, it's not an extra level

Domenic: might not agree on how many levels there are, but question is do we want to add the additional leveL?

Domenic: [missed]

sanketj: so you're proposing it should change element.internals.role

sanketj: if you never set role, and you query element.internals.role then you get button

annevk: Should this be on internals? Form-associated is on constructor.

lea: it's static

lea: my high-level concern was to not have authors declare their intent twice

lea: otherwise will end up with wrong roles

<tantek> +1 lea

lea: so don't mind how it happens, as long as simple case works by default

lea: and allow override in internals

Domenic: all agreed, but just question of how

annevk: do you remember why form-associated is static?

Domenic: for inheritance, which webkit doesn't support

Domenic: could do autonomious custom button inheritance

keithamus: common practice ot have a base classs and then extend it

keithamus: can't think of why you'd have inheritance chain for button

annevk: e.g. submit button subclassing from button

Domenic: if you call super, then the superclass will set element.internal.type

keithamus: a lot of internals can only be captured once, so if you are defining ?

Domenic: oh, basically can't use element.internals for inheritance

keithamus: element.internals throws on the second call

annevk: so we have static form-associated, should this match that existing pattern yes/no

bkardell_: I like it, but

annevk: Oh, I wanted to say that too

bkardell_: but explainer doesn't mention :focus-visible, but that should also apply

bkardell_: we did so much work to make :focus-visible work, if we make it so that doesn't work it'll be a step backwards

annevk: focus for custom elements is an unsolved problem

annevk: don't know which kinds of elmeents to opt in

Domenic: problem with focus is, say "want to be keyboard focusable or mouse focusable" but what you actually want is to match platform conventions

Domenic: so best proposal was "behave like a button"

Domenic: tried to be too generic

Domenic: but this is more specific, so can solve it

annevk: I guess that works

Domenic: not 100% certain it'll decompose well with the hypothetical future, but 80% sure

annevk: if just going to be default buttons or submit buttons?

Domenic: I hope they have same focus behavior

annevk: yes but different selector matching

sanketj: intent is type=button is button type=button

sanketj: if you want to make it submit, then need type=submit

<bkardell_> selector matching is a good point too

annevk: Maybe do more than just type? or is it open to e.g. hyperlink, submit button, etc.

Domenic: yes that's the idea

annevk: so really big enum

keithamus: wrt roles, image has non or presentation depending on herusitics

keithamus: table has ??

Domenic: those are set by a single property, not two layers

keithamus: Not to derail too much, but what if HTML button had a superclass that was designed for this kind of inheritance pattern

keithamus: woudl be like "is" but sidestepping issues around custom eleents

keithamus: would that ... work?

sanketj: one thing we want to ensure, challenge today, is attaching shadow DOM

sanketj: can't do for something that inherits from HTMLButtonElement

keithamus: I'm proposing a new class, e.g. HTMLAbstractButton, between HTMLElement and HTMLButtonElement

??: do we have anything like that today?

annevk: nope

annevk: but none of those can be extended and used as custom element

keithamus: could we extend HTMLHeadingElement?

annevk: I'd be worried about changing inheritance of existing elements

Domenic: why is this better than element.internals type?

keithamus: I think it's more consistent for developers

keithamus: authors want to extend more than just button

keithamus: we're already talking about other types of buttons and inputs

keithamus: not necessarily a point against this proposal, but ...

Domenic: both would work

annevk: either way would need to go through element.internals

annevk: so not getting much except the type

annevk: and it gives us longer prototype changes, and compat headaches

annevk: maybe impact is negligible but doesn't seem great?

<leaverou2> the superclass idea is *really* interesting

annevk: if there was a concrete benefit

Domenic: conflicts with any base classes that authors might want to use, because can't have more than one

<past> acl leaverou

lea: Value space of this new property... looking at thread seems to mix input types with element types

<Zakim> leaverou, you wanted to ask about property values

lea: e.g. range -> input type=range; textarea -> textarea

lea: worried it might not be future-proof

lea: perhaps a pseudo-selector syntax might work? e.g. writing out the tag name and if want to specify similar to input type=range use input[type=range]

annevk: could we use input-range?

lea: introduces a new microsyntax

Domenic: doing that anyway, but it's a subset of an existing one

annevk: but enums are much easier to parse

lea: wouldn't need a full CSS parser

sanketj: type as an attribute is very familiar, in input and button

sanketj: so keeping alignment would be good for developers

<zcorpan> input[type=range] vs input[type="range"] would be surprising if only one of them work

Domenic: I'm sympathetic with this worry. We had this problem when solving focus thing

Domenic: didn't come up with a good solution

Domenic: but also this proposal is very simple, and that's attractive

Domenic: do we have anticipate conflicts between tag names and input types?

Domenic: I could see that happening

<dbaron> (total side comment on an earlier discussion: the details of the keyboard activation behavior for buttons are *awful*, see https://issues.chromium.org/issues/40863985#comment6 )

lea: we already have conflicts, like search

Domenic: there are complexities to attribute selector syntax, but also sympathetic because devs might find it useful

lea: also room for future extension, e.g. if we need to identify children of a particular eleents

annevk: it's not a microsyntax, it's an enum

annevk: what if you put random other things in?

??: could restrict it to [missed]

lea: just restrict it to <ident> '['...

zcorpan: it's surprising to have a syntax that looks like a selector but parses differently

zcorpan: e.g. people will expect to be able to use quotes here

zcorpan: also, select element has two different kinds of widgets, which have a complex way of deciding which one to use

zcorpan: so select[multiple] or select[size]

lea: if we went with enum approach, how would you distinguisH?

zcorpan: select-dropdown vs select-somethingelse for example

lea: but now moved to unfamiliar keywords

lea: introduces more API surface

lea: if connecting to something already familiar with, then easier to relate

annevk: if know about select, select-optionA and select-optionB is not that hard

<dbaron> (if it's select-single and select-multiple?)

lea: how would it grow in 10 years?

Domenic, anne: probably only ~ 5 values

lea: ideally this should serve all the "behaves like this element" use cases

keithamus: value of button adheres to both options, so let's resolve on button and we can have this argument when we need it?

lea: I think 2 main classes of use cases

lea: custom elements that behave like buttons

lea: and custom elements that wrap buttons

lea: in latter case, which element do you want to actually be the popover target?

lea: whereas in first case you generally want to make that custom elemet a popover target

lea: Seen it come up many times, a big class of custom elements is simply wrapping a native element and adding some scaffolding / styling

lea: essentially want to forward things to the shadow DOM built-in element

lea: what do people think?

???: for subset of that problem, doing a breakout tomorrow

lea: worried we solve this as smaller problems and not seeing the forest for the trees

gregwhitworth: scenario in which you bind button via popover target to custom element ... is it because you don't know the ID? why is it a problem

sanketj: wrapped button is largely to get around the limitation that we are trying to solve

sanketj: so if we solve this, maybe we'll start seeing less of that pattern

bkardell_: was going to say the same

bkardell_: we've talked about this kind of thing before

bkardell_: e.g. referencetarget

<leaverou2> @fantasai @sanketj I don’t think so, happy to discuss further but don't want to derail this discussion

bkardell_: some of it comes out of Apple's objection to 'is'

bkardell_: is it a button, or does it contain a button? Is it compositiion or inheritance?

keithamus: one way to get around lack of built-in is to use referencetarget

lea: still need an easy way to forward internals in an API

lea: right now need to reimplement everything

bkardell_: I think for button this works fine, but it's the easiest

bkardell_: how realistic is it to extend

bkardell_: do you run into the same kind of problems if you'r doing inheritance-based things for e.g. select

bkardell_: how can you say "this is a select"

bkardell_: wondering if we've thought about those limits, are we ok with them

bkardell_: will we end up with multiple different solutions

bkardell_: for button we can infer so much of the magic, we know exactly what it means to be a button

bkardell_: no parts to it

sanketj: type attribute, when we add things to it, have ability to think through -- does it make sense? It's not allowing eveyrthing

annevk: and what additional API params you need for it

bkardell_: it took so long to get one...

annevk: good to start. let's start with button!

<leaverou2> @Domenic btw that proposal also uses "meta-selectors" to specify a class of elements, whose grammar is defined *exactly* how I described :)

<Domenic> Indeed, there was a reason we didn't ship it :)

sanketj: seems to be overall support for working on this

sanketj: some issues to note, e.g how does type reflect into role; how to deal with element/attribute name conflicts

sanketj: we'll work on it

annevk: can you open issue agianst HTML spec also?

sanketj: yes

bkardell_: would you pick one more besides button to think through?

sanketj: currently submit/reset

sanketj: but label could be another one

annevk: those are often requested (other than reset)

chrishtr: can we resolve on what we agree on so far?

<sanketj> PROPOSED: elementInternals.type='button' enables custom elements to get button-like semantics

<keithamus> https://open-ui.org/components/richer-text-fields.explainer/

RESOLUTION: elementInternals.type='button' enables custom elements to get button-like semantics

richer text fields

keithamus: Lots of cases where ppl use input type=text or textarea, but want slightly richer than plaintext

<dbaron> https://open-ui.org/components/richer-text-fields.explainer/

keithamus: but stepping into contenteditable is a minefield

keithamus: my proposal is to enable richer textfields

keithamus: first one is just input ranges

keithamus: want to extrac input ranges from input type=text or textarea

keithamus: it's very good to get boundingclientrects for text selection

keithamus: area of text for formatting toolbars

keithamus: wanted to ask about opinions

siliu1: Topic on WHATWG agenda about API for exposing selection bounds

keithamus: range?

siliu1: Returning a DOMRect

keithamus: is that configurable? can you extract information based on e.g. syntax highlighting? Can I extract individual characters or ..

siliu1: Current API only exposes [missed]

keithamus: input ranges and textareas, needs a bit more than DOMRects, ranges

keithamus: I would refer to explainer some use cases for each

keithamus: allow popover controls anchored to selection

keithamus: but can also feed into CSS Highlights API

keithamus: purposes of this are to do syntax highlighting in a textarea

keithamus: e.g. github.com do syntax highlighting

keithamus: today it's very difficult to do

keithamus: e.g. underlay a <pre> element with colors

keithamus: so would like to explore those two -- getting range information and feed into CSS Highlights

sanketj: being able to put highlights into input and textarea is something we are supportive of, use case fo rhighlights API

sanketj: do you actually need a range object, or do you just need the highlight?

Domenic: ranges are complicated objects. what is the actual functionality you want?

keithamus: something to feed to CSS highlight API

keithamus: and some level of bounding rects

keithamus: bounding rects are useful, 2 APIs for selection

sanketj: ability to get the boundingClientRect off the native caret or selection in input/textarea

sanketj: is that what you want, or do you want to create your own insertion caret and get bounding rect of that?

keithamus: both

sanketj: so you use your own selection and browser selection?

keithamus: e.g. display floating toolbar on the user's selection of text

keithamus: but may also show popups

annevk: not sure if you need ranges, just offsets

keithamus: not as complex as the rest of the DOM wher eyou need full ranges

leaverou2: how would the CSS highlights api work?

annevk: feed highlights some new kind of thing

leaverou2: all for fixing the problems with range

Domenic: did it once already, made staticrange

Domenic: Input offset

annevk: selection offset in select

annevk: can't have multiple things that are highlighted

dandclark: can we re-use static ranges for it?

annevk: highlight registry, if you store info on the elmeent couldn't you just feed the element to the registry?

sanketj: would need node to be textarea/input

annevk: need to know where the text is stored

annevk: has all the info

fantasai: So many questions...

fantasai: The bounding box of a highlight isn't well defined in CSS.

fantasai: so far that's been intentionally undefined

fantasai: exposing it via a new API seems iffy

fantasai: that's why you can't do background images

dbaron: we already have an API

emilio: returns bounding rect of text, may or may not match painted highlight

fantasai: The highlight apis can only change colors. Can't make bold/italic/etc. Does that satisfy all use cases?

keithamus: I'm happy with that for my use cases.

fantasai: You started by talking about richer text, that typically implies bold and italics, that implies other stuff. If it's just plain text that's syntax highlighted, implies minimal amount of formatting.

fantasai: once you get past plain text, need to consider i18n and a11y requirements

annevk: then you're basically at contenteditable

keithamus: which we're trying to avoid

fantasai: so you need to clearly define what your scope is, and why that's the scope

leaverou: suggest looking through this explainer, many use cases solved by highlights API

leaverou: very well done explainer

leaverou: idk what's the story about ranges that span shadow DOM boundaries

leaverou: but what if say textarea is text node in shadow DOM

leaverou: and once we have ranges that can cross shadow DOM boundaries, it's a normal range

emilio: no, because that shadow DOM is closed. Can't see inside it

annevk: Also why need cross-root selection. All within the same root.

leaverou: but it's in the shadow root

annevk: but that already work

leaverou: if you can't give access to the node, how do you make a Range?

annevk: don't need range, just need start/end offsets

annevk: if you have a range, cna reference two nodes and offsets

annevk: but here can just give the node and offsets

domenic: we need a new object, InputOffset that includes node and start/end offsets

annevk: could store the highlights on the input elements, then just need the start/end

leaverou: How do you design this new object so you don't have to constantly change all the offsets as the user is typing?

annevk: you'd have to constantly run through the highlighter

sanketj: maybe could have another type of abstract range, and would work with highlight API as is

Domenic: ranges offsets work a particular way, do you want to make a new thing which references offsets within the textarea text?

emilio: In Gecko, the way the selection is implemented as actual selection object

emilio: this is not exposed to website, just held by input/textarea

emilio: given you also want to have separate ranges, this is maybe moot 'cuz need a new though

emilio: but how do other engines implement

emilio: maybe what Domenic says of making ranges of editable elements, equivalent of selectionStart/End

emilio: could represent with static ranges

emilio: e.g. static range of input/textarea

emilio: means something different

emilio: DOM children of textarea don't change when editing

Domenic: what if you use DOM APIs to add children?

emilio: you wouldn't be able to add

annevk: we have dedicated selection API, why not have dedicated highlight APi

annevk: don't need a lot of things

annevk: call setHighlight on the element, and pass the element in along with start/end offset arguments

annevk: I dont' think we should use range for this

emilio: I would rather add to global highlight registry

keithamus: need more than that, also need the highlight name

sanketj: if you want highlight that does more than just input, gives effects in regular dom, need a combined API for it

emilio: since highlight is global. don't think you want scoped highlights

emilio: but whatever shape you have for a range, have for this

keithamus: could have addRange and chuck in some ranges

annevk: setlike currently. That's going to be fun.

Domenic: too detailed, let's continue

sanketj: one thing I saw was ability to have colors change on highlights when e.g. hovered

sanketj: prototyping in Chromium

sanketj: hope that solves this use case

keithamus: solves the use case of ?? but another case is github's text expander

keithamus: type a set prhase, then caret displays a popup

keithamus: combining these two APIs

keithamus: if can get bounding rect of current selection, can display a popup

keithamus: crowbot can make better use of CSS highlightsFromPoint

keithamus: but subtly different use case

sanketj: because there you're dealing with native caret, not custom

keithamus: right, asking for current selection

keithamus: we could use selectionStart/End properties, but still need boundingClientRect of some kind

annevk: could have that API on the element itself

chrishtr: at the beginning you said contenteditable is not a good solution

chrishtr: reason given in explainer seems to be bugs? compat?

chrishtr: is there a fundamental reason, or would it be a good fit if it was fixed/

annevk: there's a lot to fix

keithamus: a lot to fix, especially wrt a11y

keithamus: also hard to use

keithamus: quite powerful, but slippery slope

keithamus: it creates lots of traps

keithamus: but then we end up with these hacks

ntim: API for textarea is much simpler than for contenteditable

ntim: e.g. want to extract raw text

ntim: weird whitespace issues

emilio: not opposed to adding, but feature is getting client rects feel reasonable extension

emilio: but also there's work at least in Gecko to get contenteditable=plaintextonly working

emilio: and that presumably doesn't hit the same edge cases

chrishtr: could we have a restricted mode of contenteditable that avoids the problems of too powerful, and avoids the other bugs?

emilio: that's basically what plaintextonly does

keithamus: don't know how it works with form submissions, does it at all?

zcorpan: would need to manually set value

emilio: at least the extensions to expose things that selection API exposes already for textarea seems reasonable to me

emilio: in Gecko easy to implement because we just use internal selection

fantasai: one thing in related use cases is perf implications

fantasai: contenteditable has been a problem with very large amounts of text -- weight of DOM when syntax highighting is very high

keithamus: a motivation for CSS highlights?

sanketj: yes, that was a motivation

Text Suggestions

keithamus: writingsuggestions attribute to limit suggestions from browsers

keithamus: auto-complete certain values

keithamus: great but we feel we can provide more contextually-relevant text suggestions, either using AI or not

keithamus: issue completion, tabmention completion

keithamus: there's a ghost text feature, where we have an LLM that provides contextually-relevant PR descriptions

keithamus: similar to GMail

keithamus: doing similar hacks, underlaying transparent <pre>

keithamus: would be useful to have API to provide text completion suggestions

keithamus: allow to complete rest of the sentence

keithamus: use regular platform keyboard shortcuts

keithamus: suggestion is suggestvalue="string"

keithamus: and you get an event if the user accepts or rejects

gregwhitworth: is there still an Editing WG?

gregwhitworth: good group to ask

keithamus: should I take this to them?

annevk: probably

ACTION: keithamus to take proposal to Editing WG

Domenic: they'll know how it interacts with IMEs and other things

Input Masking

keithamus: add additional characters to break up contiguous inputs

<gregwhitworth> I WANT INPUT MASKING!!!!

keithamus: e.g. MSFT serial number, insert dashes

keithamus: lots of libraries do this today

<tantek> or phone numbers, credit card numbers, etc.

keithamus: pattern e.g. 0s or As for numeric or alphanumeric input

keithamus: and any other characters are inserted

<tantek> also copy/paste interactions for such data that are currently quite broken across the web

keithamus: some affordances in date input e.g.

keithamus: but many need to be custom

keithamus: having some kind of attribute like "mask" on input type=text

keithamus: welcome suggestions

keithamus: 0 represents numeric, A represents alpha character, * represents any character

keithamus: work like exisitng libraries but in the platform

<zcorpan> Demo of imaskjs https://imask.js.org/

annevk: existing mask proposal in HTML

?

<tantek> github issue?

<emilio> +1 to split this

keithamus: Looked for examples of existing applications, not much affordance for internationalization

<tantek> link to explainer?

keithamus: so trying to show just the current stuff

annevk: might want to grab aphillips and ask him

<gregwhitworth> tantek https://open-ui.org/components/richer-text-fields.explainer/

Domenic: +1 great idea, let's solve this, people have wanted forever

<Zakim> Domenic, you wanted to support, describe difficulty of speccing interoperably

Domenic: good job of explaining what kind of cowpath we should pave

Domenic: I think it would be difficult to specify this in the level of interop we want

Domenic: libraries have addressed how to handle typing of the mask character, handle backspace, etc.

<tantek> gregwhitworth do you mean https://open-ui.org/components/richer-text-fields.explainer/#input-masking ?

Domenic: but we don't define this for input in general

Domenic: some idk how you're going to write the spec

<estellevw> How would you surface the mask to AT?

<Zakim> tantek, you wanted to note copy/paste interaction/impacts, problems today and to also note this sounds like it may be jumping to too narrowly a defined problem/solution

tantek: +1 to splitting this proposal out

tantek: examples given look good

tantek: consider expanding to other composite fields

tantek: classical is addresses

tantek: UI pain is copy-paste

tantek: forget auto-fill, cold start

tantek: going from text message and I copy an address, and want to hit paste

tantek: have to do it in small pieces

tantek: but one effective value

tantek: that you wnat to compose and fill

tantek: slightly different than the types here

tantek: so I would encourage expand the use case

annevk: UA would have to handle the paste case

tantek: I chose address because it's a known problem because can't do internationally

annevk: but have to split text in some way, and that's up to UA and not up to ..

fantasai: I wanted to raise i18n issues. What is numeric? Regular digits, or any digits in any writing system?

fantasai: Probably a bunch of limitations that somebody might want to do. Don't we have a pattern attribute?

annevk: yes, but it's a regex and hard to inspect and go back to UI hints

fantasai: can they work together?

keithamus: I'd have liked to have a mask attribute is ??? in combination with pattern.

keithamus: but I wanted to be conservative and stick to userland use cases

keithamus: where masking restricts which characters enter the input

annevk: that's important and worth keeping

Domenic: my first pass is that pattern is validation and mask is about controlling input

leaverou2: And pattern still operates on the input minus these formatting characters

annevk: and mask is declarative so we could infer keyboard

annevk: so for some masks we might show numeric keyboard

past: we're out of time

keithamus: the intent here was for you to tell me it's a horrible idea and not to pursue it, but given that you didn't I'll keep working oni t

emilio: Going to point out that there's maybe another way to implement with multiple fields

emilio: use case I want to figure out, can you fade part of the pattern

emilio: if you have [###] might want to style the brackets differently

emilio: could do with custom highlights!

emilio: another way to build this would be to have different fields for editable parts, when you hit the end of one you get to the next

emilio: right now requries too much JS

emilio: but that could be better defined, and maybe more styleable?

keithamus: one case it doesn't address was, what about one-time codes. Currently as e.g. 6 input box

keithamus: maybe we have an input group element

keithamus: that provides the semantic for the back and forth

leaverou2: it's still styling

keithamus: it's conceptually one end value due to inputgroup element

keithamus: but can style independnetly

leaverou2: more complex because have to define when go from one field to another

keithamus: same problem as masking

keithamus: mask characters may or may not want to display up front

keithamus: and mask may change as the input goes in

keithamus: e.g. credit card number could be sets of 4 numbers, unless it starts with a 3 in which case last is 5 numbers

leaverou2: in some cases mask characters are just visual, want to strip them in the back end

leaverou2: but in other cases (e.g. dates) you want to include those in the value

leaverou2: that also affects how pattern matches

zcorpan: https:// prefix shouldn't be a mask, but a placeholder

<leaverou2> - Prefixes and suffixes? whatwg/html#10314

leaverou2: no you want it as part of the value. But you don't want people to have to type it

leaverou2: that does address the intermediate characters though

Meeting closed.

end

<tantek> Thank you fantasai for scribing and Panos for chairing

<astearns> w3c/csswg-drafts#4573 is the one topic we identified

<addison> https://github.com/w3c/i18n-activity/issues?q=is%3Aissue+is%3Aopen+label%3AAgenda%2BI18N%2BCSS

<addison> https://github.com/w3c/i18n-activity/issues?q=is%3Aissue+is%3Aopen+label%3Aneeds-resolution+label%3Awg%3Acss

<TabAtkins> github-bot, take up w3c/csswg-drafts#4573

[css‑fonts‑4] Create keywords for `unicode‑range`

<github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/4573.

<TabAtkins> astearns: We had a reoslution, but there was continued discussion. Chris, take it away

<TabAtkins> ChrisL: I was getting an idea of what we had consensus on, that was to use unicode proeprties SCript and Script Extension

<TabAtkins> ChrisL: so if Script Extension says its "deva", you'd get all the characters with that extension from the keyword `deva`

<TabAtkins> ChrisL: and you'd get the Common block by default, but with a way to exclude perhaps

<TabAtkins> ChrisL: Also, the resolution covered a way to add some ranges, but people might want to exclude some ranges.

<TabAtkins> addison: so use the 1594 script code to include scripts

<TabAtkins> addison: with maybe special handling for common?

<TabAtkins> ChrisL: common would always be included if not listed, but you could exclude it

<TabAtkins> addison: this is in addition to do codepoints?

<TabAtkins> ChrisL: yes

TabAtkins: basically a shorthand for one or more codepoint ranges

<TabAtkins> addison: have you looked at - this isn't regex, but at the regex unicode categories?

<TabAtkins> addison: people might want character classes

<TabAtkins> addison: also, CLDR's sets of characters by locale or by language

<TabAtkins> addison: maybe a source

<TabAtkins> addison: just trying to think of why people would be using this

<TabAtkins> addison: a common thing iv'e seen is people only wanting to accept certain chars, so only the ones actualyl used by finnish or hungarian. that's a bigger list than just the alphabet. unicode has a list like that.

<TabAtkins> addison: otherwise this seems, well, not unreasonble

<TabAtkins> addison: don't want to sound reticent, no shade

<TabAtkins> addison: jsut want to suggest other places to potentially look

https://www.w3.org/TR/css-text-4/#character-properties

<TabAtkins> fantasai: we have precedent for including script extensions

<TabAtkins> fantasai: we generically include it in Appendix E of Text, it's the right thing to do pretty much everywhere we reference the Script proeprty

<TabAtkins> fantasai: including common makes sense; ability to exclude common seems interesting but tricky, especially with combining marks

<TabAtkins> ChrisL: yeah, coudln't think of a use-case for it

<TabAtkins> fantasai: yeah, having a hyphen or something probably doesn't want to use a different font

<TabAtkins> fantasai: so my suggestion is not have the common-exclusion ability unless people ask

<TabAtkins> astearns: So do you still want to exclude other keywords?

<TabAtkins> fantasai: seems reasonable, yes

<TabAtkins> astearns: Big reason to exclude common is if you have a stack, the first font is for Korean, the rest of the stack is for everything else. You'd exclude common from teh Korean font. But you can also do that by flipping the font stack and excluding Korean, instead

<TabAtkins> florian: Yes, but also affects which fonts line-sizing and units takes from. If it's predominantly from Korean, you might want to take from that font even if there's fallback

<TabAtkins> fantasai: you're more likely to want to exclude punctuation than Common, like combining marks are in Common. You don't want base characters form one font and combining from another.

<TabAtkins> TabAtkins: yeah, like addison said about the regex unicode categories, they have Punctuation

<TabAtkins> fantasai: not full power, you can match on like east-asian width, doesn't seem useful. just some things.

<TabAtkins> addison: Yeah, just looking at it for a few suggestions, not necessarily all. I'm spitballing.

<TabAtkins> fantasai: I think we really only need Script and General category.

<TabAtkins> astearns: So we'd only need Script ,is that excluding script Extensions?

<TabAtkins> fantasai: No, including that. No use of CSS wouldn't want Script Extensions. Our *definition* of the Script proeprty includes that by default.

<TabAtkins> astearns: So can we resovle on using SCript and Script Extensions to create keywords?

<TabAtkins> xfq: Also General?

<TabAtkins> fantasai: We can start from the Script and add a few others as needed

<TabAtkins> astearns: Any objections?

RESOLUTION: Add a set of keywords from SCript and Script Extensions

<TabAtkins> astearns: now about General

<TabAtkins> fantasai: Yeah, I'm not as sure about General Category, if they're trying to include letters but don't get combining marks. But excluding General is okay

<TabAtkins> xfq: Yeah, and they can always generate a codepoint list if they need

fantasai: (clarifying) including General is bad, excluding General is ok

<TabAtkins> fantasai: *Including* General seems footgun-y, but *excluding* General seems reasoanble.

<TabAtkins> astearns: that's fine by me

<TabAtkins> astearns: anyone want to argue for something more than that now, rather than waiting until it's justified later by requests?

RESOLUTION: Punting on General category for now.

<TabAtkins> astearns: switching to the question of whether we do "exclusion" as well as inclusion

<TabAtkins> ChrisL: Yes, let's get a resolution

<TabAtkins> fantasai: When excluding, dont' want to exclude Common alongside the others (but including it alongside the specified value is okay)

<TabAtkins> proposed: script categories can be excluded (except for Common)

RESOLUTION: script categories can be excluded (except for Common)

<TabAtkins> ChrisL: So extending the grammar will break current impls

<TabAtkins> fantasai: So you declare it twice?

TabAtkins: just like normal

<TabAtkins> ChrisL: Ah so last one that's valid

TabAtkins: existing unicode grammar is the worst

TabAtkins: I tried, it cannot be reasonably be described with CSS tokenization rules

TabAtkins: options are special tokenization (which breaks selector u+a)

TabAtkins: or do cusotm parsing of unicode-range , which is what we're doing now

TabAtkins: I suggest keeping to that, and add functional form that expresses with numbers

TabAtkins: and build on that

<kbabbitt> +1

florian: so unicode(\d\d\d\d)

TabAtkins: you can't directly express hex values because might be ident or dimension or number

TabAtkins: but you coudl do xHHHH

astearns: so you're proposing using the same descriptor that has the current unicode-range syntax

astearns: or a new functional value syntax that is cleaner and does what we want

astearns: is that better or worse than having an entirely separate descriptor?

TabAtkins: no opinion

astearns: I think it's probably better to re-use the name; invalidity itneractions are more obvious

ChrisL: agreed

TabAtkins: actually, i change my mind. I have a very strong opinion which is to agree with you

TabAtkins: Right now unicode-range descriptor is special magic syntax

TabAtkins: so sure apply them both

astearns: what do we call the function?

florian: unicode()

fantasai: u()

ChrisL: what about negation?

TabAtkins: a "not" keyword to prefix

dbaron: maybe be more explicit about subsetting the font to only characters in that range?

TabAtkins: maybe just "codepoints()"

florian: I like u()

[some mixup about parsing weirdness]

TabAtkins: Oh, actually I mean I disagree with astearns

TabAtkins: we should use a new descriptor name

?: Then how do they interact?

TabAtkins: then let's intersect them. Initial value is 'all'

ChrisL: Could also reset unicode-range to all when encountering the new thing

dbaron: then you have a weird ordering dependency

<TabAtkins> fantasai: it would be weird if you set the new thing, then unicode-range

<TabAtkins> fantasai: they're both setting the same thing, it's weird if one invalidates the other

fantasai: Maybe unicode-range and unicode-set, and take tab's suggestion to intersect them

<TabAtkins> addison: table this, since i18n isn't helpful? you're on the right track.

<TabAtkins> addison: A related topic

<addison> https://unicode.org/cldr/charts/45/summary/kam.html

<TabAtkins> addison: you can see that it has sets of chars in use for a language

<TabAtkins> addison: for a locale you can see what's pretty commonly used, if you use that as a range it's similar to what you'd want in a font

<addison> https://unicode.org/cldr/charts/45/summary/ks.html

<TabAtkins> addison: not *as* exhaustive as some things

<TabAtkins> addison: but it kinda describes what your font should support if it's rendering locale=ks, etc

<TabAtkins> fantasai: I think this is more restrictive than what you usually want. you might include words from another lang, and you've dropped chars you wouldn't otherwise drop

<TabAtkins> astearns: Any other comments before line-clamp?

writing-mode:sideways

<TabAtkins> addison: it's in the spec, but not widely implemented

<TabAtkins> addison: impl is pretty desired here

<TabAtkins> dbaron: I think theres' ongoing work in Chrome. Don't hold me to that, but i'm pretty sure

<xfq> Chromium issue: https://issues.chromium.org/issues/40501131

<addison> #10844

<TabAtkins> github-bot, take up w3c/csswg-drafts#10844

[css-overflow] Line-clamp and approaches to ellipsis insertion

<github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10844.

<TabAtkins> florian: As you might remember, line-clamp has been specced for a few years based on fragmentation

<TabAtkins> florian: the longhand that triggers that is called continue:discard

<TabAtkins> florian: andreu has been working on an alternative not based on fragmentation, which we're calling continue:collapse

<TabAtkins> florian: aside from the primary diff between these two, one thing was deliberately designed into continue:discard and not discussed much, and apparently assumed away in continue:collapse, I wanted to talk about it

<TabAtkins> florian: on the line you add the ellipsis, how

<TabAtkins> florian: the pre-existing ellipsis mechanism is from text-overflow:ellipsis

<TabAtkins> florian: I argue that's not appropriate here

<TabAtkins> florian: that's for a single line, which is overflowing the line box. you chop it off at the end of the box, and then some, just enought to add the ellipsis char

<TabAtkins> florian: this is a physical operation, it makes sense in that context

<TabAtkins> florian: but in line-clamp we're not overflowing

<TabAtkins> florian: the logical way to remove content in this context is to act like linebreaking. you basically have a line that's a little too short, so you put a little less content in it

<TabAtkins> florian: this means you chop off from the *logical* end of the line, not the physical end

<TabAtkins> florian: if you don't do this, you'll chop the logical *middle* of the line, missing *two* parts of the text

<TabAtkins> florian: the following lines, and the logical middle of your line

<TabAtkins> florian: if you're trying to read the text, it makes no sense

<TabAtkins> florian: it's also weird if you split in the middle of words

<TabAtkins> florian: dropping at the same boundaries as line wrapping allows you significantly reduces the amount of misunderstandings you can get from chopping text

<TabAtkins> florian: kind of secondary, but still

<TabAtkins> florian: the issue is a bunch of pictures of text asking how weird it is to chop physically rather than logically

<TabAtkins> florian: so what I want is just to establish whether, regardless of discard or collapse, we should indeed preserve this "just do line breaking and break logically" behavior

<TabAtkins> florian: also, now that we know how much stuff to remove for the ellipsis, where do we put it? physical end or logical end of the line?

<TabAtkins> florian: but that's only relevant if we agree on the first

<TabAtkins> addison: i18n discussed this at length recently

<TabAtkins> addison: we're fairly strongly supportive of logical string truncation

<TabAtkins> addison: it means the kept part of the string makes sense

<TabAtkins> addison: and if you made the box wider, the removed text would be at the end of the line and would make sense to come in

<TabAtkins> addison: So we think logical truncation makes the most sense. and is the easiest here, because you find a break point and then proceed, rather than doing a bunch of ranges

<TabAtkins> andreubotella: currently it's implemented the same as text-overflow:ellipsis in Chrome, after bidi reordering

<TabAtkins> andreubotella: I don't oppose doing what Florian said, my initial impl was just following existing chrome ellipsis behavior

<TabAtkins> andreubotella: but having heard the bidi reasoning, that sounds fine

<TabAtkins> andreubotella: might offer some impl challenges, but don't thi8nk they're insurmountable considering the benefit

<TabAtkins> dbaron: my intuition about the logical truncation is that it's sort of like you're doing layout into a shorter line (shrunk by the ellipsis)

<TabAtkins> dbaron: that's one way to think about it

<TabAtkins> dbaron: one subtlety is how you place the ellipsis, whether it's good to be closer to the text or further after doing this shorter-line layout

<TabAtkins> dbaron: so flush with the remaining text, versus flush with the line-end

<TabAtkins> dbaron: I think I reasonably strongly agree with the consensus on logical truncation, but don't have a strong opinion on placement of the ellipsis

<TabAtkins> dbaron: it's interesting in both cases from a layout perspective

<TabAtkins> florian: addison had an interesting comment about that

<TabAtkins> emilio: so we need to agree on ellipsis insertion not messing with following lines layout

<TabAtkins> florian: in the continue:collapse that's true, but discard it wouldn't

<TabAtkins> andreubotella: depends on how it's implemented

<TabAtkins> andreubotella: in chromium I don't think there's a way to preserve the breakpoint after a linebreak

<TabAtkins> andreubotella: so the way I was planning to go was to do it all at linebreak time, then the displaced content is pushed to the next line

<TabAtkins> andreubotella: but that's not the same as the impl I think emilio is thinking of

<TabAtkins> emilio: it would be silly because you'd still have to do the layout of everything past the break point

<TabAtkins> andreubotella: my impl wouldn't be doing the extra work

<TabAtkins> emilio: so you'd insert it during the first layout pass?

<TabAtkins> andreubotella: yes, tho with line-clamp:auto you'd still get two layouts

<TabAtkins> emilio: I dont' thi8nk we want line-clamp to cause multipass layout

<TabAtkins> andreubotella: you need it for auto, that's "as many lines as fit". not purely a paint-time info

<TabAtkins> andreubotella: unless it is in gecko?

<TabAtkins> emilio: you clamp the inner block and outer block, it's one pass

<TabAtkins> (I don't understand any of this, hopefully it makes sense)

<TabAtkins> addison: we talked about positioning in the WG convo

<TabAtkins> addison: our thinking is that the ellipsis generally wants to behave as part of the text

<TabAtkins> addison: the trick is you probably want to provide the equivalent of a strong marker that matches the next inked character's direction

<TabAtkins> addison: you need to know if the run is gonna break or not. ellipsis is a neutral character, you want it to jump to the left or right side of the text, according to where the bidi algo would have put the ellipsis in if was actually in the text

<TabAtkins> florian: give it directionality of the thing it replaces

<TabAtkins> fantasai: no, directionality of paragraph

<TabAtkins> florian: using what it replaces intrigues me

<TabAtkins> addison: you don't want it isolated, you want to let bidi just do the job of deciding left or right side

<TabAtkins> addison: the characters just before it only provide half the context

<TabAtkins> fantasai: you also have to extract it from any embeddings

<TabAtkins> fantasai: two approaches you can take

<TabAtkins> fantasai: one is it acts like the preceding char, and attaches to that.

<TabAtkins> fantasai: dont' think we want that

<TabAtkins> fantasai: other is that it belongs to the paragraph

<TabAtkins> fantasai: we're not ellipsizing a particular phrase, we're ellipsizing the whole paragraph, so having it take the paragraph's qualities makes sense

<TabAtkins> fantasai: it also helps show it's a continuation of the paragraph, not the single phrase

<TabAtkins> addison: that's potentially fair, I did some playing with this

<TabAtkins> addison: it kinda behaves normally

<TabAtkins> addison: I think it's worth going offline and writing it down better, describing why it's a good proxy

<TabAtkins> addison: but it is possible that what you're saying it the right answer

<TabAtkins> fantasai: the fundamental questions are logical or physical clipping (I think logical)

<TabAtkins> fantasai: and whether the ellipsis is attached to the immediately preceding character or an attribute of the paragraph itself, and from that the rest falls out

<TabAtkins> florian: I support opening a followup for this. My starting position matched fantasai, but addison's remarks made me think there were subtleties

<TabAtkins> fantasai: since we're breaking form linebreaking proeprties, not per-character proeprties

<TabAtkins> fantasai: it seems like a more natural break, not as strongly attached to the previous character as you would if you broke in the middle of a word

<Zakim> Bert, you wanted to ask how you know what the language/direction of the ellipsis text is.

<TabAtkins> Bert: might be different issue, from what I understand it's not always just an ellipsis character, but can be something else

<TabAtkins> florian: the spec has an answer for that, whether that answer is what we want is another question

<TabAtkins> Bert: okay. if it's an ellipsis you can say it's neutral, but if it's something else...

<TabAtkins> fantasai: I also think that case, if it's like "continues on page 25", if you break in the middle eof hot pink small text, but paragraph is generally normal sized black text, you want the "continues on" to follow the paragraph's styling.

<TabAtkins> fantasai: and directinality

<TabAtkins> fantasai: the ellipsis probably needs to be isolated, but it should take the paragraph's directionality

<TabAtkins> andreubotella: I don't have an opinion on this discussion, but if we end up going with "matching the next/prev character", anything other than the paragraph base directiond

<TabAtkins> andreubotella: I think in the spec it should be specified in terms of the bidi level of the ellipsis character or replacement string

<TabAtkins> andreubotella: Becuase if you're breaking as part of line-breaking, or even afterwards, you wouldn't be placed back further than the bidi algorithm's progress. you'd at least have the levels of the shown characters.

<TabAtkins> andreubotella: this follows, should be the same as adding a LTR Mark character

<TabAtkins> andreubotella: so I think it should be specced to match impls in that degree

<TabAtkins> emilio: agree

<TabAtkins> emilio: I think we should at least agree to not do the physical truncation the naive way

<TabAtkins> emilio: there are multiple ways to do this that makes sense

<TabAtkins> emilio: imagine you don't have the ability to redo the line layout at that tpoint

<TabAtkins> emilio: we should still truncate at a point that makes sense, might mean truncating more text than what you originally needed.

<TabAtkins> emilio: but that's still way better than putting the ellipsis at the physical end

<TabAtkins> emilio: so I think we should at least agree on that, not naive physical clipping where you just remove characters until it fits

<TabAtkins> florian: I agree, but I'm not sure what you're proposing is "enough"

<TabAtkins> emilio: trying to start from a point nobody disagrees

<TabAtkins> emilio: I also feel strongly we shoudln'ta effect layout of following lines, to require no relayout

<TabAtkins> fantasai: one possible resolution is you remove up to a valid linebreaking point, not less than that

<TabAtkins> florian: in logical space? or is that a separate resolution?

<TabAtkins> fantasai: separate. Just saying we remove chunk in linebreaking chunks

<TabAtkins> addison: aren't those related? can you compute a linebreaking opportunity physically?

<TabAtkins> fantasai: you can't remove a single letter from English, for example

TabAtkins: Emilio, wondering about implications of what you were saying

TabAtkins: seems you do line layout, figure out lines

TabAtkins: on final line, truncate somehow and put ellipsis in

TabAtkins: and missing words don't flow into the next line

TabAtkins: they are just hiding

emilio: right, don't relayout past breaking point

<TabAtkins> andreubotella: Not sure if we should decide today, it has implications on impl

<TabAtkins> emilio: yeah, just wanted to resolve on basic constraints first, like we don't trigger multipass layout

<TabAtkins> emilio: you'd expect clamping to make the layout cheaper, not more expensive

<TabAtkins> andreubotella: i'm not sure if in blink you can drop lines after layout

<TabAtkins> emilio: I think you can, you just don't paint them

<TabAtkins> florian: regardless, I think we should ellipsize in logical order

<TabAtkins> xiaochengh: I agree we should do logical clamping

<TabAtkins> xiaochengh: but seems complicated, no one size fits all. might have different fonts or colors on ellipsis

<TabAtkins> xiaochengh: so I think we need a pseudo-element to style the ellipsis

<TabAtkins> florian: eventually yes, I don't think it's needed as a level 1 feature

<TabAtkins> xiaochengh: with a pseudo-element we could postpone some of the issues, like where to put the ellipsis (flush with text, or flush with line end)

<TabAtkins> florian: maybe with pseudo we could override some of the decisions, but we'd still need a default answer

<Zakim> Bert, you wanted to ask if 'line-clamp: "\0A …"' works to put the ellipsis on a separate line? And if so, can I right-align that line?

<TabAtkins> xiaochengh: yeah but at least we wouldn't have to bikeshed too much since it wasn't as fatal to tet it wrong

<TabAtkins> astearns: no, defaults are still very important

<TabAtkins> Bert: ah, xiaocheng's suggestion just gave me an answer to what happens with the styling of the ellipsis

<TabAtkins> astearns: can we resolve to have line-clamp remove characters at break opportunities in logical order?

<TabAtkins> florian: Knowing there will be follow-up discussions.

<TabAtkins> astearns: concerns?

<TabAtkins> emilio: we can add a "barring impl craziness"

<TabAtkins> emilio: I think everyone agrees this is the right mode

<TabAtkins> florian: yeah, if it ends up impossible we'll have to revisit

<TabAtkins> astearns: so looks like agreement that it's necessary, and if impl blocks it, we'll still need some *third* thing

<TabAtkins> astearns: objections?

RESOLUTION: Remove characters *at* break opportunities *in* logical order, for line-break

<TabAtkins> florian: so I think we e need to still figure out alignment of the ellipsis, and then andreu and emilio argue about what happens with the remaining stuff on the line

<TabAtkins> emilio: okay

<TabAtkins> github-bot, take up w3c/csswg-drafts#1282

[css-logical] Flow-relative syntax for `margin`-like shorthands

<github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/1282.

<TabAtkins> florian: my memory of where we're stuck is we had a few proposals for syntax to opt into the flipping, and we were planning to evaluate those on the basis of triaging all properties as being "physical/logical is irrelevant" or "matters, but can go either way". that action has been on me for a long time, and still is

<TabAtkins> florian: I *think* that's where we're stuck

<TabAtkins> addison: I think that's the next. can we get cycles, and will that resolve this issue.

<TabAtkins> florian: I think that step is necessary, whether it's sufficient is fuzzier

<TabAtkins> florian: step doesn't *have* to be done by me. think it's been on me for a year or more

<TabAtkins> addison: at least July '23, yeah

<TabAtkins> astearns: can you outline what the task will detail?

<TabAtkins> astearns: saying "here's what someone needs to do, i'll get to it when I can, but if anyone wants to help here's the steps"

<TabAtkins> florian: I can try

<TabAtkins> astearns: any other suggestions for kicking it off?

<TabAtkins> addison: I think that's core

<TabAtkins> github-bot, take up w3c/csswg-drafts#10036

[css-fonts] Add generic font family, Khmer Mul

<github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10036.

<TabAtkins> addison: Richard has a proposal for a new generic family for Khmer mul

<TabAtkins> addison: specific generic type used in Khmer language

<TabAtkins> addison: we've done some generics, and those have mostly been things with widely-installed font bases, and in langs that are more familiar

<TabAtkins> addison: this one is less familiar, and the install base is more questionable. so maybe probing the boundaries of the rules for adding a generic

<TabAtkins> addison: Richard has a description for what is a "true" generic for this language, should we add it?

<TabAtkins> florian: I think, having talked with Richard, an argument is that this is similar to nastaliq, not visually but in terms of what kind of generic it is

<TabAtkins> florian: it's a distinctive type of lettering in this language, there's multiple fonts that do it. maybe some are preinstalled on windows, but not a lot of other platforms

<TabAtkins> ChrisL: in addition to what richard has written, i'll need a string of text in this language rendered as an image

<TabAtkins> florian: that's in the issue

<TabAtkins> ChrisL: good

<TabAtkins> dbaron: I don't know if we have this for other generics, but is there metadata in a font that identifies this?

<TabAtkins> xfq: no

<TabAtkins> addison: don't think so

<TabAtkins> dbaron: do we have it for other generics?

<TabAtkins> emilio: no

<TabAtkins> xfq: unlike nastaliq, which is a different - for regular Arabic speakers you can recognize the Naskh font, but for Urdu you might need to use nastaliq

<TabAtkins> xfq: but for this is more like for headings

<TabAtkins> florian: this is more like naskhaliq in Persian than Urdu. In Urdu you always use nastaliq, in Persian it's a distinct style that is valid.

<TabAtkins> florian: to dbaron's point, two ways

<TabAtkins> florian: you ship in an OS that's well known, you know the set of fonts shipped with it, you assign those to this keyword

<TabAtkins> florian: alternative is a setting screen where users can say which font to use for a particular font

<TabAtkins> florian: maybe also browsers could have a big database of fonts that exist, but less likely

<TabAtkins> emilio: on some OSes, mostly Android and other non-Mac Unix variants, font lookup is generally forwarded to the OS

<TabAtkins> emilio: so you can ask fontconfig for a "sans-serif" font

<TabAtkins> emilio: that's what I think all browsers do on Android/linux

<xfq> MoolBoran on Windows in this case

<TabAtkins> emilio: should we forward this request also?

<TabAtkins> emilio: so browsers aren't responsible for making this choice, bc we don't necessarily know it

<TabAtkins> emilio: like, is this a higher level request to other software as well?

<TabAtkins> astearns: do we specify how other generics select fonts?

<TabAtkins> [no]

<TabAtkins> emilio: we can specify it in CSS, but if there's no way to actually query it

<TabAtkins> emilio: without that we'd have to make things up, or bundle fonts

<TabAtkins> addison: can bundle config and the fonts

<TabAtkins> addison: to step back, the reason we're adding generics is to get us out of the trap of jamming local styles into the four buckets we had

<TabAtkins> addison: allowing to refer to things the way they would naturally

<TabAtkins> addison: so when we talk to people with a typographic system they tell us what their generic names are

<TabAtkins> addison: I think that's valuable; we're gonna continue to face this

<TabAtkins> astearns: we're over time, I think we should resolve to add this, or punt it back to the issue

<TabAtkins> astearns: proposed resolution is to add the new generic, any objections?

<fantasai> +1 to emilio's concerns

<TabAtkins> emilio: no objections, but we should file tickets to OS vendors/freetype/etc if we really expect this to get momentum

<TabAtkins> dbaron: there are also several more new generics, right?

<TabAtkins> florian: not too many, but yes

<xfq> https://www.w3.org/TR/css-fonts-4/#generic-font-families

<TabAtkins> emilio: right, would be great to not add to a pile of things we also can't implement

<TabAtkins> ChrisL: clarification, is this going in fonts 4 or 5?

<TabAtkins> fantasai: are there generic things in 4?

<TabAtkins> ChrisL: some

<TabAtkins> fantasai: I think 4 should be wrapping up

<TabAtkins> astearns: yeah, agree with 5

<TabAtkins> fantasai: so maybe kick the whole generic system to 5

<TabAtkins> astearns: is it enough to resolve to add it to 5?

<Bert> (B.t.w., some of the old generic families are somewhat encoded in the fonts themselves, in the form of Panose. Not sure if the data is reliable.)

<TabAtkins> florian: we can pull it back later if needed

<TabAtkins> ChrisL: the general structure about generic() and fang-song and nastaliq is in 4

<TabAtkins> fantasai: are there impls?

<TabAtkins> ChrisL: don't know, we don't have tests

<TabAtkins> florian: add it to a level, at the editor's discretion

<TabAtkins> astearns: so let's resolve to add to 4, alongside the existing ones. if it needs to move later, it can

<xfq> there are some tests in w3c/clreq#587

RESOLUTION: add the new keyword to Fonts 4

<TabAtkins> github-bot: end topic