Meeting minutes
New Issue Triage
<github-bot> I can't comment on that because it doesn't look like a github issue to me.
New PR Triage
<github-bot> I can't comment on that because it doesn't look like a github issue to me.
WPT Open PRs
<github-bot> I can't comment on that because it doesn't look like a github issue to me.
[css-fonts-5] Text Fitting: Default scaling limit #12886
<github-bot> I can't comment on that github issue because it's not in a repository I'm allowed to comment on, which are: w3c/aria w3c/aria-common w3c/core-aam w3c/accname w3c/html-aam.
@Ian: CSS working group is working on a highly requested feature. Given a short paragraph of text, say a heading, and a font size, say 20px, what this does is apply a transform to each individual line such that there is no free space at the end of the container. 2 modes, per line where each line has the same font size, and a paragraph mode that
… transforms all lines by the same amount.
Cynthia: Can we see a demo?
Ian: <shows demo>
Ian: In this example, the second line is stretched to fill the container, and then the first line is stretched to the same amount.
Ian: the next question is, what happens when there is page zoom applied?
Ian: The default implementation would mean that you are only growing the "base" font size, so if you have a 200% browser zoom, we would change the new "base" to double, but that may not actually change the font size.
Ian: on small devices where the container is based on viewport size, a zoom may not actually end up changing the font size.
Ian: one option considered is that we layout the whole page without browser zoom, record how big the font gets, say 100px and then layout the entire page again and use that first size as the minimum
Ian: this results in a need to render twice, quite expensive, especially on large sites on low-end devices
Siri: Also what happens when text spacing is applied?
Ian: That gets boosted as well, but I need to double check that.
Ian: we change the font size once to get it as close as possible, then apply a transform.
spectranaut_: In the first situation where we only grow the base font size and the text wraps, is there a transform applied?
Ian: when a line wraps, it will then need to grow to fit the container, meaning that a single line could have smaller text than when it wraps.
Ian: generally we consider text clipping to be worse than small text.
scott: with this feature, when zoom is applied, there is a chance that the text size never actually changes.
Ian: the base size will increase
scott: But to the user, the text won't change though
Ian: the boosted size is often going to be substantially larger than the base size
scott: that is the tricky part, large text, people understand that since its already large, not growing might seem OK.
<Francis_Storr> I was just going to say this should be presented at AGWG. Contact the chairs to ask about agendas: group-ag-chairs@w3.org
scott: we need to bring this up to WCAG? to get a better idea of where this falls down and what text requirements are.
scott: not growing could be considered a failure, though in large text scenarios, people might be OK with that.
Ian: its always going to be true that it will render at double the base size, but since its boosted, it may not grow.
Ian: we also apply the minimum font size, in the borwser you can specifiy a minimum font size, default is 9 or 10 by default. The default size is 16.
jamesn: I don't think there is any more ARIA can do here, this needs to go to the WCAG wg to see if there is a way of using this that doesn't violate WCAG
jamesn: this happens today with viewports.
scott: I both agree with james and see the need for this. WCAG2 is already here, but WCAG3 is in development, it would be good to bring this there.
CSS/ARIA Issue Triage: [css-display-4] reading-flow/reading-order vs text selection #12014 agendabot]
spectranaut_: is this something that we should talk about more here or have coordination with the CSS working group?
spectranaut_: asking … jamie teh to weigh in.
CSS/ARIA Issue Triage: Add an ::interest-button pseudo element to interest invokers #12437 agendabot]
spectranaut_: The goal of this is to find a solution for touchscreen users and provide and alternative solution for interest invokers
scott: Essentially the interest button psuedo element is being proposed here for when a button is being marked ... so it appears on hover or focus, there is no way for a touch screen user to see.
scott: so this would make a button for touch screen devices, so someone would know they could touch an item and have a popup appear.
scott: we don't need this for mouse/keyboard devices, more important for small touchscreens.
spectranaut_: Maybe we need someone from the css side to come here.
jamesn: Lets do a deep dive rather than in this meeting
giacomo-petri: Last week we discussed aria-busy, if we set busy to an element that is improperly using aria attributes
giacomo-petri: say a div with the role list item, is it fine for nested children to have malformed aria content inside?
giacomo-petri: is it an authoring violation or not from an aria point of view?
scott: we need to do something about the aria-busy problem, will discuss next week.