W3C

- DRAFT -

Cascading Style Sheets (CSS) Working Group Teleconference

15 Sep 2019

Attendees

Present
Aleks_Totic, AmeliaBR, Brian_Kardell, Florian_Rivoal, Fronteers, Google, Igalia_and_Open_JS_Foundation, Invited_Expert, Mozilla, Nigel_Megitt, Rachel_Andrew, Rossen_, Simon_Sapin, birtles, cam, cbiesinger, chris, chrishtr, dbaron, drott, drousso, eae, emilio, futhark, iank_, jihye, krit, leaverou, majidvp, mattwoodrow, mstange, myles, oriol, plinss, prushforth, skk, smfr, stantonm, tantek, xfq_, yigu, zcorpan, xfq, TabAtkins, SimonSapin, heycam, jgraham, Léonie, (tink), ZoeBijl, mck, dauwhe_, bkardell_, IanPouncey, Irfan, achraf, aboxhall_, Roy, Judy, DavidClarke
Regrets
Chair
SV_MEETING_CHAIR
Scribe
nigel, fantasai

Contents


<Rossen_> trackbot, start meeting

<trackbot> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference

<trackbot> Date: 16 September 2019

<Rossen_> Rossen Atanassov, Microsoft

<astearns> Alan Stearns, Adobe

<oriol> Oriol Brufau, Igalia

<plinss> Peter Linss, Invited Expert

<dbaron> L. David Baron, Mozilla

<stantonm> Stanton Marcum, Amazon

<skk> Hiroshi Sakakibara, Beyond Perspective Solutions(BPS)

<birtles> Brian Birtles, Invited Expert

<heycam> Cameron McCormack, Mozilla

<mstange> Markus Stange, Mozilla

<krit> Dirk Schulze, Adobe

<emilio> Emilio Cobos, Mozilla

<eae> Emil A Eklund, Google

<drott> Dominik Röttsches, Google

<futhark> Rune Lillesveen, Google

<koji> Koji Ishii, Google

<myles> Myles C. Maxfield, Apple

<cbiesinger> Christian Biesinger, Google

<fantasai> Elika Etemad, Invited Expert

<nmccully_> Nat McCully, Adobe

<xfq_> Fuqiao Xue, W3C

<mattwoodrow> Matt Woodrow, Mozilla

<cmp> Chase Phillips, Google

<jihye> Jihye Hong. LGE

<drousso> Devin Rousso, Apple

<fantasai> ScribeNick: fantasai

F2F Scheduling

Rossen_: January is already in the books
... Jan 22-24 hosted by Igalia

fantasai: Should we resolve on Rego's suggestion to run 10-7pm?

<AmeliaBR> Amelia Bellamy-Royds, invited expert

florian: Reason was local schedules, restaurants don't open until 8/8:30pm

RESOLUTION: Igalia meeting is 10-7

Rossen_: Dates from Apple?

<prushforth> Peter Rushforth, Natural Resources Canada, Invited Expert, Observer

astearns: Tess said she's trying to reserve April 27-30
... Don't have an update on if she succeeded

Rossen_: Just want to try to sort it out asap, so people who are on tight schedules can finish their scheduling for the spring

skk: Will there be a Houdini meeting?

Rossen_: Not in Spain, in April there will be one

<ekashida> Eugene Kashida, Salesforce, Observer

Rossen_: Possible Summer locations are Kyoto, France, NYC
... Anyone up for sponsoring F2F meeting?

florian: France is a misunderstanding, can't offer to host in France, but can host in Kyoto but not in July+August

Rossen_: NYC would put two consecutive in USA

astearns: Maybe. April might be in Ireland

Rossen_: So looking at July 20-24 or July 27-31, last two weeks of July

dbaron: That is not the ideal time for Japan, not only because it's warm but also Tokyo Olympics are then

hober: I have dates!
... Did we want to have Houdini, also?
... I have three days confirmed, 4th not confirmed yet
... Booked for Monday 27 April - 29, in Cork, Ireland

Rossen_: Sounds great

RESOLUTION: CSSWG meeting Monday 27 April 2020 - Wed 29 April 2020, Houdini afterward (pending booking confirmation)

Rossen_: Back to summer
... Who was offering to host in NYC?

dbaron: Think it was Una (Google)

TabAtkins: We can probably do it

Rossen_: Ok, check about it and let us know

TENTATIVE: End of July 2020 in NYC

CSS Contain

Rossen_: Proposed to publish a PR of CSS Contain 1

florian: Afaict, it's complete
... All tests pass in 2 browsers, except those which depend on other less-mature specs
... So I think we are ready for PR
... One more note, all tests pass if we don't count the at-risk feature

<dbaron> https://drafts.csswg.org/css-contain/issues-2019-cr.html

florian: the style containment is not implemented properly anywhere
... but that's why we marked it at risk

<dbaron> https://drafts.csswg.org/css-contain/implementation-report-2019-09

<dbaron> https://drafts.csswg.org/css-contain/annotated-2019-09-05.html

florian: so my request is to drop it, go to PR, and publish FPWD of Level 2 which just contains that feature

<dbaron> https://github.com/w3c/csswg-drafts/labels/css-contain-1

<dbaron> https://drafts.csswg.org/css-contain-1/

Rossen_: So PR version will have 3.3 dropped for Level 1
... Objections on resolving to publish PR of CSS Contain 1 with dropped section?

dbaron: Is the state of style containment that implementations are shipping support and not passing tests, or not shipping support?

eae: Combination of both

florian: Chrome ships a buggy one, and Gecko doesn't ship iirc

heycam: We don't recognize the value

smfr: Are the two implementations blink and gecko?

florian: Yes

Rossen_: Hearing no objections,

RESOLUTION: PR of css-contain-1, dropping style containment (at-risk)

florian: For Level 2
... if we add new features, need fpwd, but if not adding a new feature can go directly to CR

content-size

<astearns> explainer: https://github.com/WICG/display-locking/blob/master/explainer-content-size.md

chrishtr: Posted a new explainer
... content-size is a new CSS property
... If 'contain: size' is specified, content-size is treated as intrinsic size of contents
... proposing that be able to set intrinsic width/height passed to intrinsic sizing algorithms
... Reason we believe it's useful is that you can use it when a subtree is not yet ready or you don't want it to have its own layout
... can express a placeholder sizing for it
... Allows communicating that placeholder sizing, so that flex/grid/table/etc can take that into account

<astearns> github: https://github.com/w3c/csswg-drafts/issues/4229

chrishtr: If we've skipped rendering as an optimization, dev can use to communicate placeholder sizing

SimonSapin: Would this property apply without 'contain'?

<Rossen_> a?

chrishtr: When you don't have 'contain: size', no
... Only applies when 'contain: size'. Reason is that 'contain: size' causes no competing intrinsic size
... 2nd reason is that it fits neatly with render subtree attribute proposal

florian: Can you expand on the second point? I'm not faimilar with that
... In isolation proposition makes sense, but not sure why it's not coupled with a more generic intrinsic size feature

TabAtkins: One reason was that, as chrishtr said, that means you have competing information. We don't think that's useful to have two sources of truth there
... Seems like only time you need to provide a better intrinsic size is when you're contain sizing already

dbaron: I'm skeptical of that
... I think there are a bunch of cases, where intrinsic sizing doesn't provide good results and devs might wnat to provide it
... Talked about some o those cases in the past
... Some cases devs want to override only in one dimension

TabAtkins: Bad behavior of intrins scorllers maybe?
... flexboxes blowing up

dbaron: Didn't have that in my head, but sure

TabAtkins: That's intriguing

AmeliaBR: Also cases we've had where certain modes cause things to collapse down to zero, and might be better not to
... Lots of cases there might be a demand for it
... Wrt naming, 'content-size' might be interepreted as size of content-box
... If there is a limitation, tho, should be good reasons for it

TabAtkins: Yes, happy to come up with better name
... Cases that fantasai and I identified where boxes get too big in intrinsic sizing, and currently don't have a way to opt into better behavior
... In some cases can inflate itnrinsic size, others might be able to shrink
... good idea

<florian> fantasai: Support florian and dbaron , this should probably be a generic mechanism

<florian> fantasai: the value space would be legacy | auto | <size>

<florian> cbiesinger: what is the diff between legacy and auto

<florian> fantasai: scrollers collapsing to 0 or not

<florian> fantasai: if inside a flex item, there is an overflow:scroll pre element with a very long line, the min-content size is the size of the very long line, that makes the flex item be very large, even though we could just have made it into a scroller

TabAtkins: Semantics are still a bit funky, if you provide a size wouldn't do anything unless you're contain: size

fantasai: Well, I think it would

dbaron: I would also note that there are cases where intrinsic sizing provids sizes that are too small, e.g. in cases with percents

<florian> fantasai: if you specify an explicit size, that takes over and you ignore the content

TabAtkins: Could do that... was wondering if you wanted to max them

AmeliaBR: Doing a max or min doesn't work if we want to accept both use cases of dealing with cases where intrinsic size is too big or too small
... Just say if you specify a value, you wanted to override

chrishtr: All these examples that were alluded to but not explicit, please write into issue

fantasai: Based on discussion, this doesn't go into contain, goes into Sizing level 4

<florian> fantasai: based on this discussion, this goes into sizing-4, not contain-2

Rossen_: Anything else on this topic

TabAtkins: Discussion was good

chrishtr: Point Florian raised about, what are you talking about wrt render subtree
... maybe wait until we talk about that
... but 5min background on render subtree, though it's on the HTML spec
... package, how they fit together matters, so just want to mention

Rossen_: we can put that topic next

chrishtr: Just want to give an overview of what it is, what use csaes are, how it functions
... so can get some feedback

Rossen_: So content-size, or whatever we're going to call it, will go to size level 4
... Any objections to add it?

<chrishtr> Explainer that contains rendersubtree: https://github.com/WICG/display-locking/blob/master/README.md

TabAtkins: maybe call it intrinsic-size

fantasai: Nobody wants to spell that

TabAtkins: true

fantasai: There was a suggestion that this be split into width/height not one property for both dimensions
... Seems to be the proposal is foo-width/height/inline-size/block-size

iank_: legacy as initial value?

PROPOSAL: Add proxy-width/height/inline-size/block-size with values legacy | auto | <length>

RESOLUTION: Add proxy-width/height/inline-size/block-size with values legacy | auto | <length>

Contain level 2

florian: We could go CR directly, but we might want to change things so maybe fpwd is better
... some suggestions, e.g. single-axis contain, etc.
... might want to add

RESOLUTION: FPWD css-contain-2 being copy of css-contain-1 (including at-risk features)

Render subtree

chrishtr: I posted alink to an explainer earlier

<chrishtr> Explainer that contains rendersubtree: https://github.com/WICG/display-locking/blob/master/README.md

<chrishtr> https://github.com/whatwg/html/pull/4862

chrishtr: PR for spec idea
... render-subtree attribute is an attr you can put on any HTML or SVG element
... Has one or more keywords that are space-separated

<bkardell_> ... or mathml?

chrishtr: ex. rendersubtree=invisible
... what that means is that it is invisible, but takes up layout space
... and also is designed so that UA doesn't need to do any render work for that subtree
... no heuristics to figure out whether needs to render that subtree
... you load a web page
... bunch of content not on screne atm
... you like that page to load quickly, not have extra layout cost
... not load external resources
... etc.
... for stuff that's not on screen right now
... common because scrolling is common on web, and large websites
... what does attriute do when set to invisible?
... First, it applies layout, style, and size containment
... layout containment is good, content below can't escape layout of the element at the root of the subree
... size containment for imilar reasons
... dont' need to know layout to compute layout of the page
... so don't need to do layout, don't need to paint it,
... not painted to screen and not hit-testable
... so don't need to do any work as UA to process that DOM subtree
... is present, but doesn't cause any work
... that's the core value-add of the 'rendersubtree=invisible'
... Other value syou can add
... If you say that rendersubrree is invislbe and activatable, what that means is that UA is allowed to mutate that attriute to be empty string
... to render the content
... e.g. wikipedia, stuff below the fold
... wikipedia markes as activatable
... and invisible
... when user or a11y API wants to look at that content
... or user wants to do find-in-page operation
... and UA notices the content is below the fold off-screen content

browser would be able to cause the content to rnder

chrishtr: which has effect of causing it to render
... and script can observe the mutation of the attribute through a mutation observer
... takes some action to help
... or in simplest cases, content is just rendered
... important because lots of UA algorithms not controlled by authro
... e.g. a11y, anchor link navigation, tabbing between focusable elements
... scroll-int-view operation, find-in-page
... finally, two additional keywords
... one prevents external resources from being loaded
... image wouldn't be loaded until whole-loads keyword is removed
... avoids blocking network pipeline for stuff below the fold

<astearns> ack 'dis

chrishtr: useful for feeds of info like fb, twitter, also for page with lots of images off-screen
... This is a lazyloading feature similar to what chromim is trying to ship
... Finally, web component element upgrades
... if you have custom elements defined in your registry,
... if element was registered, runs create callback
... allows dev script to participate in rendering the custom elements
... but if elements are off-screen, then cost isn't desirable
... dev would prefer not to run script until content is on-screen
... way this fits in with content-size is that if you set the render subtree attribute to 'invisible'
... has containment
... therefore content-size would take over sizing of unrendered content
... this way, when content is subsequently rendered via UA action or dev activation
... layout doesn't jump around
... contain: size is only applied when invisible
... when not invisible, then it will no longer have 'contain-size', automatically uses actual size
... intrinsic size without size containment might be compelling enough to drop this connection, but that's what we were thinking
...
... 'display: none' doesn't help for off-screen content because idoesn't take up layout space
... 'visibility: hidden' doesn't stop layout, and also can be overridden by descendants, so have to render through the subtree

Rossen_: 'display: none' + 'contain: size"

chrishtr: display: none box is gone
... rendersubtree=invisible, the box is still there, only its contents are gone
... you could have e.g. a spinner erndered in the elemetn, or a pseudo-element, but don't actually render the subtree

smfr: What's the behavior when element with visible subtree changes to invisible

chrishtr: if you just add `rendersubtree="invisible"` to element
... it'll apply contain: style layout size
... and not render the contents
... but element itself will still read
... script can still read style, could cause layout thrashing

smfr: so toggle from visible to invisible, ...
... does it give you a stale value?

chrishtr: Will do the work to get you the right value
... doesn't cause it to render, but has to do calculations

smfr: seems a bit magic, like a hack
... seems like maybe it should be a CSS value, e.g. new keyword to 'visibility'?

chrishtr: if it was a CSS property, would be weird if UA overrides it
... but made attriute so UA can remove automatically

smfr: Worried about circularity about activatable
... e.g. user hits Cmd+F to start a find
... I thin kyou have to bring in the subtree in order to search it
... because have to check 'display: none'

chrishtr: Don't have to show on scren, but have to compute style

smfr: activatable has side-effect of removing the attriute?

chrishtr: If you try find in page, UA will do the work necessary to compute the disply: none part of pipeline
... if it matches query, would activate the subtree

smfr: Worried there are some things that are not specified that end up affecting the activation behavior
... Spec says activation depens on UA behaviors, different browsers iwll have different activation policies if we don't standardize

chrishtr: explainer lists which actions cause activation
... scrolling doesn't, JS scrollIntoView does, a11y access does

Rossen_: We have built up quite a queue

florian: Maybe I missed something, one part I'm confused about
... what'
... what's the use case for invisible without activation?
... I think author will probably miss some important cases if it's not activatable
... Also, feels like it's something like a delayed or sync value for visibility
... you're allowed to delay, but once on screen please show
... most enefits when combined with contain,
... but conceptually could be separate
... you're allowed to load the assets later
... wouldn't need to override the value, just permission to do it later
... maybe that covers requiremtn for running scripts?
... rest feels like it could be in CSS somehwere along the lines that smfr was talking about
... would like to also know why have a version that's not activatable

chrishtr: Suppose youhave content that is not fully loaded, don't want to show to user. That's why you don't want it to be activatable
... wouldn't be visibility: hidden because not performant, layout subtree still applies

myles: if you wnat to leave space for it, you can set visibility: hidden for it, will leave space
... if you do want the pop, can set display: none

florian: would combine visibility hidden with contain, to reduce jank

TabAtkins: will have jumping because the content hasn't loaded either

florian: but would use 'contain' and 'content-size' as well
... why needs an HTML attribute

TabAtkins: Doesn't allow us to not do layout
... which is a problem if wanting to load 10,000 nodes worht of content

florian: so would want 'visibibity: ...', whic would allow delaying

TabAtkins: recall reason chrishtr just said aobut having invisible but not activatable
... element is in state where it's waiting for stuff to load
... dont' want to allow activation until finished

AmeliaBR: had same question
... but final comment, might want to consider making activatable the default
... authors might *think* they know when to activate, but haven't considered things through very well
... so suggest to make default acticvatable, author has to explicitly request non-activatable

myles: might be problematic to have elements callback in unpredictable order?

<AmeliaBR> e.g. `inert` version for non-activatable

chrishtr: Can use this feature to automatically activate content which is below the fold, or not even actually visible
... e.g. tabbed UI or content hidden behind a ? that can be opened by the user
... e.g. details element
... still want user to be able to find that content and navigate to it
... currently, that's not really possible
... e.g. yu have content in anotehr tab of the ui, or subwidget
... nm, nother reason for activation

heycam: two things: one, want to echo what smfr said
... I feel like behavior when subtree isn't rendered seems like CSS kind of feature
... recognize that overriding the style value of some property doesn't feel great
... but otherwise feels like some new 'display' value, like 'display: placeholder' which only generates frame and not contents
... Some kind fo solution where it's somehow reflected in CSS property dispaly would be nice
... 2nd point was about automatic avtivation behavior
... have you consiered solution where you have strict callbacks for events for these types of activation behaviors?
... so dev can choose to catch events and decide whether to flip activation

chrishtr: So suggesting that script shoudl be able to observe activation

heycam: wonderign if that's a design that you've considered

chrishtr: did consider that design
... and prototyped in chromium
... the event fo this, which we calle dactivate event, was in psec proposal
... but makes sense and is convenient to add
... technically can be implemented with mutation observer, but might be inconvenient

heycam: one advantage of that might be that you could then have a new display proeprty value that does the actual work of that
... and let the author change the value of that property

chrishtr: so tell dev that "i would liek to activate this, please help me out"
... problem is defautl behavior is not good

heycam: author specifying 'display: placeholder', on you to complete the solution

chrishtr: comments about flipping default activation, should make it easy as possible to adopt feature without unintentionally breaking accessibility

TabAtkins: copy-paste two-line activation script on every page that uses this feature
... that's not so great
... If they dont' want it to activate, they can use the don't activate value, and have that work as intended automatically
... back to display values, while I wouldn't fight too hard if we decided to add a display subproperty
... but doing none-typed things in 'display' itself is problematic because lose typing
... this is really bad

chrishtr: want UA to be able to activate for you
... with recent testing with partners etc, does seem to be a use case for controlling things with a style sheet
... sometimes convenient to do via CSS

<fremy> @chrishtr: added some notes over here: https://github.com/WICG/display-locking/issues/78

<TabAtkins> aka you can't set "display:flex" on the element without paying a *lot* of attention to specificity, or else you'll accidentally override the hide-contents value

<florian> fantasai: same concern as AmeliaBR about making the activatable version the default

<florian> fantasai: It would also be good to have the attribute map to some css construct, instead of having the HTML do its own magic

chrishtr: Less magical means harder to cleanly spec, and some use cases are lost

myles: see readme and whatwg pull request, how do I comment?

chrishtr: I think the pull request ahs a correspondign issue in whatwg, good place to ask questions

SimonSapin: similar to 'display: none', but different in that only contents are hidden
... how is this different from 'display: none' on children?

TabAtkins: Text content that are direct children can't be styled
... but also 'display: none' implies a lot of things

Rossen_: animations, do they run on your subtree?

chrishtr: no

Rossen_: so that's also same as display: none

chrishtr: Subtree boxes do have CSS boxes
... conceptually are laid out, just don't need to do work unless forced by script

mattwoodrow: what si additional contstraint that we get over 'contain: all'
... couldn't UA optimize by not rendering anyway?

chrishtr: it's an explicit API
... rather than combo of CSS values

TabAtkins: off-screen 'contain', animations still run
... You will fall down accidentaly perf cliffs

mattwoodrow: so it will block animations?

TabAtkins: among other things, yes

bkardell_: I could be misreading this and not understanding, but sounds like the intent is for the UA to actually change the attribute?

chrishtr: yes

bkardell_: is there a precedent for doing that?

TabAtkins: there's one precedent

bkardell_: think there's been 1000 times that's been suggested, and push to not do that

TabAtkins: one precedent, details
... for similar reason to details, nice thing about directly manipulating attribute than a hidden state
... don't need to expose a new way to report actual value
... and don't need to expose to CSS using custom selector
... just use regular attribute selector
... as long as attribute value is easy enough to work with, and this one will be simple,
... there are usability benefits that come with this for free

cbiesinger: value attribute of input?

TabAtkins: those don't change

Rossen_: OK, thanks for introducing topic, chrishtr !
... ppl wanting to participate, please do so at links provided

<br duration=25min>

<chrishtr> Issue for rendersubtree: https://github.com/whatwg/html/issues/4861

Highlight APIs

Note: break-out session on rendersubtree Wed at 2:30pm??

<AmeliaBR> https://github.com/w3c/csswg-drafts/issues/4307

sanketj: Want to talk about new propoal about highligh API
... builds on top of existing css-pseudo-4 spec
... existing spec allows styling native highlights of the browser: sleection, grammar-error, spelling-error
... can style how you want
... this is useful for editing apps
... implement own selection, spell-check, grammar error
... currently authors use spans
... some problems
... can be complicated, particularly if span across multiple subtrees
... then adding/removing creats perf problems
... wrt invalidation etc.
... users can add/remove highlight using dom ranges
... since can span multiple subtrees, easy to code
... invalidationis only paint invalidation, due to how highlight pseudo elements worok in css-pseudo-4
... will overview first, then ask for feedback, also some issues
... iff ppl support concept, would like to move towards official spec
... two key pieces: one is cssom piece, one is a sleector
... adding two new types: highlightRangeGroup
... provides a group of ranges to be handled ogether
... similar to find-in-page, range per instance of term
... want to style at once
... so style all together
... highlightsMap takes a name key and group as a value
... introducing a global map per document, contaisn all user-defined highlights
... way user adds a highlighRangeGroup is calling .set, user will give a name and use that as key itno teh map

smfr: user meaning author?

sanketj: yes
... two properties on highlightRange which are interesting
... .style property and .?
... connection from highlightsMap to group is important
... to make it stylable
... can only style stuff in the highlightMap
... to style introduces new pseudo, ::highlight(hlight-name)
... same properties supported as other highlight pseudo elements
... can also use .style property
... works just like cascade
... inline style wins
... multiple highlight range covering same content
... example
... Here we have two overlapping ranges, some text contained in both ranges
... each in its own hihlightrangegroup
... one is bg yellow, one is bg orange

HeWenli: what color is the overlap?

sanketj: what is the order?
... we use the timestamp of addign to the map
... if author wants to change that, they can set higher priority
... default priority is zero
... but can change .priority attribute on the rangegroup
... that is core pieces of the proposal
... want to pause and ask for feedback

Rossen_: already have a queue, so let's go through that

TabAtkins: Question about the reasoning for having ragnegroup isntead of multigroup, but you explained with priorities
... wrt that, is priority 0+ or can be negative?

sanketj: can be negative
... want to discuss how priority relates to otehr pseudo elements

TabAtkins: any ties, then fall back to timestamp order?
... one more question, is intention that,if took that example calling foo again, would it ahve a newer timestamp

sanketj: no, timestamp is established when first added to the map

plinss: timestamp order same as iteration order of the map?

sanketj: yes

<TabAtkins> Yeah, so that means even setting "foo" with a *different* highlight group would also not change the timestamp.

florian: first comment, really like this, many of us have been thinking of doing something like this for awhile, actually doing it is great
... there already is a similar notion of ? for built-in highlights

<TabAtkins> (Which totally works for me; phrasing it more explicitly as the map iteration order would make me a little happier.)

florian: not only important to say which one wins, but what does it mean to win, which can be different for different things
... so important not to re-invent a new solution for custom pseudo than for highlights
... and have the resolution be the same mechanism

sanketj: that's one of the issues I wanted to talk about

emilio: few questions, first how does this interact with shadow DOM and general scoping?
... CSS map is global, but rules that apply...
... global ::highlight speudo that spans shadow tree and part of light DOm, what si the style of that?

sanketj: good question
... as currently specced, you have a range in ShadowDOM and some outside, all styled by global map

emilio: do normal css scoping rules apply?
... global parent group, that will apply to non-shadow-dom group, but not shadow dom group
... do you explain how different groups intersecting priority, have to decide
... when you specify some proeprties in some range and not others, do you still apply properites of the other range?

sanketj: you have one group applying bg color and one applying color, overlapping portion gets both of those

emilio: how do you specify that

florian: we have this problem already, and it's specified in css-pseudo-4
... because we have same situation with selection/spelling-error/grammar-err
... whichever we resolve it, must be same for custom ones and normal ones

emilio: a bit annoy8ng but fine I guess

dauwhe: higher-level question, Web has been struggling with identifying arbitrary ranges of text for a long time
... stuff like Web annotations etc.
... does this complement those efforts? is it independent of them? how does it relate?

BoCupp: I would say that they are complementary. This doesn't do anything to identify arbitrary text fragments in a URL to idetnfify a range, etc.
... some places in DOM you can get a range, some cannot
... this is just about applying style over a range

hober: There is a propsal right night for some kind of find-i-page fragment syntax, and would be useful to talk to those people

Rossen_: who has proposal?

<tantek> See Fragmentions for existing work on this too: https://indieweb.org/fragmention

hober: willd rop in minutes

<tantek> deployed on a bunch of sites

atotic: Any restriction on styles you can apply?

sanketj: set of properties youc an apply to highlight pseudo is same as for other highlight pseudos
... fairly limited

<AmeliaBR> Text fragment in URL proposal: https://github.com/WICG/ScrollToTextFragment

cbiesinger: Have you considered making priority part of highlight pseudo syntax rather than in JS?

<florian> fantasai: it's more a question of order. For regular element, we have the DOM order, but for pseudos we don't. For the built-in ones, we specificy that order into the spec

<florian> fantasai: but for custom ones, we need to specificy where they fit

<florian> fantasai: this isn't something you want to redo everytime you select something, so it doesn't belong in the selector

heycam: I like the proposal, wanted to be able to do for awhile

<florian> fantasai: we could have a declarative mechanism in addition to JS, but selectors isn't it

heycam: two questions,
... is there a need to style ranges that match multiple higlihgts at the same time
... rather than just styling all of the individual highlight speduos
... if you have a comma separated name of highlight speudos?

sanketj: trying tunderstand
... if you have multiple ranges, would you need to style them separately if the same content?

heycam: would you need to be able to style, say I want this style when I match both "a" and "b" type of highlight

sanketj: scnearious we're looking at, they are independent
... one implementing spellcheck, one impelmentign selection , etc.
... want both fo those styles to show up

heycam: two styles of text decorations are underlining, maybe you want to style slightly differently if two underlines

BoCupp: so if you have a range that is overlapping two range groups, e.g. this section is currently selected and also a found word
... when combination comes together, you want to pick a different color for that?
... don't have a good scenario for that

heycam: the built-in highlights, theyr'e not exposed in the JS API, would it be beneficial to expose those?
... so you could set .style on them, too

sanketj: maybe

<foolip> Are we set for a WPT/CSSWG meeting tomorrow at 9am?

dbaron: I'm also a big fan of this, we've talked about having a feature like this for awhile
... some questions
... a little concered about ergonomics of the JS api
... one common thing a user will want to do is create a range and add it to the set of something
... say the set is called grammar-error
... my reading of what you have in the JS API is that the way you do that is going to be different depending on whether you've added a grammar error before

sanketj: in scenario you're adding a grammar-error
... if you are creating range for grammar errors
... user types something, new grammar error appears
... grammarly made the group and has to keep track of the name
... they need to keep track of that info

iank_: mentioned someone makeing such a library would ...

dbaron: seems awkward to create all your global errors up front rather than initialize
... reminds me of various set APIs that have e.g. get APIs that have "get this object out of the set, and if it doesn't exist make me one"
... it seems like this API should have that mode
... maybe some other way to structure API
... other thing is that I'm not sure, there's a bunch of new work in pseudos spec
... unsure if implemented

sanketj: wanted to check status of implementation itnerest of pseudo-spec

dbaron: if those are not implemented, I'd prioritize interests of getting this implemented over those
... having generic mechanism work reasonably is more important than having existing spec work

florian: the thing that makes them tricky to implement isn't which one exist, but how do they work?
... we ahve to figure that out for built-in and for custom
... if we implement custom things and drop built-in grammar and spelling-error standard, I don't mind
... but definign how the cascade work etc. is still needed

dbaron: yes, but if that work doesn't extend well to an arbitrary list rather than a specific list, then given that at least it's not implemented, we should fix the cascading/etc to work for arbitrary list of classes

chrishtr: wanted task your current thinking wrt performance of DOM mutations

sanketj: open issue on this
... static range is one of the otpions thinking about
... might be useful
... also going to discuss this topic in editing TF later this week
... any other APIs to make this useful
... if you have static range, do you still need live ranges?
... I'm not sure
... but would like to not just restrict it to ranges

chrishtr: Appreciate taking it seriously, ranges have been a significant perf problem
... each API that changes DOM has to check that range is still correct, it's a problem

skk: We are develoipng viewr for weak eyesight
... using text-to-speech using ? API
... is it possible to synchronize with speech?

sanketj: Currently, the accessibility concerns haven't been addressed
... true for all higlights, I think. Don't think have a way to say spelling error exists here
... so still need to figure out

birtles: priority field feels a bit like z-index
... are there any alternatives like a relative ordering?
... I'm concerned that an extension hlgihglts ranges in the page, going to be a highlight war to get higher priority in teh page

<dbaron> floating point numbers!

sanketj: regardless of option, need to have some kind of recommendation of how priority would interact with application priorities

<TabAtkins> fantasai: I think that setting the prio rleative to the prio of the builtins is easy, you just set it a prio.

<TabAtkins> fantasai: Probably you just set it to 0.

<TabAtkins> fantasai: That doesn't answer brian's question, which is multiple libs competing.

<TabAtkins> fantasai: so how do they coordinate rather than just assigning random numbers?

fantasai: cuz most of them will then try to assign max-int

BoCupp: I don't think you can coordinate things that are inherently uncoordinated themselves, there has to be an integrator
... when frameworks brought together in the web app, maybe grab each one and set its priority to say which is more important
... extensions like grammarly, go app by app, look at how do I integrate with each appSpeechSynthesis
... dont' do it blindly, do it after investigating the app
... today have to figure out how to integrate spans into app without breaking, this would be much less invasive

birtles: quick example of relative ordering
... my app does highlights for a short time, so should be above grammarly's hiighlights
... with priority approach, I might see that grammarly uses 1000, so I use 1001.
... but then grammarly upgrades to 2000
... maybe have an API that give me the highiest available priority, or priority above this particular name

sanketj: currently best could do is iterate map and get the highest priority

<heycam> maybe a priority name like "transient" would work?

johannes: Grammarly tries to integrate with other apps, in cases where it cannot, it usually just breaks the app
... in gmail, can't integrate with it, your email is just gone
... grammarly is trying to do this for awhile, but it's not working unless you have central registry

rune: Thinking about cascding and inheritance
... div::selection, implementations aren't using that style for span::selection in the div
... concerned there will be too much inheritance

BoCupp: A few questions about priority and inheritance
... maybe we should go to the issues?

rune: just a general worry
... maybe we should fix that in implementatiosn before adding lots of new ones?

<Zakim> fantasai, you wanted to reply

sanketj: priority property is currently just distinguishing stacking order for user-defiend highlights
... wnat to discuss how that relates to native highlights and combination of the two
... if we extend to native highlights, two pieces here, what is default priority for user-defiend highlights relative to native highlights
... if user wants to customize that, what is mechanism?
... some scenarious useful
... nwhen author is buildign some editing capability, but using native capabitily for something else
... might impelemtn find-on-page, but use UA's selection
... and want that to show up above their find-on-page
... in other cases might want to show over the UA selection
... solution I propose is that by default, author-defined goes below UA-defined

florian: I agree

BoCupp: Is there a need to interleave with the UA highlights?
... having phase above or below that is probably easiest

<florian> fantasai: the painting rules are already interleaved

<florian> fantasai: background is painted before, text decorations are on top

<florian> fantasai: it's inevitable that things interleave

sanketj: spelling-error and grammar-error, is one group

<florian> fantasai: but if you've got mulitple of them trying to set the same property, the one needs to win

sanketj: selection, find-on-page different
... let's say user wanted to impelemnt their own spell-check and use their own styles
... but wanted to use browsers' grammar-error, is there a way to maintain that stacking order?
... because selection and spelling error are different styles, then would get both

<florian> fantasai: there might be a way to allow the UA defined ones to be manipulated the same way as the custom ones

<florian> fantasai: if you had the native ones in that same map, using standard names, the author could style them, change their priority...

<florian> fantasai: the author could possibly also replace the range objects

<florian> fantasai: so the author could take over built in ones, instead of duplicating

<heycam> +1 I was just thinking the author may want to use the browser's native styling for grammar etc. with their own range, so it may make sense to expose them in the map to allow that

fantasai: also worth noting that we have spelling-error and grammar-error text decoration styles, so you can duplicate that styling if you want to for other types of highlights

florian: need to be careful about priorities
... and thining about them
... it's not quite about in front / behind
... because even if you have lowest priority, your foreground will be over the background of the ghighest priority
... some degree of interleaving is inevitable
... if there is a priority that doesn't allow ?
... not sure bannign it would sovle the impelementation problem
... backgrounds are behind, shadows, then text

BoCupp: ....
... we reasoned, does anyone need that, what are schenarios? would you replace grammar/spelling errors?
... fishing for scenarious taht would reuqire a more capable API

Rossen_: one procedural recommendation, since running low on time
... hearing quite a bit of support and interest from CSSWG
... something that has been needed for quite some time
... I suggest that we transition into figuring out where this work is going to go
... and start transfering text into an actual spec, and star tracking issues in our GH tracker
... if going back to explainer, where would work need to be split out?
... there's some selectors and then some actual speudo explanation

<dbaron> fantasai: I'd say either its own spec or the pseudo elements module.

fantasai: Would suggest ether its own spec, or integrate into css-pseudo

florian: Starting as own thing, amybe merge into pseudo maybe split it

sanketj: also question on name
... earlier proposal was range-decoration?

<astearns> +1 to OM concerns mixed in the feature, instead of in a separate spec

fantasai: css-highlight-api

<tantek> +1 fantasai

Rossen_: Any objections to adopt as ED, with sanketj as editor?

dbaron: adopt as new ED or integrate into css-pseudo-4?
... I'd prefer integrating into css-pseudo-4
... would prefer the closely related things be in the same document

iank_: that said, might be easier to iterate on API if separate

florian: can revisit during FPWD time

Rossen_: so maybe start as separate spec and integrate later?

TabAtkins: an issue into css-pseudo-4 pointing at draft to be integrated later

Rossen_: any co-editor?

florian: propose myself

sanketj: ok!

hober: me too

RESOLUTION: Adopt css-highlight-api as ED with sanketj, florian , and hober as editors; add issue into css-pseudo-4 for where it might be integrated pointing at the ED

<eae> <br type="lunch">

<astearns> starting back up soon

<myles> ScribeNick: myles

Scroll Anchoring

emilio: Is this microphone on?

<astearns> github: https://github.com/w3c/csswg-drafts/issues/4239

emilio: The spec sepcifices a few situations where if a given style chagne happens, you don't apply any scrolling adjustments in thecontainer. This is done to avoid manual sticky effects. This is done to prevent them to breaking.
... even with this heuristic, we have still found either broken pages that for example, once you scroll to the bottom you can't scroll back up, or they do things that in the regular cases you want scroll anchoring to apply, or pages that get burn a bunch of CPU in infinite scroll event listeners because scrolling triggers more scrolling listeners. This is possible in both chrome and firefox.
... What I did to fix it is to never apply any adjustment for scroll anchoring if you are processing a scroll event listener for htat node.
... When you fire the scroll event listener, you remember the target of the event, and if the element matches, you don't re-fire
... this is mainly to prevent bad scroll events. I'm just interested in feedback from implementors

<missed> : Chrome implementors are in agreement

emilio: Steve Kobes is no longer working on this

eae: No one is working on it now

chrishtr: What about it are you itnerested in?

<heycam> s/Ian Skobes/Steve Kobes/

emilio: scroll anchoring restores positions so the offset relative to the scroller is preserved. There are cases where that's undesirable, or break,s if the page is doing stuff like scroll effects. So if you change a static position thing to be below, the anchor node goes up, and then you need another scroll event, and the page realizes that the thing is no longer sticking to the viewport, et.c
... Chrome fixed this by, when changing from in-flow to out-of-flow, don't do the scroll adjustment.

eae: Yes, that's how it works today.

emilio: Even with this heuristic, pages burn CPU by firing infinite scroll events, which is not great. Pages that get locked up on scrolling if you get to the bottom.
... Those cases are not easy to identify generically, because a particular style change happened. The style didn't change, it's a case that scrolling wants to fix. The only thing that's happening is a scroll event listener. Instead of Chrome's heuristics, it would be simpler to not adjust scroll offsets if you're doing scroll anchoring if it's happening during a scroll event listener

eae: We tried that and rejected it, but I don't remember why. Our current behavior is the one that worked the best in the best number of cases.

chrishtr: If something dirties layout that changes scroll offset in a scroll event listener... you want that readback to not take into account anchoring?

emilio: Yes.

eae: That sounds reasonable. If we can't figure out why we can't do that, we should try it agian and see if it's workable

chrishtr: Is the code doing this loop synchronously?

emilio: I know pages in Chrome that burn CPU because the scroll offset keeps changing
... It changes back and forth, and triggers two scroll events

eae: We try to detect that and short-circuit if we go back and forth more than a few times, but it may not always work.

atotic: If you have feedbakc, that would be great, because we're using a heuristic now

chrishtr: If layout is dirtied and syncrhonously read back in teh same handler .... what does reading it back have to do with ....

emilio: While the page is measurin gsomething, so if you insert something, measure it, then remove it, that measurement triggers a scrolloffset update. If you measure again, you'd get the opposite scrolloffset update. That needs to update the scroll offset

chrishtr: Are you proposing that forced layouts don't do this?

emilio: I'm proposing that Scroll offsets don't do anchoring

smfr: Is the time that scroll anchoring is applied defined in terms of HTML5 event loop.

emilio: no. This is an issue. Mostly for this heuristic, if we can remove it, we don't need that, but the main issue is that it's udnefined when this calculation occurs. We are aware of this.
... Scroll anchoring runs after updating styles but before updating layout.
... In order to have hte tree in the state you want it to, you have to run it every layout

smfr: Scrolls triggered by scroll anchoring fire scroll events?

emilio: yes

smfr: that's necessary?
... yes

emilio: yes

chrishtr: What you're proposing is worth investigating. Chrome can invest engineers to page back in our history here.

eae: If you're impelmenting now, we shoudl revesolve this

astearns: Do we need a resolution? Should we change the spec?

emilio: These heuristics are still implemented in Chrome and Firefox. I want to remove them in Firefox.
... I don't see any reason to remove them now.

chrishtr: We need more investigation.

dbaron: You talked about, in a certain case, not doing scroll anchoring. Are there are reasons to record but defer the adjustment until later?
... I haven't thought about it that much. It feels like not doing it sometimes runs the risk of dropping something that you might have wanted

emilio: That may be another approach. And then we can move it to the "update the rendering steps" in HTML5
... The main reason case where you don't want scroll anchroning adjustments is when you're reacting to scroll events yourself

atotic: Part of the problem in Chrome is that, by the time we're in layout, we don't know which handler cuased it. If you can make it work in Firefox, maybe it's possible in Chrome. But we don't have anyone working on it

emilio: Yeah, but you can set a flag....

atotic: We'd have to pass the flag around....

emilio: Yeah, it's possible

smfr: High level comment about spec: The spec is unusual because it describes a behavior which is making up for the fact that web developers often make mistakes and cause scroll jank. With specs like this, we need to be careful. We risk a scenario where some UAs implement this, papering over the bad stuff, and authors may only test in UAs that implemented it. In other UAs whcih haven't implemented in it, there's a lot more scroll jank than the other UAs. This

spec increases the disparity between user agents. We need to be careful not to make too many of these in the future

astearns: There are lots of CSS features which are improving the rendering of a page. If a browser doens't implement that feature, that browser will look worse.

smfr: It's invisible to authors. The browser jsut fixes up content. It's easy for authors to create scroll-jank if they don't test in chrome

iank_: there is precidence. Text autosizing behavior is automatic.

astearns: Can we move on?

Can an anchor node be an inline block

<astearns> github: https://github.com/w3c/csswg-drafts/issues/4247

emilio: A bit of the issues we've found with the spec, the spec uses terms, and the terms don't map to the implementation that wrote teh spec. The spec says "the anchor is either a block box or text" but what blink does is "well any thing that is non an inline or an anonymous block can be an anchor"
... that is not great. I think we've reached agreement with Steve about better terms for the spec. The spec needs some love.
... I'm happy to help out to refine the spec.
... Proposal: Changing the definition of anchor node to be every box but inline boxes and fragmentainers, which are the only things that fragment across <missed>
... This is what Blink does.

astearns: Any concerns?

iank_: There's some discussion on the github issue?

oriol: Instead of explicitly specifing the inlines, can we use atomic inline from the display specification? We can use terms from that spec for future additions to the spec?

emilio: So right now, the definition is accurate. That term from the other spec sounds better.
... Proposal: An anchor node can be every box except a non-atomic inline box

RESOLUTION: An anchor node only can be every box except a non-atomic inline box

RESOLUTION: An anchor node can be any box except non-atomic inline boxes

JLReq met last week

astearns: There's going to be a breakout session on Wednesday to talk about JLReq updates

nat: Japan Language Requirements. We're working on an errata and gap analysis that will add new tests so we can more deliberately affect standards for japanese typography including those on the web. 10-11 Wednesday, called Evolving the JLReq. Will be talking about what we are currently doing and what we will be doing in the future.

TabAtkins: Majid pointed out that Waterloo is available for a summer meeting (instead of New York).

Rossen: Near Toronto

TabAtkins: 1 hour drive

Rossen: Thanks for the offer.

Transforms

smfr: I'd like to build up the understanding of how they should work incrementally. I have some data from real sites that will inform our discussion.

astearns: Projection?

smfr: yes

<emilio> ScribeNick: emilio

<myles> https://github.com/w3c/csswg-drafts/issues/4116

<myles> GitHub: https://github.com/w3c/csswg-drafts/issues/4116

Images with layout information

GitHub: https://github.com/w3c/csswg-drafts/issues/4116

myles: I'd like to present a problem and no suggestions about how to solve it, but I hope to leave with a sense of whether we're interested in solving it
... there are images that need to be positioned similarly to text
... like a math formula with a tall integral sign where most of the formula should be aligned to the baseline but the presence of the integral sign the whole image will sit on the baseline
... so the formula won't align with the text

<fantasai> if we're talking about things like gaiji, which is inline images that should have a baseline and stuff... there was some proposal to add a property to specify a baseline table

<fantasai> we didn't spec it out because it wasn't a high priority

myles: it'd be cool if the math formula could say "my baseline is in the middle of the image", and layout could align it correctly

<fantasai> but it's certainly possible to do

myles: similarly with the apple pay logo and similar, because of the descender of the y
... a similar case is for symbols like the play button in the ios music app, which is not fully horizontally centered, but visually centered
... it's a triangle, so if you mathematically center it horizontally it would look wrong
... so the layout moves it slightly horizontally
... same for gaiji, which are cjk chars which are not in unicode and people use them using images
... since they're images they behave wrong
... three of the examples show the need for horizontal baselines, the other is a vertical baseline

<tantek> There's another fairly common use-case of this, images used for decorative first/initial letters

myles: there are various ways to do this, one option is using it on the image formats and such to provide the information
... another option is to add a css properties
... mac has these system assets that contain this information

<nmccully> unencoded glyphs = gaiji; Chinese poetry typeset for Japanese audiences = kanbun

myles: another option would be to provide a css function that takes a name to these system assets, and returns the information
... so at least we could use it for system assets
... I wanted to get an indication of whether this is a problem worth solving, and if it is what's the solution could look like

TabAtkins: chrome is fine with that, we have taken a look to the image formats to provide x-height and baseline

<smfr> ack

nmccully: a single baseline is fine, but multiple baselines may be needed for multiple writing systems

<Zakim> tantek, you wanted to note use-case of decorative image first/initial letters and also prior art / related feature CSS cursors which reference the hotspot of the cursor image

tantek: I agree this is worth solving. Another use case is a decorative image for the first-letter which has decorations and borders and such
... we have a similar feature / challenge in css-ui with the cursor property
... cursor has a hotspot. May be something that we could reuse somehow

TabAtkins: cursors are usually set once, but in this case you need the same information every time you set the image

tantek: I think cursors can also have the same issue. Having the info in the image would be great, but maybe both

TabAtkins: both is fine

stantonm: we have a similar use case for @font-face / images and cjk, where adding a baseline to the font-face rule would be useful

myles: can you link me to it?

stantonm: we also have a use case to get rid of these images and use the font, so we wanted to use @font-face with the images, and for that the baseline would be great, but for the symbols it may not make sense

<fremy> @myles: if you want more details about the CUR format wrapper which can contain a PNG image and specify a hotspot: https://en.wikipedia.org/wiki/ICO_(file_format)#Icon_resource_structure

stantonm: another thing we wanted to see if we can treat images more like a bitmap, to invert in dark mode

myles: mix-blend-mode?

stantonm: haven't looked into impl that much

heycam: I wanted to express general agreement on the problem being worth solving
... have run into this with svg

<stantonm> creating @font-face from an CJK image (gaiji) - https://github.com/w3c/csswg-drafts/issues/4013

heycam: I think modifying image formats would be useful, though I'm concerned for compat if we run into a situation with image-orientation
... where we start reacting to image metadata and breaking pages

myles: we still need some css integrations to define how these are read or what not

<tantek> FYI CSS UI cursors with optional hotspot x y that can override any built-in hotspot: https://www.w3.org/TR/css-ui-3/#cursor

heycam: using vertical writing mode to getting centering and alignment seems a bit odd

krit: file formats seems nice, but there are formats which we may not be able to modify
... so we may want a css-only solution as well

chrishtr: what formats have this already, any examples?

myles: nope, 0
... the ui image in iOS apps have this, but it's not a file format

chrishtr: so in an iOS app you create an image and set this and use it in your layout?

myles: yes

chrishtr: I'm curious about how feasible is it to modify the formats

myles: people think it's a good idea so I'll try and come back if fail

<fantasai> myles, I think we need to make sure whatever we do can handle multiple baselines

fremy: we may not need to change formats, the cursor format is a small wrapper file with some metadata. May be able to use a similar wrapper-format

<fantasai> e.g. alphabetic vs ideographic vs central vs mathematical

chrishtr: you're proposing a new format?

<nmccully> Adobe's SING glyph format was one way to make an image with font metrics : https://web.archive.org/web/20080627183635/http://www.adobe.com/devnet/opentype/gdk/topic.html

fremy: windows cursors do exist already, and include the hotspot. It already has the hotspot, but we don't want exactly that
... so we may want that instead
... as changing formats is going to be a pain

myles: only interested in jpeg and png really, and those do have optional tags
... but yeah, first thing to try is changing those, second the wrapper format, third css-only solution

<myles> optional tags inside their existing formats

bkardell_: We need to specify what do we do with these values, and people thought that a css solution would also be valuable too
... so it seems like we'd get into a situation where there are multiple sources of truth

myles: image-orientation was like that until not long ago

bkardell_: right, also aspect-ratio and such
... do you think a property of that sort would be valuable?

myles: I think the way I'd approach is the underline-{offset,thickness} where there is an auto value, then from-font (which would look and the image), then <length>

chrishtr: we discussed something similar about mathml not long ago right?

myles: I think the mathml proposal was to identify the baseline out of specific elements inside the formula
... but that doesn't work for non-formula use-cases like the ones I've provided

chrishtr: that makes sense

cbiesinger: could potentially work for svg

myles: yeah, true

chrishtr: drott mentioned that fonts can be the wrapper format
... that may be a lot of overhead

myles: I think making icon fonts is an anti-pattern

drott: there are some ergonomic issues with them
... but my point is that we don't need a new wrapper format, you could wrap an image in a font file

myles: I'd prefer a new format, there's tons of unrelated stuff that you'd need to create a valid font

multicol

Github: https://github.com/w3c/csswg-drafts/issues/4036

rachelandrew: this is an edit made in #3224 (since the last wd)
... dbaron opened this, issue has a bunch of discussion
... I think it was left reverting the resolution in #3224, but then we need to resolve what column-fill: auto and height: auto works
... so we need to decide
... I wanted to sort this so I can publish another wd, and I wouldn't like to publish something that we may revert

iank_: can you describe what happens right now?

rachelandrew: if we're on a continuous context we only look at column-fill: auto in ???, and there were interop issues
... Chrome is doing the new behavior, which is actually the old one that was commented out on the spec
... dbaron has a nice table on that issue
... the second table
... I think if we print from the browser the behavior should be the same

dbaron: yeah, I think we shouldn't get in that situation, because we'd balance the columns separately because we're printing
... I think at least the last fragment in paginated mode should behave the same as the only fragment
... I suggested a fix, but florian didn't agree because it was not what print formatters do
... so I suggested going in the other direction
... I think mstensho was fine with this if we have a clearer definition of what each combination does
... it'd take me a bit

astearns: so reverting would get us to a better place to improve upon right?

dbaron: I think so if WebKit are fine with changing this

iank_: reverting this leaves less more stuff unspecified right?

rachelandrew: yeah, that's right, but we shouldn't publish something that we might revert

iank_: can we mark it at risk or such?

astearns: it's more of a note "we think this is wrong but we haven't figured out the implications of changing it"

iank_: that seems fine for a WD

astearns: but if we know it's flat wrong it may not be useful

iank_: but is it wrong for sure?

dbaron: I think the inconsistency is pretty wrong

iank_: mstensho didn't agree looks like

dbaron: I don't think he disagreed
... to be clear the thing mstensho is complaining about is that `height: auto; column-fill: auto` if we revert this change
... that combination is already not-defined when you're printing
... so there's an existing spec gap that needs to be filled
... but I don't think it's too hard since there is existing behavior (though we may not like it)

florian: I think consistency between printing and formatters is important, so it is consistency between a browser on continuous contexts and printing
... so we should revert to find a solution that doesn't break any of both

astearns: iank_ had objections?

iank_: I think reverting is fine

astearns: proposed resolution is reverting the change and leave issues in the draft to define this

rachelandrew: yeah

iank_: may be useful to link to the reverted change

<dbaron> It looks like what Gecko does for the auto height is just to assume one column.

RESOLUTION: revert the change made in #3224, and add spec issues to define this

RESOLUTION: republish the wd of css-multicol

transforms

<heycam> ScribeNick: heycam

smfr: thinking about 3d transforms
... I want to make sure any changes to the spec don't have unreasonable web compat impacts
... so I wanted to understand how people use 3d transforms on the web, I did a poll
... analysed these sites that are using real 3d
... not as many sites as I expected
... I've noted the structured
... the set of properties on the node that's doing 3d stuff
... properties on the node, the child, the grandchild, etc.
... generally web sites are putting perspective on the root of the 3d stuff
... not preserve-3d on the root, mostly just perspective
... then they put preserve-3d in the child, sometimes with transform
... sometimes they have a noop element. not no transform related styles on it
... sometimes they'll have some intermediate elements, e.g. 3 noop divs, then transform/preserve-3d under that
... sometimes they put just the transform on the leaf nodes. sometimes preserve-3d and transform on the leaf nodes
... something that came out of this is taht there are a few sites that have these noop divs that cause bugs in Gecko
... Gecko treats an element in the ancestor chain that doesn't have transform related prtoperties and something taht triggers flattening
... it's causing problems on a few sites

florian: are there sties that rely on this happening>

smfr: did not see any
... people combime overflow-scroll and 3d for parallax effects
... might have to make some exceptions for overflow-scroll
... this is how people are using 3d transforms.. most important thing is that noop divs should not cause flattening
... next I want to build up the 3d model from scratch
... I'ver realised there are some porblems with the current ED
... we'll end up with a combination of thwat's in the current ED and the preivous WD

[shows transforms-buildup.html]

scribe: let's started with a simple case. this is a 3d transformed element, in isolation
... nothing else that is 3d-ish in this content
... the best behavior for this is that the 3d transform here acts as a painting effect
... it'll be squished by the transformed, but painted in the regular z-order
... no intersection with its container or anything else
... next question is what happens if there are 2 siblings that are transforms
... think the right answer is that they should act as a painting effect, they should not intersect
... I think that's the Gecko model, and maybe Blink, but not WebKit. willing to change WebKit here

chrishtr: nothing has the preserve3d here

smfr: right, we're still in "painting" transforms

astearns: is this something the current ED is sayin something differetn about?

smfr: the current ED is written with the notion that you're always in a 3d rendering context, and doing flattening
... it uses the analgoy of CSS stacking ocntexts and flatening
... I think a better model is that you only establish a 3d rendering context when you use the magic properties
... otherwise you paint in the regular z-order
... now let's change the eexample to put perspective on the container
... originally the notion was persecptve is we're applying another transform for descendants, a common viewport/perspective
... looking at the way content is using perspective, think it makes sense to establish a 3d rendering context
... the 2 siblings would start intersecting with each other

chrishtr: not a behavior any browser has now?

mattwoodrow: WebKit will intersect them (though even without perspective right now)

chrishtr: the perspective proposal is unrelated to current intersecting behavior of WebKIt?

smfr: yes
... when an author says perspective, they're opting in to 3d stuff, and expecting descendants to depth sort

chrishtr: and currently, in Gecko and Chrome, they don't intersect but the perspectie does adjust teh transform

mattwoodrow: right
... did you have examples on your spreadsheet of examples where Gecko/Blink are broken?

smfr: most sites had more complex hierarchies
... nobody had just perspective and transformed chlidren
... so, hard to say
... going back to the example, next set of questions is about the preserve-3d behavior
... I think the right hting for preserve-3d is to establish or extend a 3d rendering context
... so in this case, if you put a preserve3d wrapper around the child -- leaf doesn't have the preserve 3d -- ...

chrishtr: so 2 transformed elements in a single context are sorted with respect to each other

krit: this example would render the same in all browsers now?

smfr: not sure that Gecko will do intersection between the two

krit: the proposal is if you have persecptive set to a value, you'll establish a 3d rendering context?

smfr: yes

chrishtr: support you have an element with perspective. and a child with no transforms. then a grandchild ---

smfr: we'll come to that
... web site data showed that noop divs should not flatten
... some interesting cases then, things like opacity that trigger flattening
... creates a stacking context, and a graphical group, it triggers flattening

mattwoodrow: my biggest concern with the noop thing is it's hard to describe what hte behavior is
... the spec wording for how to decide how to establish a new one or to participate in an "ancestor" ...

smfr: think that should be written in terms of stacking context ancestors
... WebKit's implementation is based on paint order, not containing block order
... I think there are some cases where these properties should trigger a containing block for ease of implementation
... but effectively we certainly work in painting order

mattwoodrow: there are things liek overflow:scroll
... anything that has a clip ...

chrishtr: setting aside overlfow:scroll, do you think this opacity would need to establish a containing block?

smfr: no?
... another interesting case. things that trigger stacking contexts but which arent' grouping effects
... for example z-index
... that doesn't create a graphical group, but stacking contexts are effectively graphical groups, so it should flatten as well
... it's no-op-ish
... so I think in the model it has to flatten
... then there's the other interesting one, what if you have overflow:scroll -- doesn't create a stacking context. people take advantage of this not flattening to create parallax effects
... not really sure how to describe the clipping effects of oveflow

mattwoodrow: think we want different behavior for pereserve-3d and perspective
... for preserve-3d we probably want to flatten. but the persecptive subset we could do relatively easily

chrishtr: can we go through a quick example of doing parallax with this model?

mattwoodrow: currently in Gecko, the clip is applied on the outside of the persecptvie
... the perspective gets multipled into the transformed elements
... but the perspective origin is outside the scrolled element
... the clip is not in the middle of the transform chain

chrishtr: as long as we can preserve parallax scrolling....

mattwoodrow: spec text could say to look up the DOM to find a preserve3d element, but stop walking if you find overflow:scroll

chrishtr: I think you would want this to be a containing block and stacking context as well
... it's neither of those 2 things by default

mattwoodrow: right

smfr: when it has preserve3d around somehow?

chrishtr: walk up the tree, if it's got preserve3d around an overflow:scroll, ...

mattwoodrow: not suggesting overflow:scroll should be a stacking context, but the inner preserve-3d would create a new 3d rendering context

[some discussion about preserve-3d on the overflow:scroll element resulting in the computed style being transform-style:flat]

astearns: sounds like there were some existing sites that expected noop divs ... is there a difference between noop divs and those that have an explicit flattening property?

smfr: noop divs don't flatten

mattwoodrow: I think it's easier to specify if they do flatten

astearns: but not what authors expect?

chrishtr: maybe

smfr: none of these examples totally broke. but you could see the perspective looked different on some elements

chrishtr: definitely think aligning browser behavior is going to break some content
... should minimize that, but come up with a model that we're sure is well defined

smfr: that flattening was the most obvious breakage if we followed the Gecko model straight away
... I think the last piece is the discussion around how perserve-3d behaves ...
... on #1950, Tab lists four different behaviors
... don't fully undersatnd if they're the same except for whether preserve-3d is on the parent or the child

chrishtr: Q1 is, do the children 3d sort before they flatten

<TabAtkins> Q2: do the children sort with the rest of the 3d scene their parent is in, or do they flatten into the parent and then (flat) parent lives in the scene?

chrishtr: and these behaviors are the 2 core ones we control with preserve-3d or perspective
... taht's your whole point? how do they behave dfeault and how do the properties affect this?

TabAtkins: yes
... all 4 combinations seem reasonable, don't know if you want to expose them all
... case 1 is fully 3d, everything is operating in the same graph
... case 2 is you run the children's 3d scene, flatten it, the parent does the 3d scene

<dbaron> One other thought (related to discussions a few minutes back) is that you were talking about walking up the DOM tree, but I'm not sure if you wanted to walk up the DOM tree or the containing block chain.

TabAtkins: #3 is the weird one. each child does an independent 3d thing in the parent's plane, but they could overlap with other things
... 4, double flat is simple

smfr: doing all of these with combinations of properties, with the behavior I described, except if perspective establishes a 3d rendering context, authors would not be able to have the transfom effects of perspectie without also the intersection effect
... but the author could use the perspective transform function on the leaves to get something similar, but not sharing the same origin

chrishtr: I think that first part of the sentence is a good reason why perspective should not imply preserve-3d

smfr: so valid to hav eshared perspective, but siblings not intersecting, which is contrary to my first point
... ok, so we're back to perspective not making a context
... question is how many of these sites would break

chrishtr: then there's the question of resolving the intermediate divs
... how we'd spec and implement the corner cases
... if those intermeidate divs would in some cases be transmitting up the preserve-3d as opposed to flattening

smfr: unless we're willing to go to the Gecko model of always flattening
... still think that's the most web incompatible change

chrishtr: if it was web compatible would it be objectionable to you?

smfr: no

chrishtr: certaimly the easiest to reason about in the spec
... we should do some homework tonight on why these sites are broken in Firefox, see if it's due to this issue or something else

mattwoodrow: I can do that

chrishtr: and whether it's easy to fix them

smfr: if we say that the root must have perspective and preserve-3d to establish a 3d context, I did not capture dat about whether there are multipel transformed siblings

chrishtr: the intersecting thing?

smfr: yeah
... no authors are using preserve-3d on the element with perspetive

chrishtr: you would've observed a rendering difference

smfr: these don't have multiple siblings, so wouldn't necessarily see that

chrishtr: nobody's done any httparchive searches
... would be good to find mor eto sanity check

smfr: the stripe stuff is genuine content, most others are old demos

chrishtr: ancedotally, not sure how common this kind of content is
... I will volunteer to do an httparchive search tonight

florian: I think the lack of interop is indeed causing a lack of sites using it
... I did retire a site that used to use 3d

backface visibility

<astearns> github: https://github.com/w3c/csswg-drafts/issues/918

mattwoodrow: current spec says that backface-visibility only applies to the element it's on, not descendants
... doesn't say it would create any plane or layer, which Gecko faithfully implements
... other engines create a plane for all descendants but not positioned descendants
... which is not something there's any precedent for, seems a bit crazy. would prefer backface-visibility create a stacking context

smfr: I think in WebKit it does create a stacking context, not a containing block

mattwoodrow: maybe it is that it doesn't create a containing block

chrishtr: definitely doesn't create a stacking context

smfr: I'd be scared to change hte behavior of backface-visibility...

mattwoodrow: so try to find a descroption of what it actually does. affects itself and non-positioned descendants?

chrishtr: self painting layers reset the backface visibility thing

mattwoodrow: don't know how to describe it for the spec

chrishtr: similar to the set of things dbaron found that caused "painting as if positioned"
... in CSS 2.1, positioned elts paint later than regular elements

<dbaron> https://dbaron.org/css/test/2018/stacking-context-z-order

chrishtr: anything that has an effect-y thing on it
... this is exactly what is on self painting layers
... so we could define it that way

florian: where else did we run into this?

chrishtr: might have been another case yes
... but the thing about hte paint order is one that's not specified properly, is that right?

mattwoodrow: most of hte psecs that create stacking ocntext say that. but they mean create a stacking ocntext and sort it with positioned descendants

chrishtr: overflow:hidden, backface-visibility, SVG elements and other atomically replaced elements, ...
... CSS clip probably
... and the rest of them do create stacking contexts
... we should define this, get interop on the table in dbaron's test, then use it for the backface-visibility definition

dbaron: I don't think there's a whole lot in there that's not what creating a stacking context
... CSS clip only applies to things that are positioned

chrishtr: but in terms of the "painting as if positioned"
... I think overflow:clip is the most common

dbaron: have we added that yet?

chrishtr: I mean overlfow:hidden and scroll
... on the issue in which this table resides, I mention there's a silly quirk in Chrome and probably WebKit, not triggering self painting in some bizarre corner cases of scrolling

smfr: WK does not create self painting layers for overflow:hidden

dbaron: I don't htink Gecko sorts overflow:hidden on to positioned descendants list

mattwoodrow: don't think so
... overflow:hidden isn't a stacking context, can interleave things inside and outside, so can't go in the positioned descendants list

smfr: so is everything on the list make stacking context?

mattwoodrow: yes

chrishtr: overflow:hidden does not create a self painting layer (in Blink)
... if there's overlfow:scroll but is in effect like overflow:hidden since there's nothing to scroll, then we skip it
... that's something we could change in Chrome
... in any case, is this a good way to spec it?

mattwoodrow: yes, I agree the CSS 2.1 spec describes floats [...]

<dbaron> I think Gecko calls this "pseudo-stacking context"

RESOLUTION: Add a new "pseudo-stacking context" definition and use it to define how backface-visibility works

dbaron: some of this would be easier if there's a spec to put this old CSS 2.1 text to evolve it
... maybe a central painting spec

-- break until 4pm --

<TabAtkins> ScribeNick: TabAtkins

Define path() in Shapes 1 or 2

astearns: A number of specs are using <basic-shape>, which has several functions in Shapes 1, but not path().
... But path() is being implemented for *some* of the <basic-shape> properties.
... It's weird to have them linking to a definition in Shapes 2 that's just a diff.
... One option is to flesh out Shapes 2 into an actual spec, with a proper definition for <basic-shape> including path()
... Another option is to pull path() back into Shapes 1, which implies we should implement it for shape-outside
... I don't much care which one we do.
... But would like to resolve on which way to o.

TabAtkins: My preference is whatever gets all the props using the same set of shape functions; all the props use a different subset right now and it's terrible.
... Spec's easy, I'm fine with it in level 1.

astearns: I think Ian said doing path() in shape-outside woudln't be trivial, but seems plausible to do.

eae: Yes.

astearns: So I propose adding path() to Shapes 1. There's other things that need to be done in the spec, we can get a draft out that everyone can refer to with all the functions.
... Can deal with how that slows down Shapes 1 from PR as we find impls to try it out.
... Objections?

<AmeliaBR> The problem with adding path() to shapes 1 is that, as currently defined, it can't be used everywhere a shape is. It only defines the outline, not the fill area.

heycam: Any objection to shipping path() in things like offset-path - do they need to ship together?

TabAtkins: [reads Amelia's IRC comment]

astearns: Yeah that's a bit of th eproblem, some properties don't need fill-rule at all.
... So I'm imagining it's an optional param to the function. But I haven't thought about how it's specified yet.

heycam: Would that block Motion Path?

astearns: My proposal is just to put it in Shapes 1. It shoudl improve the Process situation for Motion Path; it can then refer to a CR-level spec instead of a FPWD diff spec.

<AmeliaBR> Motion path would just ignore the fill rule. But for the SVG `d` property, allowing fill-rule in the path() function is possibly confusing, since there's a separate fill-rule property that applies.

astearns: This is really all about Process.
... Tab, you mentioned Chris Coyier's annoyance with the shapes being different everywhere.
... There's the path attribute in SVG; it's possible we won't get all the way to SVG syntax in CSS.

[discussion about CSS tokenization not being compatible with SVG]

myles: Does that mean you can't build up paths from varia les?

TabAtkins: Not without defining a new syntax that's CSS compatible.

AmeliaBR: Or doing the string-concat function.

myles: Didn't we resolve to add that?

AmeliaBR: Yeah, but no one's written it yet.
... wrt it being a Process issue; if we want to put path() in Shapes 1, we have to figure out these issues before Shapes 1 can move forward in the process.
... I'm not sure who's responsible for Shapes's progress, I think Alan; at this point is it best ot clean up and stabilize, or are we fine to take on this new work? Becaus eit's also abuot impls.

astearns: I think my strat will be to add it to the spec as an at-risk feature, so that we can punt it if we need to move Shapes 1 forward, but I'm perfectly happy with it sitting at CR for a while, or even going back ot WD if there are enough changes.
... I'm not that concerned with getting it to Rec real quick.

AmeliaBR: Does adding path() mean we have to cycle back to WD, as a significant new feature?

florian: Nah it's fine.
... Patent Policy will handle it fine; as long as you've got wide review and what not is fine.

AmeliaBR: It's been reviewed in Motion Path, but review there...

florian: The easier it is to demonstrate review, the easier time you'll have.

astearns: And if we have to bounce to WD, that's fine.

AmeliaBR: So long term, is our goal that shapes should be shapes, and you should be able to specify motion-path with circle(), etc?

TabAtkins: Yeah, a circle is a path, whatever.

astearns: So any objection to adding path() to Shapes 1?

RESOLUTION: Move path() down to Shapes 1, adding it to <basic-shape>.

krit: I missed - are impls willing to support path() in shape-outside?

astearns: Missing a few people that would answer that.

TabAtkins: Ian says it's non-trivial, but doable.

astearns: So yeah that might slow us down, but getting things consistent and well-explained is more useful than a quick Rec for Shapes.

krit: Would it be good to add a note about precision in paths? A very complex path might get transformed to a polygon, maybe have a lot of points, etc. So can we add a note that impls can decide on how precise it wants to be?

AmeliaBR: I don't know if we currently have text to that effect with polygons...

astearns: We do have text for some degenerate/difficult situations, saying you do have to do the difficult stuff.
... I'm not sure we need to define that; precision's going to be an impl detail. Tests will have to be fairly coarse anyway to avoid being flaky.
... So I think it's just a QoI detail they can live with.

krit: So if we agree it's just QoI, it's probably fine.

AmeliaBR: There's already a lot of flexibility for, say, *drawing* SVG paths.

krit: Ok.

<astearns> github: https://github.com/w3c/csswg-drafts/issues/4270

Sunsetting the fxtf-drafts repo

AmeliaBR: This has already been decided, but there's been no volunteer to do the work.

TabAtkins: I can do it.

plinss: We'll need to add some redirects to the draft server, since the URLs will change. Coordinate with me.

<heycam> ScribeNick: heycam

Should list-item counter reset rule be in a UA stylesheet?

<astearns> github: https://github.com/w3c/csswg-drafts/issues/4244

emilio: the CSS Lists spec says that ol and ul (should also include menu!) should have a counter-reset: list-item in the UA sheet
... we've had 2 regression reports, people overriding counter-reset
... the fix on the author side is trivial, adding list-item to the value
... afaik, the 2 regressions are fixed that way
... but we may want to think about whether we should make this reset magical
... the issue with making it magical, is that there's no way to override it to none

TabAtkins: at the previous meeting, didn't we resolve to do the thing where if you don't mention list-item?

emilio: that's for counter-increment
... should we do the same for counter-reset?
... the reason I didn't want to jump to do that, there's no way to override it to none
... could say you add the counter-reset, unless you explicitly set it to none
... so it's tricky
... not totally convinced we need to change it for compat, but I'd like to know if we do need it

TabAtkins: if we wanted to express the reverse mbehavior, in non magical ways, you'd need something special for counter-reset
... the only way to do that within the syntax of counter-reset would be to add a function
... because there's no comma, must be an ident and possibly a number. if you add a number ident, that's just another counter
... if you wanted to change hte behavior, like with reversed lists, synatx would be to use a function rather than an ident
... could have a dont-reset(...) when you explicitly need to
... then if it's not explicitly mentioned in this way, it gets reset in this way

emilio: not a fan

AmeliaBR: counter-reset: dont-reset(list-item), xxx

emilio: just looking for ideas if we needed to tackle this
... for now this is fine I think
... a more web compatible solution would be to always reset it, but then it's annoying you can't override it

TabAtkins: you can override the use of it
... the browser's doing some extra accounting in the background, but the author just wouldn't use it

fremy: what happens if you don't reset, and you have a reversed list inside another reversed list?

AmeliaBR: it's a nested counter

fremy: if you're not resetting th ecounter, you have to consider the nested child as part of the main list
... does anyone want to implement that?

emilio: I think it would work right now

AmeliaBR: the list items handle if you're incrementing up or down

emilio: we do the counting on the counter nodes, so we count the number of counter nodes that are in the same list
... I think it would work. mixing reversed and non-reversed lists would be fun...

fremy: not sure it's a big problem if we cannot

AmeliaBR: any interested in supporting reversed counters in general? counter-reset and reset it to the max value the counter would have?

TabAtkins: so far no, since that's not what reversed counters actually do in HTML

<TabAtkins> ScribeNick: TabAtkins

word-break:keep-all and overflow

florian: In langs like English, word-break:keep-all is same as normal

<astearns> github: https://github.com/w3c/csswg-drafts/issues/4286

florian: In Japanese, it suppresses a lot of wrapping opportunities. (Not quite all, but most.)
... So if you have a very short measure of text, you might have a small sequence of text without break opportunities.
... Currently ther'es a provisio in the spec that the UA may reproduce the suppressed wrapping oppo to reduce overflow.
... I think this is good, but the "may" isn't. We should harmonize on should or must if we want to do this.
... An example of this is a title or figcaption, a short piece of text.
... People tend to like it not breaking anywhere in Japanese.
... But if the amount of space is small enough that it woudl cause overflow, they'll prefer it to break anyway.

myles: This value is for Korean, right?

florian: It's frequently used for Korean, but it's also useful for other CJK langs.
... Any lang that allows breaking at syllable/char boundaries can use this to opt into a less free-form style.

myles: Right, just if Korean use is most common for this, we should see what Korean native speakers prefer.

koji: I'd prefer this be explicit, so it happens only when authors opt in, like overflow-wrap.
... If you want overflow-wrap to not break at specific points, that might be the feature you want. I don't see much different from keep-all in English case.
... If it's useful for Korean it's probably useful for English.

florian: Difference between like-English and break-all is that in English, there's no real context where breaking anywhere is acceptable. But other langs, that is the default.
... So falling back to that behavior in those langs that opt into keep-all is possibly reasonable, while it's not in English.

myles: What about overflow-wrap:anywhere?

florian: This isn't actually anywhere, tho.

myles: Maybe break-word?

florian: break-word and anywhere are identical except for intrinsic sizes.
... But maybe we could have a fourth value, that says that if keep-all, it still falls back to breaking anywhere if necessary.

myles: Right, my question is just if we need a new value, or if the existing values are enough and we just specify their interactions a little different.

koji: In my mind, the two variants of Korean linebreaking are just variants; keep-all is normal behavior.
... Even in English or German, if you have a tiny space to lay out in, you might still want a break going anywhere.

florian: My proposal is *not* to allow breaks before commas, etc. Those are disallowed in 'normal'. My proposal is that, in these restrained-size situations, revert keep-all to acting like normal.

koji: I understand. but this value is already to suppress this situation from happening in Korean. But I think we want to fix all languages.

florian: We have this in german/english/etc by using hyphenation, with "" for the hyphenation character.

koji: Ok, so say English text has a very long word, and the author uses overflow-wrap:break-all to allow it to break. In that case it can break before a comma, which isn't ideal.
... I don't think we can change that, so we might want to add the fourth value.

myles: That's what break-word was supposed to do way back when Hyatt implemented it...

koji: word-break can be commonly used in an issue tracker, for example. But using it on English text is troublesome. overflow-wrap is more useful, but can do bad breaking.

myles: My overall point is that the linebreaking properties in the Text spec are already so complex and there are so many of them, that it will be hard to justify another one.

koji: Ok, well, I think this is basically the same as modifying keep-all.

florian: One action item is to ask Korean speakers, since they're a frequent user of this value, if it would be generally acceptable or if it would be weird.
... There seems to be a use-case to have it either way, but you're right, there is a big cost to adding new properties in this space.
... So we could defer the always-prevent value if it's going to be rare.
... It's just having the "may" that I think isn't terribly useful.

myles: Right, making a resolution now seems premature.

florian: Sure. That's enough feedback fo rnow.

How to handle leading ideographic space sequences

florian: this has evolved over time; they're a strange kind of space, like figure spaces, ideographic spaces, etc

<astearns> github: https://github.com/w3c/csswg-drafts/issues/4180

florian: These now have the treatment that they'r enot collapsible, that hasn't changed, bu tthey're discarded at the end of the line (assuming white-space:normal)
... Unfortunate consequence: if the line is *only* these spaces, they're not discarded for being at the beginning of the line, but they're also at the end of the line and need to be discarded. That leaves an empty line, which is weird.
... We coul dinsted hang them.
... Diff is you could still see them if you underline or background them.
... But from layout, it would be the same as an empty line.
... This was found by Igalia when implementing the spec as written, and it seemed weird to them.
... I think there's no real author preference between discarding and hanging. So since hanging is simpler for impls, would be preferable.
... I made a PR for this, I know fantasai is okay with this.

stantonm: Is there precedence fo rhaving that many hanging spaces?

florian: Yes, we have some other situations like white-space:pre-wrap.
... There's an open issue for some variant situations, but...

stantonm: The inline border does seem strange.
... An inline with a border would project off the edge of the element.

florian: Like any overflowing content, es.
... Example: "<span>a b </span>". If the spaces can hang, these can stay on one line. If they can't and must overflow, instead you must break before b, then let that second line overflow anyway. So not hanging isn't avoiding overflow at all, just introducing extra linebreaks that shouldn't be necessary.

koji: Hanging would require changes to our whitespace code that we'd like to avoid if possible.

myles: there are like 5000 ways to make text look bad on the web already

stantonm: Is there a way to avoid this?

florian: Yes, text-underline-skip for example.

astearns: So proposed resolution is to accept the PR, which states that the spaces will hang.
... Objections?

RESOLUTION: Trailing "other-separator spaces" will hang, accepting fremy's PR.

is it OK to ship clip-path:path()

<astearns> github: https://github.com/w3c/csswg-drafts/issues/4271

astearns: There was a second gh issue we didn't send the comments to
... An impl was asking if it was okay to ship clip-path:path()
... Because they needed to point to an official draft that had this path() thing specified, and all they had was the diff spec
... So in my mind the intent of moving this to level 1 is to let impls ship it.

heycam: clip-path:path() is already shipping in WK, I believe. Not in Chrome yet. Ready in firefox for a while.
... Just wanted to make sure nothing drastic would happen to the syntax.

krit: CSS Masking is already in CR, so implementing clip-path is fine; this is specifically about the path() function.

astearns: Does anyone think Gecko should *not* ship the syntax?

RESOLUTION: Impls can ship clip-path:path()

github-bot: end topic

heycam: What's the policy on this sort of "blessing"?

<fantasai> we put it into the Snapshot

astearns: In general, CR means definitely fine to ship; before is usually behind a flag. But it's fine for there to be situations where people need to ship before CR, just check with the group that it's in a stable situation.

text-size-adjust

myles: People like to view websites on their phones.

[general astonishment]

myles: But phones ar esmall. So the text is usually too small
... So way back in 2007, iPhone 1 implemented a feature to automatically increase the text size without increasing page size.
... We've been shipping this for a very long time.

<tantek> FYI some old writing on this here: https://wiki.mozilla.org/CSS/text-size-adjust

myles: This is controllable with a CSS property called -webkit-text-size-adjust
... Three values: none, which means "don't mess with my sizes"; auto, the default "mess with them it's fine"; and a %, which means the browser's default method of messing with sizes doesn't work well for a particular element, so they site provides its own % boost for the element.
... So if font-size is 10px, and wtsa is 130%, you'd see a 13px size.
... So a bit later we shipped the iPad, also a small screen.
... This wasn't a problem; we made the iPad view the same content the iPHone viewed; it pretended to be a big iPhone for the web.
... So it also got the text-size-adjust behavior.
... This past year we've changed iPad behavior.
... Now iPads get desktop content.
... So this means that sites which said -wtsa, we don't get that behavior anymore.
... But ipads are still small, so we have to do something.
... After research, turns out the method we need to increase font-sizes is different between ipad and iphone
... In iphone, the goal is to make text readable when you double-tap an element; we'll zoom in so the text fills the width of the screen, so you avoid scrolling.
... In ipad, people don't usually double-tap on elements, so the goal was to make it readable by default.
... So the heuristics are pretty different.
... No problem so far.
... This year we started accepting desktop content. That often has -wtsa property, because desktops don't honor it, so it just kinda sticks around without doing anything.
... But when we flipped the switch, ipads were honoring the property, and everything got messed up.
... AFter investigation, we discovered that most of the sites that were setting wtsa were using 100%, which is the same as turning it off.
... Correlation between sites that did that, and sites that *needed* wtsa to work well on the ipad, unfortunately.
... So what we now have implemented in ToT is...
... none still means none. auto still means magic; different than phone, but still magic.
... But %, we found that if treated %s as auto, it made the web look better than honoring the %s.
... Way more sites were using %s to turn wtsa off, than were using it correctly to specify good sizing. In fact, *zero* sites were using it correctly.
... So it would be good to write that down.
... There is a spec covering this feature, CSS Text Size Adjust.

<drott> https://drafts.csswg.org/css-size-adjust/#adjustment-control

myles: I have a bunch of edits I'd like to make to that spec.
... Mostly of the form that %s will be used as a hint. On iPHones they'll be honored; on iPads they'll be a suggestion (currently ignored, might change later if sites start using it correctly).

<karl> https://github.com/whatwg/compat/issues/18

myles: And I'd also like to generalize the inputs/outputs for the "auto" behavior to make it encompass both the iphone and ipad behavior.
... And I'd like to add a section about how authors should use the property to control this behavior; you can look at computed value to see what the brwoser did to your text, and you can use "none" to reset if it you don't like it.
... So want to know what wg thinks.

astearns: How are you speccing this behavior? UAs may do this, may do that...?

myles: Strat we thought best was to keep things general. Two behavior on two platforms, browsers might have other behaviors, etc.
... As long as the author can know what was done and fix it, should be fine.
... So strategy is to make it very general and have a list of things that may be considered when the browser does auto sizing.

heycam: seems like you want the author to be able to tell what auto adjust the UA has made for an element
... Exposed thru the computed style.

myles: Already how iphone works

heycam: looking at the old spec for the moment; initial value is auto, and it's inherited. so if it computes down to the actual %, wouldn't that be inherited to the children?

myles: In webkit I think we don't follow the inheritance rules to the letter for this property.
... If you stack a bunch of %s, they don't multiply.

dbaron: I heard you saying look at computed value of font-size, not text-size-adjust.

myles: Right!
... So you look at font-size and line-height; i think it's important that the spec explicitly says only those two properties will be modified.
... S'o they know what to consult and fix.

dbaron: I think most of this sounds fantastic.
... A little nervous about generalization.
... Would be nice to have a good description if someone wants to implement this...

myles: So over the past long time we wanted to change how ipad viewed the web
... but text was too small

<emilio> karl: aliases are cheap

myles: the iphone's model isn't really what we want
... want different behavior, and faster (iphone behavior is slow), looks at viewport, style of nearby elements, out-of-flow vs in-flow, etc
... Tried to come up with an algo for the ipad, and we implemented it, and it wasn't good
... Cycled for a while.
... so instead is we got a lot of humans to visit websites, and tap on the things that were too small. custom webkit build that would log this
... Adn then did the same to tap on the thins that weren't too msall
... Then used ML to predict too-small vs ok-size.
... So we have a decision tree, but...
... it's not intentional. It just gives good results on a lot of pages.
... So I think it would be a bad idea to put those results into a spec. Plus it can change later.

dbaron: I think it would b euseful to have it in the spec even if it's not required to be followed.

myles: Maybe as a non-normative impl guide?
... That's fine.

florian: If I'm an author and your algo gets it wrong, that seems unpredictable to me.

myles: We try our best to make the heuristic good, and you can use "none" to fix it.

tantek: You specifically gave examples of authors trying to shut off the bheavior, but accidentally messing the pages up on other devices, and then you having to figure out what they really intended and correcting things for them.
... So that lack of predictability caused authors to misuse the property.

TabAtkins: That's not right. When authors used wtsa on mobile devices, they did it reasonably right. The problem is that wtsa wasn't honored on desktop, but authors were still using (useless, ignored) declarations in their desktop-only code. As soon as ipad starting requesting desktop versions and honoring those declarations, it messed up.

fremy: Ultimately if the heuristic isn't understandable/predictable, Stack Overflow will just recommend swapping 100% to "none".

myles: And that's fine.

emilio: So wk exposes the used font size...
... Your text adust used to be layout time, right?

myles: Yes. But on both iphone and ipad, if you say gCS().fontSize, you'll get the used style.

emilio: Okay, that's not what Firefox does. But maybe we shoudl change it.

myles: Yeah, I think it's important.
... So if the group thinks this is okay, I'll make a PR for these changes. They're pretty substantial, so maybe I could be added as a coeditor?

tantek: I'm okay with that.

<dbaron> +1 to myles as a coeditor

SimonSapin: You said computed value of font-size is affected; does that mean that other lengths using em are affected

myles: Yes

emilio: It didn't used to be the case, right? If you did adjustment at layout time, you can't.

myles: Hm, maybe I"m wrong.

<Zakim> SimonSapin, you wanted to ask if em units are affected

tantek: We neve rpublished a fpwd, we had too many issues and didn't understand how to get it ood enough to publish.
... So maybe that's a good goal.

myles: I think that's a reasonable goal.

fremy: do you apply the sam ehueristic for all ipads?

myles: No, depends on screen size and viewport size and specified style
... This is listed in the proposed changes

fremy: So if there's a new version of the ipad, are these rules something that'll scale, or is it arbitrary? Do you have to do more tap testing?

myles: I don't htink i can answer that.

astearns: So let's get edits into the draft and raise issues as needed.

myles: The algo intentionally doesn't describe an algo currently, but it does describe things the browser can consider, and that it only affects two proeprties

plinss: Do you turn these heuristics off when MQs are involved?

myles: no
... But <meta viewport> does interact with this
... So if you have a webpage that is mobile-ready, that'll affect this algo
... So the algo is only strong on webpages that are getting shrunk; if they fit well it has minimal effects

plinss: Overall concern is just that we should be encouraging authors to just make pages in general and use MQs .

myles: The overall purpose of tsa is to make things look good on small devices, so it's driving us toward that goal.
... Philosophy maybe isn't productive, but generally: a solution in the UA works on every page, and doesn't rely on the author getting it right.

<Zakim> tantek, you wanted to express concerns with changing algorithms based on hardware releases

myles: Users don't say "gee I wish this page used MQs" they say "I can't read NYT, this sucks"

tantek: So a few time syou mention hw releases meaning new algos.
... I'm uncomfortable with algo changing with hw releases. That's not a standard.
... I'd prefer something tha tusrvives hw releases.

myles: First, if we release a new device, we're gonna have to tweak it. The web'll look bad, we have to make it look good.
... Second, restricting this to exactly two props, and telling authors how to change it, goes as far as we can to that goal.
... So the most future-proof we can do is to say that tsa can only affect font-size and line-length; no matter how the browser changes things, the author can alway slook at those properties, and disable tsa if they want.

TabAtkins: and note that myles wasn't originally intending to publish the algo at all, that was a dbaron request

tantek: I'm concerned that this'll be continuous reverse engineering.

myles: Yeah, when android ships another phone, they'll have to do the same sort of engineering.

hober: This is just acknolwedging reality

dbaron: And realizing that the web's behavior will juts change over time. Maybe that means the spec will need to change over time too.
... In a world where devs test on these N devices and not every possible-in-theory form factor, there will be things that break when a new device comes out. That'll always be the case, and the impl might need to do new things.
... so I'd rather have a spec that evolves over time to reflect that

myles: So the alternatives.
... One is a spec that changes all the time and is only good on one device, not great.
... Another is don't spec it at all, and have i tjust be magic.
... I think I've described a good middle ground.

dbaron: Commenting back on the plinss/myles convo
... I think using MQ as a signal is a bad idea.
... It's a passive mechanism. One random stylesheet might use MQs, and if that changes the behavior, it can be a disincentive.
... So for this sort of thing, I think meta-viewport is a better signal.

<fantasai> I would prefer to not put more and more rendering instructions into HTML?

tantek: I think I need to see the PR to make more comments, so I'd like to make you a coeditor, make the edits, and have continuing discussion

myles: Yeah, not asking for you to pre-approve things you havne't seen.

RESOLUTION: Add Myles as co-editor to CSS Size Adjust.

<karl> \o/ yeah!

astearns: And I think we have a general agreement ot specify text-size-adjust. Objedtions?

RESOLUTION: Specify text-size-adjust more fully.

<foolip> こんにちはCSSWG! If you're wondering whether to come up the joint session with WPT tomorrow, here's a preview of our short intro: https://docs.google.com/presentation/d/1F1II3lx0krPBIqAzgU9YFIENC-UBEnZtN796hye_bWw/edit?usp=sharing

<foolip> fantasai florian TabAtkins ^

<foolip> Great, see you in the morning :)

<SimonSapin> foolip: in what room is that?

<astearns> SimonSapin: we'll be in the CSS room (Navis-C)

<astearns> trackbot, start meeting

<trackbot> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference

<trackbot> Date: 16 September 2019

testing

<astearns> presenting https://docs.google.com/presentation/d/1F1II3lx0krPBIqAzgU9YFIENC-UBEnZtN796hye_bWw/edit?usp=sharing

<birtles> scribenick: birtles

<astearns> +1 to wpt documentation improvements. It's much much better!

fantasai: thank you for updating the docs
... it's great to have everything up front
... it would be nice to have a navigation system like a tab bar or footer
... to connect them all
... it would be easier to get from wpt.fyi to the docs and back
... second comment: do we have any plans for testing printing? and paginated modes?

jgraham: we have talked about it a bit

fantasai: do we have any way of helping people find and run and report results for manual tests
... there are some things that are not automated and are unlikely to be automated in the near future

foolip: I know Florian does a lot of manual tests
... the answer is no
... there is a manual runner on w3test.org but it doesn't work so well
... and it doesn't report results in the right format
... there are not so many building blocks missing

fantasai: that helps close the gaps for the types of the tests for which we don't have infrastructure
... e.g. printing and media queries
... I don't know how we'll test media queries
... someone should run those
... e.g. plugging in a monitor
... if we only run it once, the data will be old
... we need to be able to run it more frequently

foolip: would it be acceptable if you have to use wpt to run the test?
... locally wpt run
... ./wpt run --manual would be less work than a website approach

fantasai: it would be nice if you can load the test on a website
... but the important thing would be to find the manual tests and then compile a result
... if you can accept data from Peter's system into wpt reporting system
... that might be a way

foolip: just converting them would be straightforward I guess
... but do you want to keep maintaining that?

plinss: I would be happy for it to be replaced
... once its functions are covered
... it tracks what git revision of each test is used

jgraham: perhaps we can follow up later

fantasai: minimum requirement is to get a list of manual tests then provide a report of results

foolip: would it be fine to get all the manual tests in a specific directory?

fantasai: yes

florian: if the system is designed so that you have to run all of them, that wouldn't be so convenient
... there are thousands of tests in writing-modes for example

foolip: if there's no subdirectories then we can maybe use chunking

jgraham: the requirements to run this probably need to be considered in more depth
... there are data model considerations with regards to wpt.fyi
... there are lots of technical details

florian: I think it helps breaking the problem down because eventually we want to replace and retire Peter's system
... even working out how to display manual tests is an interesting problem
... there might be conflicting reports
... using an existing data source and then working out how to display them later

astearns: we do need to work out how to fix this
... I want to second the joy at the improved documentation
... I went through the docs to submit a reftest recently and everything was there
... when I submitted a PR, however, something broken and I didn't know what to do
... I could see the test results, I submitted another patch and it passed
... but I don't know how to fix it the first time
... the first two checks were red and I didn't know what to do about it
... I didn't want to bother anyone

foolip: please bother us
... we need to fix this

jgraham: some of this have failed for reasons out of our control
... e.g. GitHub actions being beta
... sometimes it takes quite a bit of experience to work out what went wrong
... there are infrastructure problems but there are also things we can do better

dbaron: is pinging you on #testing the way to reach you?

jgraham: yes

foolip: or on the PR

jgraham: IRC is generally more likely to get attention
... can get lots on GitHub email

zcorpan: it depends a bit on what it is
... if it's something you see repeatedly
... it might be a system bug we need to fix
... otherwise ping one of us on the PR / IRC

florian: in addition to the manual testing, we need 2 more things to retire Peter's tool
... one is MUST tests vs SHOULD/MAY
... important for exiting CR
... the other is that wpt.fyi groups report by directory
... but using the metadata pulling results by spec not directory would be helpful
... then we can retire Peter's tool

jgraham: we are working on associating labels with tests
... I think that would cover these cases
... if you want that information to be in the test files rather than in metadata
... then you could have a bot to check they are in sync

florian: currently that data is in the data, the flags meta
... so we need to sync that with labels

jgraham: that labelling system is quite limited but it is being worked on
... we could have a script to check they are synced

foolip: if you can search for not labeled tests is that fine?

florian: if there is a button to click that's better, but as long as it's do-able
... one more question about fuzzy tests
... for non-fuzzy reftests we often have problems where one side is don't with Ahem and one is not
... but the box is quite large...
... is that covered by fuzzy

jgraham: there are two parameters in fuzzy reftests -- one is the total number of pixels you allow to difffer
... one is the amount of you allow in difference per color channel
... so in this case you would allow a very small range in difference per color channel
... if you specify one number it means exactly this number must be difference, but you can specify a range, e.g. from 0
... the other thing is that in Gecko we can have meta files that layer over the wpt tests so we can apply different fuzzy parameter for Gecko only
... e.g. we know our form controls differ

florian: for the color channel parameter, it sounds like what I want to do
... but getting the right numbers might be difficult
... if we can find a way to make that easier that would be good

jgraham: the screenshot tool could do that

dbaron: the gecko reftest failure tells you that -- the failure range
... makes it easy to know what numbers to use

AmeliaBR: for SVG I have been planning to work around this for SVG reftests
... by adding a stroke overline to cover the anti-aliased part
... not the ideal solution
... but you can block off the regions where you don't care about differences

emilio: thank you for all your work
... the tests that keep going to Gecko's internal test suite are crashtests
... is there any way we can convert them to wpt in the future

jgraham: I think for crashtests the thinking is that it's normally a very browser-specific thing
... there might be cases where that's not true
... if we think it's worth doing it's quite do-able

emilio: I can try to see how many of the Gecko crashtests affect other browsers

smfr: thanks for all your hard work
... getting Safari's stuff working right is great
... I want to confirm that if a run fails in the middle there's a clear differentiation between failed tests and not run

foolip: if it fails in the middle we don't get results...

smfr: I'm interested in cases where a test doesn't not run... it should show up as a fail

foolip: a missing test is better than a fail

smfr: just following up on AmeliaBR's point
... sometimes there are differences we do care about in a test with fuzzy parts
... a number is not sufficient, sometimes you want to obscure the irrelevant part

jgraham: the fuzzy thing is a useful thing, it works in Gecko
... and when running it locally it will spit out the numbers you need to annotate them

dbaron: the fuzzy number notation is very useful when they are exact numbers
... since if you get any other kind of number you get an unexpected pass

<Zakim> majidvp, you wanted to discuss scrolling test automation

majidvp: thank you for adding testdriver annotation
... for writing scrolling tests, we often need to inject input
... you support pointer actions, what about mouse

foolip: if pointer actions supports it we can do it

jgraham: if it's not in webdriver we can add a feature request for that

Timed Text

nigel: Hi, I'm Nigel
... part of this group and the timed text group
... there are other members of the timed text group here

<florian> https://github.com/w3c/ttwg/issues/52

<nigel> Joint TTWG/CSS issues

nigel: I want to go through the issues in the order they're listed

Supporting "not within an EM" at text-combine-upright and tts:textCombine for 縦中横 'tate-chu-yoko'

<nigel> https://github.com/w3c/tt-module-cjk-ext-1/issues/1

nigel: This is about text-combine-upright, tatechuuyoko / 縦中横
... the request was to say not to put it in 1em
... to take up more than 1em

nmccully: the normal way of spacing these characters is that the first two kanji should be flush
... in the example on the screen, when the characters can't be included in the line height, they might be allow to intrude into the sides of the line without making the line any taller
... then the line won't be any further away than it is
... the other way is to scale the glyphs

koji: this feature is being considered in writing modes level 3

<fantasai> testcase: http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cp%20style%3D%22writing-mode%3A%20vertical-rl%22%3E%E4%B8%AD%3Cspan%20style%3D%22text-combine-upright%3A%20all%22%3E2222%3C%2Fspan%3E%E6%96%87%3C%2Fp%3E

koji: but we didn't include it because it makes it more complicated particularly when ruby is included
... it complicates the spec and it's not clear how it should work
... and the author can work around using inline blocks
... the layout is slightly different from the optimized text-combine-upright but it's almost the same using an alternate flow

nmccully: this is a common thing though so to reject it for the case of decoration being difficult
... makes it difficult for the 80~90% case
... by requiring authors to do a workaround
... it seems like a lot to ask for the non-decorated case

myles: ruby has this concept over overhang too

<dbaron> I'd note 民國108年 is a good real example (and common in Taiwan) for the 3-digit case.

myles: and that's not controllable by css
... is this a similar thing that the browser should just do?

fantasai: it's not a new CSS property, it's just a different way of doing text-combine

florian: is this an author choice? Or the browser does the right thing thing?

fantasai: an author choice

AmeliaBR: the current spec gives a limit for how many characters to compress, but then beyond that it goes to vertical, not horizontal overflow

glenn: the question was "how does the author express a preference"?

koji: they can use a line block to do this

nmccully: can you still get the same width of the line block doing that?
... or will there be some small space that messes up the layout?

stantonm: there are two ways you could do it.. you could compress the font size

myles: my question is this additive or a bug we're fixing?

nmccully: the scaling is a less desired behavior from a typographer's point of view
... we've also tried to work out what the default should be

<fantasai> testcase:

<fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cbody%20style%3D%22height%3A%2010em%22%3E%0A%3Cp%20style%3D%22writing-mode%3A%20vertical-rl%22%3E%E4%B8%AD%3Cspan%20style%3D%22text-combine-upright%3A%20all%22%3E2222%3C%2Fspan%3E%E6%96%87%E4%B8%AD%3Cspan%20style%3D%22display%3A%20inline-block%3B%20writing-mode%3A%20horizontal-tb%22%3E333%3C%2Fspan%3E%E6%96%87%3C%2Fp%3E

nmccully: most of the time you see this in dates
... and dates often use scaled glyphs
... with variables going forward we hope font designers can be more involved with scaling glyphs so they scale well and don't disturb the line height

<fantasai> updated testcase:

<fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cp%20style%3D%22writing-mode%3A%20vertical-rl%3B%20height%3A%2010em%22%3E%E4%B8%AD%3Cspan%20style%3D%22text-combine-upright%3A%20all%22%3E2222%3C%2Fspan%3E%E6%96%87%E4%B8%AD%3Cspan%20style%3D%22display%3A%20inline-block%3B%20line-height%3A%201%3B%20writing-mode%3A%20horizontal-tb%22%3E333%3C%2Fspan%3E%E6%96%87%3C%2Fp%3E

nmccully: for the Web the preference you currently have--biasing to make everything fit--it fine
... overhang is more of a print thing

AmeliaBR: this suggested layout is going to affect your line-spacing?

fantasai: because it's an inline block it doesn't include the extra line-spacing so it might fit within the line height

nmccully: so this shows it is possible in the browser

florian: this example doesn't show where ruby goes

pal: not scaling is very common practice
... in 100% of Japanese subtitles it doesn't scale

fantasai: one of the bad things about this is text-emphasis doesn't work how you would want with the inline-block approach

koji: this is not too rare in publishing
... compression doesn't give good glyph shapes
... some authors prefer not to compress
... in a single page, authors don't compress

<dbaron> I wonder if that underline behavior is just the result of text-decoration-skip-inc

<dbaron> -ink

koji: but when the text has ruby or decorations, that do compress

<heycam> with text-emphasis and text-decoration: http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cp%20style%3D%22writing-mode%3A%20vertical-rl%3B%20height%3A%2010em%22%3E%E4%B8%AD%3Cspan%20style%3D%22text-combine-upright%3A%20all%22%3E2222%3C%2Fspan%3E%E6%96%87%E4%B8%AD%3Cspan%20style%3D%22display%3A%20inline-block%3B%20line-height%3A%201%3B%20writing-mode%3A%20horizontal-tb%22%3E333%3C%2Fspan%3E%E6%96%87%3C%2Fp%3E

koji: if they don't have decorations, they use inline-block, otherwise they use text-combine

pal: I'd like an action item / next steps

AmeliaBR: file an issue on the CSS repo

fantasai: against writing modes level 4

nigel: also an action to go back to reporter and suggest the best practice we discussed

pal: text combine covers 0% of use cases within the domain of subtitling

florian: an inline block it's a reasonable thing to use when you don't need emphasis, but if we put something in the spec, we need it to work in all cases

AmeliaBR: if you can get pictures of actual typography that does those things, that would be wonderful

pal: so ruby, emphasis on both sides

florian: maybe background colors

iank_: does it contribute to the scrollable overflow?

myles: I think CSS should have facilities for this

nigel: moving on to issue 2983

<AmeliaBR> Agree that the basic feature request, for a new text-combine-upright value for a common typographic pattern, is strong

<fantasai> github:

<fantasai> github: https://github.com/w3c/csswg-drafts/issues/2983

nigel: this is about CJK and supporting shearing

<nigel> github: https://github.com/w3c/csswg-drafts/issues/2983

<fantasai> github: none

Shearing Vertical Text

<fantasai> github: https://github.com/w3c/csswg-drafts/issues/2983

pal: today there's the ability to specify slant on individual characters using oblique
... or italic
... sometimes it's useful to apply shear not on character-by-character but entire line
... that's desirable to apply alignment between ruby and base text
... it's subtle but really matters to folks that care
... separate issue about whether or not we should be able to specify the angle of shear per-character
... issue here is applying by the whole line

nmccully: in print, it's not keeping the height/width of the line when you shear it
... you change the shape of the box of each character to a diamond
... it's call shatai in Japanese

<myles> https://helpx.adobe.com/ch_fr/indesign/using/formatting-cjk-characters.html

<myles> this is what Nat is talking about

nmccully: in subtitles has it become just a shear?

pal: it seems to be just a one-dimensional thing in subtitles
... not sure if it's an artistic desire or technical limitation

koji: the difference here is a position of the ruby, right?

pal: yes

koji: I'm not sure about this use case, but for me changing the position of the ruby looks to me
... shearing the individual characters looks better to me

pal: on the thread some others seem to prefer shearing the whole line

fantasai: for print we know they want the per-character approach
... so I suggest we propose that and take that to the subtitle group and see if that is acceptable
... it's possible that the request here for shearing the whole inline-block is just coming from technical limitations

pal: I like the idea of going back and asking questions
... but the issue opened against ttml was specifically about not being able to shear the whole block

fantasai: I thought the problem was that italics shears in the wrong direction

koji: can you point to specific individual / issue so I can follow up
... I can't see any ruby in that issue

<Rossen__> https://w3c.github.io/ttml2/index.html#style-attribute-shear

<AmeliaBR> text-combine-upright does look bad with individual character shear: https://github.com/w3c/ttml2/issues/784#issuecomment-390856934

<fantasai> https://github.com/w3c/ttml2/issues/784

florian: you said we want to shear the entire line OR paragraph
... these are two things
... for the second option, CSS transforms will do it

pal: ttml can do all three: character, line, paragraph

florian: the difference with ruby is more subtle
... but the text combine upright case is more obviously different

pal: the issue in 2983 shows a good example
... 2983 ends with a question I asked

myles: any proposal for how the author would describe to the browser the effect they desire

pal: yes there is a proposal there

myles: so a new property?
... has anyone considered re-purposing the new syntax for font-style to describe the shearing?

glenn: no I have not
... we introduced three new properties: shear (block), line-shear (per-line including tatechuuyoko), font-shear (glyph box by glyph box)

myles: one option would be to have font-style: oblique -14deg does shear
... and if it looks bad it's a browser bug

fantasai: I don't think it will look good if there is latin text involved

myles: there's an issue in the agenda for that later today

fantasai: I don't think we can mix this with the oblique/italic feature

nmccully: It's complicated to have these different properties, but I agree with fantasai's desire to have a separate feature for this
... to say I want to shear these things correctly, and provide an angle, and let the UA decide how to do it (especially for mixed text)

koji: I agree with myles and don't understand why specifying an angle doesn't work

nigel: you're asking a lot of the implementation and reducing authoring flexibility

koji: what exactly doesn't work?

myles: my proposal is that the font-style property does more than just font selection
... it does font selection as it does today and also does the transform as necessary

pal: the way this was explained to me is that the desired effect was literally just shearing

koji: we understand, but the point is there are other glyph shearing use cases
... that is what myles is proposing

pal: we need to understand three distinct use cases: per block, per line, per character

koji: we have per block already, myles is proposing per-character
... we are wondering what is needed for line shearing

fantasai: this example on the screen shows why we can't cover the line case with the same per-glyph approach
... the characters all shear in different directions when using font-style: oblique

(example includes mixed CJK and vertical and horizontal latin)

myles: yes, we want to discuss this later today

<AmeliaBR> +1 for keeping this logically separate; too confusing when mixing latin and upright scripts

nigel: I think we've understood the use case better, any proposal action?

fantasai: CSS definitely needs to solve the per-character shearing
... block shearing is solved
... open question about if more is needed for line-shearing

pal: for block shearing, transform shears the background too. Is that ok?

AmeliaBR: you need a wrapper element if you want to avoid that

pal: does the size change too for the block too?
... it doesn't so it extends beyond the background
... any chance of a shear property that affects block size?

myles: transforms that affect layout?

pal: yes

AmeliaBR: it could be a dedicated block shear property

florian: the general solution for transforms that affect layout is hard
... a limited use case could be ok

pal: just reacting to the idea that block shearing is solved

Aligning an aligned block of text within its container

https://github.com/w3c/csswg-drafts/issues/1975

<fantasai> github: https://github.com/w3c/csswg-drafts/issues/1975

nigel: action was with us to check that the draft spec text was ok

<AmeliaBR> draft spec: https://drafts.csswg.org/css-text-4/#text-group-align-property

pal: I haven't had a chance to look. What's the right way to test it?

nigel: there's draft spec, but no tests
... what is the best thing is to do to create those tests
... we don't have any perspective on implementation

florian: it's not implemented

fantasai: to get it implemented, write tests, convince browsers to implement it, hire Igalia, implement it yourself

florian: as far as the WG is concerned, if the spec is done, there's not much more we can do

AmeliaBR: it would be great to have pictures in the spec
... if you are keen on the feature, adding pictures and use cases would help

pal: so create a new PR with examples?

all: yes

Images with layout information

github: https://github.com/w3c/csswg-drafts/issues/4116

myles: when we discussed this, we talked about annotating images with baseline information
... is there an image format for subtitles?

nigel: same image format as elsewhere

create a display property value for visually hiding an element while making it available for AT

github: https://github.com/w3c/csswg-drafts/issues/560

nigel: this comes up a lot in subtitles and captions
... the desire to be able to make text available to the screenreader while not visually displaying it
... this is particularly important for subtitles because there is a video behind it which might be showing text, for example
... so we don't need a subtitle necessarily but we want to expose it to a screenreader
... there are hacks to do this
... perhaps a display property value

fantasai: this exists in the speech module level 1
... property is speak
... initial is 'auto' which defers to display
... but not implemented it
... 'never' and 'always'

AmeliaBR: display: none has so many other affects other than just hiding

fantasai: we have a spec but no one is interested in implementing it

nigel: the request is not to speak it
... it is to make it visible to the screenreader
... it might be presenting it in some other way

AmeliaBR: braille display etc.

Rossen__: you can use visibility: hidden
... and refer to it via aria-description etc.

AmeliaBR: as the label of a different element

nigel: if you're just labeling an element then the screenreader might just read that once
... but this is an element whose contents is live
... it needs to read it when it changes

AmeliaBR: there are many demands this feature beyond the captioning use case
... I'm sure the accessibility people who come in after the break would be happy to talk about it

nigel: perhaps we can cover it in that session

github: end topic

github-bot: end topic

<fantasai> ScribeNick: fantasai

Accessibility-CSS Joint Meeting

Janina: FYI but need support from CSS
... We have a lto of user requirements about using better for user style sheet things
... Controlling animations was a need, can do , wasn't aware but that's great
... But need to be able to control spacing between words and between punctuation
... Can be done on user side, I believe?
... Seems youhave to be an expert user, invoke the htings
... Make that more usable, would appreciate CSSWG support on that
... WCAG guidelines are quite regulatory
... help to get technological solutions sorted
... and built into browsers

<AmeliaBR> (Better browser support for user style overrides would be wonderful, but yes, probably outside of our realm to specify.)

Janina: Cognitive and learnign disabilitys and low-vision requirements
... Would it be reasonable to control flashing?

florian: There was a long list of things you might want to control in your requirements
... not sure we have solution for every single one, but many are things that authors can control
... and we do have notion of user style sheets
... this is a notion, doesn't have to be a style sheet written in CSS by programmers
... perfectly OK for User Agent to have a UI that sets these rules
... cascade then says how the user prefs and author prefs interact
... but usability of making settings is a UA issue

jcraig: For motion, have prefers-reduced-motion implemented across browses now
... media features and web pages can adapt to them
... that seems to be solved wrt CSSWG, but usabitiliy can improve

Janina: Audio, killing all sounds. Part of browser config

jcraig: want sounds on device but not pages?

janina: bubbling up out of COGA (cognitive)

florian: we don't generate sounds in CSS generally, so don't have a way to turn off

myles: desktop browsers have ability to shut off sounds per tab

janina: spacing: interlinear, inter-word, punctuation

jcraig: letter-spacing available since CSS2.1
... not easy for users to define, but outside scope of CSSWG to solve

florian: spacing after punctuation specifically is not something we can control on author and user side

janina: request to have more space around punctuation

<tantek> sounds like a feature request

fantasai: We do have word-spacing property, but nothing for spacing around punctuation

janina: can add?

fantasai: depends, do you want different spacing at end of sentence vs after abbreviation? We don't know where the end of the sentence is

florian: spacing requirements are also quite dependent on language
... various conventions, requirements per language/writing-system
... so hard to make that work globally

<heycam> fantasai: that's typographic mainly

<heycam> ... a lot of the learning dsiabilityies require -- I would require more spacing after phrases, or sentences, things that need linguistic analysis

<heycam> ... it's a bit difficult to solve on the CSS side

<jcraig> Myles mentioned text-spacing: punctuation

<heycam> ... but could be solved with CSS and a browwser extension maybe

dauwhe_: there's a weird property by Prince called text-replace, we can replace certain characters with e.g. space-punctuation sequence

Rossen__: We have one issue remaining from TTML

astearns: will cover after

janina: next issue, we agreed to do an Accessibility API Mappings with CSS

<dauwhe_> prince-text-replace: https://www.princexml.com/doc-refs/#prop-prince-text-replace

janina: some people volunteered to edit
... so will be sending a draft

<jcraig> Zoe Bijl and Joanie Diggs

janina: Joanie will bring a11y expertise
... Zoe will bring CSS knowledge
... Will specify how to standardize across OSes
... Unless questions about that, move on to next issues

jcraig: had issue about dynamic text size, which is CSS issue 3708

astearns: ok next issue...

<jcraig> issue-3708

<trackbot> Sorry, but issue-3708 does not exist.

Display property value for visually hiding element while making available to assistive tech

astearns: brought up by TTML also

<jcraig> https://github.com/w3c/csswg-drafts/issues/3708

astearns: question is how to move forward on this capability

<heycam> github: https://github.com/w3c/csswg-drafts/issues/3708

AmeliaBR: The general use case is when you have text that adds a little extra information for assitive technology but either repeats something already visually on the page

<astearns> github: https://github.com/w3c/csswg-drafts/issues/560

AmeliaBR: or is text that is already obvious because of other visual cues
... so don't want to print the text, but want available to a11y
... there are methods used by authors using absolute positioning or clip
... intentionally picked by authors because not currently used as cues to screen readers to hide the text
... so feature requests coming to ARIA and CSS
... is to have a simple one property one attribute way to do this
... there are ways in specs defined to do this

<jcraig> Example of what AmeliaBR is referencing: <p>Read <a href=“#”>more <span class=“a11y”>About widgets</span></a></p>

AmeliaBR: there's aria-hidden=false, originally specified to do this
... there is the 'speak' property in CSS Speech module

https://www.w3.org/TR/css-speech/#speaking-props-speak

<jcraig> hidden=true aria-hidden=false

AmeliaBR: neither of these is implemented because in reality the visual display property has all sorts of side-effects in how elements are processed

<jcraig> aria-hidden=false was problematic for a variety of reasons

AmeliaBR: and saying 'display: none' or visually hidden but still available to AT
... has never happened in borwsers
... so feature request is for specific way to do things
... in ARIA yesterday had a talk about, is this really use case pattern we want to encourage by making it easier to do?
... visually-hidden styles can be misused by developers
... who are only thinking about visually-able vs. blind users
... missing a huge swath of people usign both AT and visual rendering
... so argument that this is a hacky approach for a reason, shouldn't make it easier
... but it is widely-used on the Web anyway, so argument for paving that cowpath
... my recommendation is to go ahead with this
... and do it in CSS
... because sometimes visually-hidden content depends on MQ
... e.g. button might have icon and text on big screen
... but on small screen only the icon
... but want AT to be able to see that text

<Zakim> jcraig, you wanted to remind the group that many (most?) screen reader users are not completely blind...

jcraig: I think this is valuable and needed
... but remind group that most screen reader users are not blind
... there are a lot of low-vision users
... ~ 1/5 are actually blind

astearns: Amelia's comment was that this is a bad assumption some authors make, shouldn't encourage

florian: the reason why neither ARIA attr or speak has been easy to implement
... is because AT works by reading plain text off the render tree
... this is the reality today
... can't ignore it
... but causes many problems
... exposing info to AT
... I hope this is merely current reality
... and not long-term goal we want to maintain
... because in that case many limitations
... there are many cases where we would want to work from DOM, not render tree
... because render tree has lost information that's in the DOM\
... I think we will see that problem in a number of use cases
... I would like us to not abandon idea that aria / display proposals

<Zakim> nigel, you wanted to point out that for text to describe media content the solution has to work in an ARIA live context

florian: I hope this is taken as a current situation, not a design goal, because otherwise many things cannot be solved

nigel: Some of the proposed solutions/hacks might not work for ARIA live regions
... for ? put forward this morning, want something that describes content in a video
... gets read out during playback of video
... want to use ARIA live region approach
... and have AT notice that

<florian> s$that aria / display proposals$that aria / speak proposals$

nigel: biggest gap we have is something that, following from florian's point, here is some text from render tree
... don't actually paint pixesl for it, leave layout alone
... atm visibility: hidden has effect that some screen readers don't read it out
... I would separate visibilty from display
... I would expect display: none to never feature in a display
... but visibilty is not rich enough

<florian> fantasai: visibility hidden currently leave things in the layout tree

<florian> fantasai: so they take up space

<florian> fantasai: we probably want a variant that doesn't

jcraig: technique used is positionign off-screen and clipping

nigel: want something more proper

astearns: and more simple

tink: I'm really strongly in favor of this proposal
... than existing methods, which cause alls orts of problems
... can confirm that visibility: hidden does get hidden from screen readers
... if we go ahead with an idea like this attribute
... what will we do with tab focus?
... techniqe that jcraig describes
... tab focus disappears off screen
... some renderers will screw up rendering as a result
... would there be some mechanism to get around that problem?

AmeliaBR: that's a very good argument for a proper bult-in feature
... then browser knows to override hiding and make things visible
... with current techniques, up to author to have a special focus rule
... to handle that case
... strong argument to have dedicated feature so browser knows why this style is being set, and to override

tink: so if was focusable content hidden, once it got focus would become visible
... makes visible, but if contents appear from off-screen, that would be quite disruptive
... is there a possibility to do it the other way around, take things outside of focusability?

AmeliaBR: that wouldn't help with skip links

tink: screenreaders have much better ways to navigate content
... skip links are mainly useful for sighted keyboard users

florian: would be problem to make things visible without author expecting it
... likely to break things
... would rather make it not visible, invoke HTML inert behavior
... author can pop things into visual space if they want

AmeliaBR: or maybe two different values of a property, recognize different use cases
... standard skip link that should become visible
... and extra information for screen readers

<Zakim> jcraig, you wanted to mention that WebKit was the one engine that implemented `hidden=false aria-hidden=true` and I can discuss some of the implementation details

jcraig: couple techniques mentioned, one seemed reasonable was HTML hidden=false
... aria-hidden=true
... or reverse of that rather
... webkit was the only browser to implement
... was very tricky, because webkit builds accessibiltiy tree off of render tree
... this was after fork from blink, so blink doesn't have
... firefox same thing
... so very challenging
... after noticing bugs
... decided to only allow this if every ancestor above was displayed
... so child node could be hidden, but not descendant
... not sure that's the right path, but is the one available atm
... technique in the ARIA spec, aria-hidden=false not recommended

<Zakim> nigel, you wanted to reply

jcraig: hidden=true aria-hidden=false

nigel: interaction between attributes and CSS properties not clear in spec, and varies in implementations
... there some weird stuff going on there
... my conclusion was to ignore HTML hidden

jcraig: on WebKit side, implementation was hidden=true { display: none; }

Rossen__: Edge actually supports everything you said about computing aria and various permutations
... there is an effort that was in EdgeHTML
... have ongoing work in Chromium to add additional capabilities to handle that n Chromium-based browsers
... not sure where Mozilla is

jcraig: no plans last I heard

<Zakim> ZoeBijl, you wanted to say that there are more assistive technologies than screen readers

ZoeBijl: Want to remidne veryone that there are more AT than just screenreaders that might be affected by this stuff

?: displaying something ...

jamesn: Issue of deliberately making things visible
... another use case is when you have native HTML control that you do not want to display but you want to use all of the properties that you get for free
... e.g. range control, can't increment/decrement unless native
... but can't sytle it properly
... so hide it, and display your own control over it
... common authoring technique right now, because can't make controls accessible on moble
... is one custom control for visual, and one hiden native control for interaction
... hidden using very low opacity so stll there
... you wnat it to not be inert in this case

<nigel> scribe: nigel

fantasai: we've heard a lot of new info in this meeting

<florian> fantasai: we've heard a lot of new information

fantasai: next step is someone to draft a proposal for a new CSS property or value
... probably a property

<jcraig> display value?

fantasai: that takes into account the use cases here and the various limitations
... I haven't heard a proposal yet.

<fantasai> astearns: https://github.com/w3c/csswg-drafts/issues/560

astearns: Is there a specific CSS issue for this?

fantasai: We definitely don't want to use the display property for this.
... too many other effects.
... There is an existing property in the speech module called speak
... which was intended for this use case but it doesn't address the issues of the render tree and focusability

jcraig: I've evidence that it was never intended to address this
... it's well specced for DAISY

<fantasai> jcraig: css-speech is very well-specced for DAISY use case, not for screenreader

<scribe> scribe: fantasai

astearns: need a volunteer
... lacking a volunteer, keep the issue open and periodically ping people

tink: can try to put words together but need someone on CSS side

AmeliaBR: I can help

<scribe> ACTION: Amelia and tink to draft a proposal

<trackbot> Created ACTION-883 - And tink to draft a proposal [on Amelia Bellamy-Royds - due 2019-09-24].

<IanPouncey> I can also help.

astearns: and bkardell_

accessibility section in transforms

<astearns> github: https://github.com/w3c/csswg-drafts/issues/3870

krit: To summarize issue here, we ahve a spec where animations are appleid to transforms in the transforms spec with combination of SMIL
... but I think this entire section shoudl be removed
... section introduces transform to the animate and set elements, both SMIL elements that refer to svg aniamtions
... in addition to what is in SVG already
... but there is no ? and no interest to implement
... so request to either defer or remove entirely
... if section gets removed, then there's nothing about motion in the spec anymore

AmeliaBR: issue is just asking you to add an accessibiltiy section?

krit: issue was about adding section about accessibility
... but we removed the section reference to motion, so no need for adding an accessibility section

AmeliaBR: one paragraph of animating transforms can be bad ?

fantasai: anything can be animated, width, margins, etc. do we add to every layout feature of CSS?
... I think better to keep in the animation section

AmeliaBR: so requesting to clsoe this issue as wontfix and follow up with getting it addressed in CSS Animations

krit: yes, but request woudl be to defer the entire feature
... if we want to do that, would suggest to try with SVGWG or SVGCG first

AmeliaBR: so other feature request is adding way to pause CSS Animations, which we don't currently have

krit: right

AmeliaBR: Dont' see why this should be deferred to SVG, CSS Animations has ...

fantasai: do we need to discuss all this with A11y?

krit: need to close issue no change beause moving teh section

IanPouncey: comment about documenting a11y concerns
... while I don't have a particular problem in this case
... just want to say the wya ppl use these documents is to find example they need and copy it directly

<tantek> I'm wondering if the request for the ability to "pause animation" also includes the ability to slow down the animation

IanPouncey: not going to look at different document
... in some cases we might want to have notes in multiple locations therefore

krit: would maybe put in boilerplate to add to every single module

<heycam> fantasai: if you put it in the boilerplate, it'll be at the top of the spec, and someone linking into the middle of the spec won't see it. maybe in the animation type definition?

fantasai: which is linked from propdef table

IanPouncey: happy to draft that note

AmeliaBR: I like fantasai's point, we do have a link from every CSS property definition "Animation Type", can put the note there
... each spec item in the spec would be connected to the warning
... Proposal is wontfix on request to add a11y consideration section to css-transforms
... for the remainder of the issue, request for pausing/stopping
... that will be opened as new issue on Animations or Transitoins

krit: can only wontfix if remove the animation section
... so request is to remove animation section
... since feature that is added on top of SMIL and no interest form impelmenters and from community

astearns: so proposed to remove the section and wontfix the issue

AmeliaBR: can be moved to SVG Animations Level 2 which may or may not ever go anywhere
... but that's where the text is lived

astearns: open a separate issue on that
... for this particular issue, remove section and wontfix

RESOLUTION: Remove section on animation and wontfix issue about paragraph about accessibility because no longer relevant

astearns: out of time

lunch

<br type=lunch>

<heycam> ScribeNick: heycam

<astearns> https://wiki.csswg.org/planning/tpac-2019#tuesday

canonicalization of :lang() selectors

github: https://github.com/w3c/csswg-drafts/issues/4154

florian: the :lang selector lets you select pieces of the DOM for styling based on the language
... it's alreay somehat smart, since lang tags are structured
... selecting zh, and the document saing zh-Hant, it will do the right thing and match it
... that logic is already built in
... the IANA maintains a registry of the langauges that exist and what they mean
... tags and subtags
... and in addition to just listing them, there is logic in that registry. some languages are a deprecated version of some other languages
... Cantonese used to be zh-yue. that is deprecated and replaced with yue
... the lang selector does not take that logic into account
... so if you have a document marked as lang="yue", and you are matching :lang(zh) or :lang(zh-yue), it won't match
... we may want to use the registry definitions of how to match
... I propose we do that

addison: some tag canonicalization is defined by BCP 47 to consume some of the information in the registry
... you've been corresponding on the IETF langauges list and I think some of your questions have been about handling macro-languages -- zh-yue is a macro language

florian: zh-yue is a macro language, zh is a macro language

addison: there's a separate thing. previous to the current BCP 47, there was a mechanism for regsitring whole tags
... that's grandfathered now
... some of them match subtags, some don't
... [...] is replaced by xtg
... ignoring grandfathered tags, they all map to something. the ones you're referring to are structurally identical, the tags are composed of subtags
... like zh-yue

florian: the way I'm looking at this, there are variety of reasons for why certain langauges might be the same
... there is a defined canonicalization that handles some of them

addison: for the BCP 47 canonicalization, that will do awy with the grandfathered ones and other strucutral weirdness

florian: it won't deal with the two types of norwegian
... this is a complicated topic with many weird variants

addison: there's a subset there that's well defined
... there's a second set of rules, which are in CLDR
... UTR 35
... for handling some additional cases around Chinese, where you have different script subtags that you want to appear or not in some circurmstances
... some of those may be of interest, but it's more complicated
... I don't want to pretend that doesn't exist, but they do

florian: if you have a link, please drop it

addison: defining matching, if you're just using BCP 47 "lookup" IINM

florian: extended filtering
... the text for extended filtering says you should canonicalize

addison: yes you should

florian: thanks for bringing up that the topic is broader

addison: if you do the minimum set, it'll make it the most predictable. the other aspects are worth studying
... there are some annoying corner cases in Chinese

florian: I hear support for the current proposal, and complicatd problems to think about in addition to that

addison: yes I agree with your current proposal and then do further study, and track the other standards happening in that space

florian: there is a PR for this

addison: should we review that?

<fantasai> https://github.com/frivoal/csswg-drafts/commit/3cff5d844b6415ef30d3e2dac221f9479e0ec7aa

florian: if you haven't I suggest you do

AmeliaBR: the other question on the topic, do we have implementor commitments?

r12a: the current text I'm looking at says "... must be converetd to x-lang form"
... that's a slightly different discussion from what you canonicalize it as
... zh-yue would become yue

florian: I had that discussion on the list as well
... this is the right direction
... zh doens't match yue. so if you canonicalize both to x-lang format, it'll match
... I raised this on the mailing list, and they agreed it was the right form to canonicalize it to

addison: some people on the list did
... the challenge is taht this will bring you more promiscuous matching than the author may have intended
... it'll make Canontese match Mandarin Chinese in some cases

florian: if you want to match Mandarin specifically that's also possible

addison: normally Mandarin is tagged just as zh

r12a: for all the macro languages there's usually a preferred language

fantasai: if the author cares that much, they can put the information there

addison: that's right
... you don't want to have them with a correctly tagged document, have the :lang match things they were [...]

duerst: that mailing list is no longer a WG

<addison> http://www.unicode.org/reports/tr35/#Canonical_Unicode_Locale_Identifiers

duerst: so people can give you opinions and background knowledge, but no formal resolutions

<AmeliaBR> So, to cases: (A) author used zh in stylesheet and yue in HTML; doesn't expect a match. (B) author used zh in stylesheet and zh-yue in HTML; does expect a match. Canonicalizing both yue and zh-yue to the same value will break one or the other.

florian: I agree that the problem can exist in both directions, too much or not enough, I think since we're doing it for typographical purposes, and the languages are realted, most of the time if you have zh styles you want it to match Cantonese too

<addison> http://www.unicode.org/reports/tr35/#Likely_Subtags

florian: it's possible to style Mandarin differently from Cantonese, Hakka, etc., but that's rare

r12a: it's not just Chinese we're talking about
... there are other languages that have much more differentiation between the language depending on which of the subtags you choose
... the point I watned to make was that we said that let's go ahead with the proposal at the moment
... looking at the issue, there was a proposal you wrote, I responded saying you had to modify that
... the PR doesn't say much
... not sure what the exact proposal is
... I think this information we're talking about now should also be part of that

florian: the earlier proposal that you rightfully pointed out I wrote too much, including making zh-HK match yue and things like this, that's not defined in the repo I'm referring to
... I'm just saying, just the canonicalization to x-lang form as defined by BCP 47
... and as supported by the mailing list that used to be the WG that used to define that document
... btu whichever way we go, including no change at all, has a risk of mismatching things in some cases

addison: not all tags match all values, otherwise what's the point
... the problem is to arrive at something that authors understand how to get the results they want
... we'll make some compromises, the question in which ones

fantasai: based on the conversation so far, it seems like I don't think canonicalizing yue to zh-yue is going to be good. either we don't canonicilze, or in a direction where zh encompasses Cantonese
... I am sure there are style sheets that just use :lang(zh), and they'll expect it to match

addison: the other possibility is that the inclusion or non-inclusion of the enclosing subtag -- in this case zh -- is a choice the author is making deliberately. if they've made that choice deliberately, if we mess eith their tags when doing matching it may produce results they don't expect
... most of the matching algorithms are strict "remove from right" subtag matching
... to make it obvious what's happening
... what's you start adding or subtracting subtags in ways other than the deprecation/renaming, I think that has more risk to it in your space
... since it's not obvious what's going to happen
... I would support doing the mappings that's in the registry, since that's where if you have mlutiple variations, because people have older documents and style sheets, they'll get the right answer
... that's different than adding or subtracting subtags

<Zakim> AmeliaBR, you wanted to suggest that this is better dealt with in the user agent stylesheet

AmeliaBR: we covered a lot of what I was going to say, but witha different conclusion
... it's important that when matching a style sheet and a document that we respect the way that the author matched it, don't want to introduce spurious matching from canonicalization
... also don't want to break matching
... from the examples brought up, it's obvious that any canoniclization may end up breaking one site or the other
... the question is then how do we make it easier in the general case for having new style sheets or new UA style rules deal with all these deprecated synonyms
... at the UA style sheet, that can just be an advice to UAs to look up the BCP deprecation list
... then also included the deprecated synonmous
... that doesn't work for things like a style sheet that is coming from a library or CSS reset
... or the case of newer code, writing a new new style sheet, but still apply to the old pages with the older language tags
... one approach that might address that use case is something like what we do with case insensitive selector matching
... a flag in the selector that means "this value or any synonms"

florian: so an opt in for canonicalization

addison: there are three sets
... the grandfathered list is permanently fixed and has been for 10 years
... all those tags have explicit mappings, you can safely map them to modern equivalents or vv
... individual subtags that ahve mappings, it's mostly about countries going out of business
... yiddish has two subtags, hebrew has two subtags, there's a canonical one
... the third thing is the x-lang thing, which is inconvenient
... because there's two ways to say things. with or without the enclosing subtag
... the canonicalization rule in BCP 47 says you can drop the primary langauge subtag and use the x-lang by itself
... it's permissible for implementations to do that
... I don't recall it says you can put it back

florian: there are 2 sets of rules
... one that just strips it off. the other says when you're done stripping it off, put it back

r12a: it says you could consider doing that

addison: the first two are completely safe
... you want to do those
... for interop
... the x-lang thing, I think you can choose
... whether to put the enclosing subtag on
... the challenge is that Chinese you'd want to do that, but some of the other macro languages are not as crisp. Arabic is one of these, Malaysian

<r12a> https://r12a.github.io/app-subtags/

r12a: Omani Arabic and Moroccan Arabic, which treat certain things differently, may have different font requirements
... but they both resolve to "ar" if we follow this PR
... but that's used for standard Arabic

florian: I think we're not ready to merge the PR
... action items: the safe subset of canonicalization, I don't think it's defined as a canonicalizing operation separately from the x-lang thing
... action on me to find out if we can

addison: this is an area that probably deserves better documentation from us
... we can go offline and make sure we get the right answer
... we can go back and talk to the locale folks at UNicode and the languages list and make sure we're capturing the sense of this

florian: one, figure it ouf if the safe subset exists as a standard operation
... two, if we do what I'm proposing, look at the affected languages and see if it's good for them

Breaking Rules at inline element boundaries

<fantasai> github: https://github.com/w3c/csswg-drafts/issues/3897

fantasai: there was an issue raised about what happens when you have two inline elements that have different ine breaking rules
... 3 props control this. white-space, word-break, line-break
... looking at an example (in the GitHub issue)
... at the boundaries of the span, which line breaking rules applies when it has a different word-break prop value to the rest of the text
... for white-space, the nearest common ancestor is used
... the complication for word-break and line-break is that the determining rules for where you're allowed to break requires running an analysis on a lot of text
... and every time that value changes you have to do another run, so impl wise it's a bit awkward
... there's been some discussion about what's the best behavior here
... I wanted to ask i18n if you have feedback on this issue
... and ask the WG if this proposal to leave this undefined for L3, give impl time to experiment
... doesn't seem to be a terribly high importance case to solve at the moment

florian: I think one of the more interesting cases -- and I suppose making it undefined -- is if the aprent div allows a break between every latter, and two spans next to each other which don't
... can you break between the spans or not
... current spec says yes, but it's hard-ish to implement
... if we need time to think about this, undefine it for a while, seems reasonable
... but that's the kind of case this brings to the surface

Rossen: any objections to leaving it undefined?

r12a: we should look at it as a group offline
... it's quite a long thread. I seem to remember someone brought up an example that didn't work

nmccully: are there layout engines working on this that would benefit from the extra time?

fantasai: part of the issue is part of the ICU APIs make it awkward for the rules to change in the middle of the line
... so impl wise it's awkward
... could be factorial if you're changing it every other letter in the line
... so there's some hesistancy to impl that given the current infrastructure
... but there doesn't seem to be great solutions
... some of the behaviours you'd get from doing an easy thing would be non-symmetrics
... you'd be switching slightly less if you use the current rule in the spec
... there's not a high pressure to solve this and get interop
... look at it again in L4

myles: tangential comment, the general thing we're discussin is styling element boundaries
... this is something letter-spacing also does
... the spec says something that all browsers diagree ith
... with we do come up with a good way to describe boundary behavior, we should try to use this system to describe letter-spacing too

fantasai: I think the spec is right on letter-spacing

nigel: I think it would be good to have a general way to handle this

florian: we have a current generalized rule, that is general, and does the right thing, and is painful to impl

RESOLUTION: It's undefined

<fantasai> https://github.com/w3c/csswg-drafts/issues/3481

<fantasai> https://github.com/w3c/csswg-drafts/issues/337

RESOLUTION: i.e., the presence of soft break opportunities between spans which change soft breaking opportunities is undefined

Remove collapsible line breaks adjacent to word separators

Collapsible breaks adjacent to word separtors

github: https://github.com/w3c/csswg-drafts/issues/3481

fantasai: we generally have this concept in CSS and HTML that you can use white space to format your source, and we collapse white space down to a single space
... including line breaks
... for Chinese and Japanese which don't use spaces, we have some rules to remove the space otherwise you will be forced to put all paras on one line
... there are some rules for doing that based on character classes
... what we didn't consider thoroughly is languages that use a word separator that's not a space
... we do special case ZWSP, for Thai and other languages
... but we don't have something similar for Ethiopic word space
... probably don't also want a regular space there
... proposal is when there's a word separator character adjacent to a line break, the line break just goes away
... I think the characters that are affected here are Ogham space mark and Ethiopic word space and the Tibetan tsek

AmeliaBR: does this map to something in Unicode? or do we need to maintain this list?

<koji> https://drafts.csswg.org/css-text-3/#word-separator

r12a: I think there is something, not sure if it's fit for this purpose
... archaic scripts have other examples

y

fantasai: [reads definition in the spec right now for word-spacing]

florian: we need to maintain a list

myles: let's ask Unicode to do it
... if there is such a facility for these character lists, hard to believe it's specific for the web platform
... and not needed in text editors for example
... I don't think the web specs should maintain this list

florian: I agree with part of your statement, should try to work this out with Unicode
... this one specifically maybe, but some are specifically web platform relatively
... since this is relevant to turning HTML markup into text

myles: there are many different markup languages...

fantasai: there are 2 questions
... if we want to do this, and then whether we maintain the list of if Unicode should

addison: i think we want to do some research
... space or no space is a classic problem
... I would be surprised if there weren't something, but don't know off the top of my head
... would be happy to engage

myles: if this is a classical problem, it's been solved, and we should figure out how it's been solved in the past and re-use that solution

fantasai: looking at some of the stuff in css-text, weh ave a concept of word separateors
... and it includes a set of code points
... it excludes Ogham space mark
... since it would cause text to not join any more
... so general usage in UNicode is text processing segmentation is not going to account ofr that concern, since they don't deal with typesetting
... so there's gonna be some aspects of how we're using Unicode codepoints with sepecific requirements that haven't come up in Unicode's context so far
... unbreaking lines is something that's been hard to explain to them

myles: maybe we shouldn't be unbreaking them?

fantasai: too late for that!

addison: fwiw I've had to write this code in the past, and it's not any fun
... it maye have been individually solved but not written down

<fantasai> fantasai: HTML has been unbreaking lines for as long as it has existed, we want to make that ability available to more languages

r12a: like with the other issues, we need to look in more detail
... the Tsek is a syllable separator, not the same as a word joiner
... you could end a line with a Tsek, then start with more Tibetan on the next line, with indentation, and no real reason to join those together necessarily

fantasai: you wouldn't make the Tsek go away, just avoid the extra space going in there

<scribe> ACTION: i18n to look this issue of word separators next to newlines

<trackbot> Error finding 'i18n'. You can review and register nicknames at <https://www.w3.org/Style/CSS/Tracker/users>.

<addison> ACTION: addison: ensure we respond to css 3481

<trackbot> Error finding 'addison'. You can review and register nicknames at <https://www.w3.org/Style/CSS/Tracker/users>.

ResizeObserver Device Pixel Border Box

<fantasai> ScribeNick: fantasai

chrishtr: device-pixel-border-box is the actual device pixel bounds of a canvas element
... including pixel-snapping feature which is ued by browsers to avoid blurriness by snapping to pixel grid
... fundamental problem with no complete solution
... authors that use canvas
... have no reliable method to determine on-screen pixel size of the canvase
... if off by one pixel due to pixel-snapping, rounding, or other issue
... will end up with wrong or blurry results
... pixel-snapping is intentionally not specced to allow UAs to do their best
... acocunt for varying rendering architecture
... and evolution
... so no way to reliably find this size
... proposal is to add a box that observes device pixel border box
... to ResizeObserver
... which will notify if that box changes
... will happen at similar timing as other ResizeObserver

<astearns> github: https://github.com/w3c/csswg-drafts/issues/3554

chrishtr: there were two main objections to adding this
... one was raised by Jeff Gilbert
... had a long discussion with him and Ken Russell, our WebGL expert (?)
... have a compromise proposal that both of us agree to
... objection he raised was that if you have a WebGL-centric application
... e.g. full-screen game that uses WebAssembly and only DOM in minimal way
... want to have a continuous requestAnimationFrame loop
... drawing the canvas
... in that model where you are canvas-centric
... it still lives in a DOM shell or browser window that has a size
... need to observe that size
... where pixel snapping will work
... but in Web Assembly not in JS
... most convenient to query device border box directly from canvas during rAF loop
... rather than by observer
... if layout was dirty at the time during making the query, it will force layout and other things in order to compute pixel snapping
... in taht use case maybe it's OK
... other use case, which I was most focused on
... you have canvas element embedded in a DOM-centric website
... maybe photo-app or ad or widget,
... potential multi-actor scenario
... want to avoid layout thrashing
... cases for which ResizeObserver was designed
... this makes most sense
... compromise proposal is that we just have both APIs
... The End! :D

jeff: ....

jgilbert: ... moving forward with both propsoals works out
... having it be in ResizeObserver also makes sense
... like you went over, there was some concerns about it covering espeically more easily some more trivial cases
... having both lets people pick and choose appropriate API
... default should be to use ResizeObserver, most reliable
... kindof like getClientBOundingRect() , need to be careful if calling that often
... maybe warn in UA
... if called too often
... but getDeviceClientRect() API alone ...

chrishtr: 2nd objection smfr raised
... pixel-snapping requires more information than just layout in today's engines
... in Chrome requires pre-paint step
... in Safari requires paint
... don't have solution to that problem
... just note readback method for rAF
... canvas.getThing
... also has to run the same steps

Rossen_: but that's not blocking to accept the proposla

smfr: in some ways make sit worse
... because 2 places we have to do this painting calculation

Rossen_: was asking if this second objection is blocking accepting the proposal

smfr: so to clarify the proposal is having API to return the box on canvas and also in ResizeObserver
... I'm not a fan of doing partial paitn to get this info
... I would expect for games , especially in full-screen, to position on ? boundaries
... surprised if using fractional pixel positioning

jgilbert: for full-screen, unlikely, but for partial screen almost always get this
... both on Windows and on Android, I believe, Windows will happily give you 1.6574 device pixel ratio
... you just have to deal with it
... you end up trying to reverse-engineer what pixel-snapping is to figure that out
... pre-snap a rect to a non-integre CSS size , if that works out to integer pixels... then no artifacts? but it's a huge mess

smfr: other case that's confusing is on our iPhone's that have retina displays
... already 2.7? scaling factors
... so can cause hairlines to disappear aetc.
... seems like also on windows, too
... getting pixel perfection, seems like OS is doing scaling behind your back, how can you expect it to work?

jgilbert: out of the box cases where if you play around with virtual scaling
... on a Mac and play with scaling on a retina screen
... no way to get 1-1 device pixel

myles: even worse, the default ratio is not 1-1 or 2-1

jgilbert: it really depends on how the OS is doing this sort of scaling
... I'll add that what you end up with, for instance in Mac, when you have this OS-level virtual resolution scaling
... can't get one to one
... if can't get 1-1 in application, can still get moire effects
... can't entirely eliminate scaling artifacts, but can do better
... than naively try to grid on the screen and hope it looks good

mattwoodrow: difference is on Windows the scaling isn't hidden
... can attempt to match

jgilbert: windows 10 implements scaling that llows 1-1 rendering, not virtual scaling as default
... Mac doesn't expose effective scaling, just says 2x all the time
... Android says 3x all the time

??: regarldess of what operating systems do, if application renders pixel -perfect

??: Result will be better than if it wasn't

??: I think we agree on that

myles: if goal is to get hairlines, even if you get a little closer to hairline, can still disappear

??: Display scaling might give you smoother color if checkerboard is pixel-perfect before the scaling

mstange: and if you have checkerboard before scaling, then less smooth design
... still discussing value of getting an accurate box? what's status?

jgilbert: if we decide that we don't want to give ppl this box, then ?
... do we want to get into that? or do we want to take it as a given that we're trying to give ppl most correct idea of device pixel than we can?

mstange: what we would need to do in Firefox to get this result
... Firefox takes into account the full zoom, and takes into account CSS Transforms
... space in which we snap is established by the closest animated ancestor transform or the root
... we only know this info during painting
... so would need to run more steps before giving info

smfr: this device border box would not be affected by transforms
... so would have to do *special* calculation

jgilbert: 3D transforms no idea what to fee dback
... pixel-snapped bounding box?

atotic: if you're doing transforms won't be pixel-perfect anyway, so don't worry about it
... your'e also talking about implementation that you need to get this nformation during pre-painting
... remember you had this information ??
... Might be ok to deliver incorrect information and not have to paint

myles: there's a chance of you never get correct info

atotic: I think you want, once things have settled down want accurate box size
... if animating, don't care so much

jgilbert: deliver informmation lately
... would be nice if we could try so that you could do 1-1 perfect every time within certain set of constraints
... be nice if we didn't immediately settle on a 1 frame late policy
... matching what native APIs are able to do
... don't want to suffer if dont' have to suffer on native

myles: if it is one frame late then the exact timeline that we drop frames is exposed to the Web so don't think we want
... similarly, worried that we'd have to reverse-engineer chrome's pixel-snapping strategy

jgilbert: shouldn't have to do more normalziation than you do today, I think
... if trying to use this to get anti-moire, in order to do this today have to ??

smfr: one frame late version also problem of which rectangle to trust

chrishtr: not late if layout occured
... only late if you have a threaded animation

smfr: thought it would be late because we woudl collect info at paint time

chrishtr: I don't think we shoudl do that, disagree with atotic
... think we can do it therefore we should
... in cases where layout has occured
... agree with point about threaded animations and not syncing with JS thread

smfr: want to tie together two of previous points, first that if we implement this paint day device pxel border box, will be more expensive for us
... secondly because of physical mismatch, wouldn't have some user benefit
... display is scaling anyway
... can we get examples?
... want to try on Apple devices, see what would happen if looks right

atotic: moire patter
... if you're moving canvas around the screen, the moire is animated. looks really bad

smfr: please give us some tests

chrishtr: I think time is up?
... propose to add the feature?

Rossen_: does the group feel there's enough merit to add this?
... would be adding both APIs
... is there any objection?

smfr: I dont' think we can accept new API without evidence that it's so much better that it's worth the extra cost

fremy: you can agree with the API and just return some approximate result if you feel it's good enough

myles: your'e saying implement the API without implementing teh API

fremy: might not be useful on your device
... but might be useful on Android
... so just return the result

AmeliaBR: Not having an API is better than having API with bad results
... if a particular browser has particular concerns about implementing the particular API

<jgilbert> fantasai: in this case it would be, if you as an author were trying to do this thing, and you had this browser gives me the actual DPR, and this one gives me some approximation of the size

<jgilbert> ... I still need to size my box either way

<jgilbert> ... if my choice is I can get teh actual device pixel size from Chrome, but calcaulate it myself from widht/height props in WebKit, and get an approx result, then I don't know it might be better to have an API that does that calculation for me

<jgilbert> ... then I only need to write one code flow

AmeliaBR: might make sense, but have existing cases where you can't trust the API

florian: In general I agree with your statement, this doesn't seem to be such a case

Rossen_: I woudld like to end this topic
... going to call for objections to adding the API, if we have objections we'll deal with them and have additional conversatiosn with the TAG and whatnot
... any objections to having these APIs?

smfr: Can we wait until we ahve the examples?

astearns: I might object because seems like we need more data
... so I will object on Safari's behalf

Rossen_: so back to you to get test cases, we'll discuss again on telecon

CSS Writing Modes Implementation Report and Open Issues

<florian> https://drafts.csswg.org/css-writing-modes-3/implementation-report-2019-08

<mstange> ScribeNick: mstange

florian: We've been working on the writing mode spec for some time. I've updated it since I've showed it last month.
... Out of about 1000 tests, about 14 failed and 24 others failed. (?)
... There will always be some tests that fail. We'll be fixing things forever.
... Have we done enough fixing already to move on?
... There is a number of issues that are marked in yellow, which are a not insignificant part of the remaining tests.
... They have some patches which are about to land in Gecko so that they will pass.
... Some tests could be split up into two tests, both of which will each pass in different browsers.
... There are a couple legitimate failures as well.

iank_: Please don't remove tests that test intersections of features. Those tests are useful.

florian: In this particular test, the two features are independent. The intersection is not tested.
... The test results are from current Chrome Canary.
... We have not done enough work on writing modes to never think about it again.
... But I don't think any problems are in areas we believe to be wrong in the spec.
... It's my opinion that we can move on despite those failures.

<xfq> Current open issues (for L3): https://github.com/w3c/csswg-drafts/issues?q=is%3Aopen+is%3Aissue+label%3Acss-writing-modes-3

<Rossen_> https://github.com/w3c/csswg-drafts/issues?q=is%3Aopen+is%3Aissue+label%3Acss-writing-modes-3

fantasai: There are some issues about things where the spec is unclear, and we should just do those clarifications.

florian: All issues are about things that ought to be better defined. But we need help.

fantasai: I think it would be better to address these issues before saying that writing mode L3 is done.

dbaron: I've been uncomfortable with some of the things about intrinsic sizing.
... I think the third issue is more on the material and sizing than on the material and writing modes.
... In response to being asked to implement something in Firefox, I ran into a list of conditions that was unclear.

florian: Was this not partly answered by text that was restored?

dbaron: I think this was after it was being restored.

florian: fantasai discovered that some section had been lost and it was recovered in late August.

dbaron: This is a specification pattern that is difficult for authors. Rather than saying "You want to compute X", it says "You calculate in the following terms".
... It is very hard to know what some of the terms mean in a specific context.

florian: I agree that this specific text should be tweaked. But the level of writing in L3 is higher than in L2. Raising the bar of writing is good, but gating specs on that bar might not be necessary.
... Can we address this in L4?

dbaron: I guess. L2.2 probably did not have backward references to things that were poorly defined to the degree that L3 does.

Rossen_: How do we move writing modes forward?
... Do we actually want to hold off and resolve on these issues with additional spec works and re-enter PR at a later time?

fantasai: With the exception of some tweaks, Gecko seems to have implemented this just fine.
... We are basically rewriting all of CSS 2, but we need to do it in pieces. The current writing is not ideal, but it is the best I could do without rewriting chapter 10.

AmeliaBR: Given that fantasai has said that Gecko is right, could dbaron suggest new text that describes that & addresses his issues (in time for publication)

dbaron: The hard part is the edge cases. The question is not, "Do we follow this list of things in simple case X which is being tested", it's "what is the exact list of cases where we need to do this list of things"

Rossen_: We almost went into Rec two or three years ago. I think the level of the spec is fairly high at this point.

dbaron: I'm ok moving forward if you want, but there are cases that are not defined enough to be implementable in an interoperable way.

fantasai: This spec was written assuming grid and flexbox do not exist. We can't make this gate on defining exactly how things work in grid and flexbox.

dbaron: It would be nice to give an example where this list doesn't apply.

fantasai: I don't know of one.

dbaron: That's why I suggested stating in the spec that it always applies.

<astearns> +1 koji

Rossen_: The proposal was not to resolve the issues, it was to move them and retag them for L4.
... Any objects to retagging the three issues to level 4? Those are 4026 3095 and 2890.

<astearns> and they will need to be added/updated in the DOC

Rossen_: No objections. We will move these issues to be tracked under L4.
... Are there any objections to move CSS writing mode Level 3 to PR?
... No objections, resolved.

<fantasai> fantasai: Ah, the case was about computing max-content inline-size vs auto block box inline size: in latter case, it's not well-defined what max-content computation is in CSS2, so could be conceptually that available size is infinite, and it's OK. But auto width computation needs definite length to subtract margin/padding/border from and result in non-infinite content-box width, so can't use infinity, so

RESOLUTION: Move CSS Writing Modes L3 to PR.

<fantasai> have to use fallback size

Remove font-variant @font-face descriptor from Fonts 3

github: https://github.com/w3c/csswg-drafts/issues/2531

myles: We have two text paths. In WebKit. The distinction which path to go to has to happen before font fallback.
... Sometimes we detect something too late and can't go back and re-do everything, so we just do our best.
... If this is not necessary for the web platform, let's remove it.

fantasai: It does look like there is an implementation (faceless2 says it in the issue)
... If the feature doesn't have a problem, we should leave it. We do not need implementations to move this spec at the moment.

myles: When is the deadline? It's been years.

Rossen_: This is a non-verifiable implementation. How do we evaluate it?

drott: We would support removing it because the semantics are unclear in some cases.

heycam: We would also be fine with removing it. We haven't heard much demand from authors.
... In principle it seems like a useful thing, but we would be fine with removing it.

Rossen_: Any objections to removing it?
... No objections.

RESOLUTION: Remove font-variant @font-face descriptor from Fonts 3

mitigations for font based fingerprinting

github: https://github.com/w3c/csswg-drafts/issues/4055

chris: The issue is that you can pretty much identify individuals based on the set of installed fonts.
... For example, I have all CSS test fonts installed and some fonts for languages I don't speak, and that identifies me uniquely.

<foolip> fantasai, florian, TabAtkins: we're in the #testing meeting debating what your requirements actually are. can we interview you later?

chris: One proposal was to only report fonts that are the standard fonts for that platform.
... But this would cause you to re-download fonts you already have.
... This consumes unnecessary bandwidth.

florian: On some OSes, even the set of default fonts can almost uniquely identify you.

myles: It is impossible for the spec to describe the set of default fonts.
... The proposal is to say in the spec that browsers must have some affordances to protect user privacy by having some sort of (?)

florian: On the performance vs privacy question, I lean towards privacy. On performance vs internationalization, it's less clear: If you don't have the font for a particular language and can't read the text, that's bad.

chris: There is a strong web compat problem here. Things that used to work should not break.

florian: When working means look pretty, there's a trade-off. When it means you cannot read it, it's different.

myles: WebKit has been doing this for over a year. We discard user-installed fonts.

florian: Mongolian without fonts is unreadable.
... When it is readable, removing the fonts breaks it.

myles: It's a trade-off.

thomas: How did you choose that list of fonts?

myles: I commented on the issue.

<fantasai> It was also pointed out that downloading fonts can cost money in some areas, and this is more likely to be the case in areas which are more likely to use minority languages

thomas: Rather than a bespoce list, could we come up with a list that can be updated periodically? Some list that covers languages for i18n use cases, as well as some fonts that are installed on machines.

<fantasai> and which have less money to spend

iank_: The information about fonts is queriable by measuring the bounds of boxes, without getting the list of fonts from an API.

Rossen_: We will pause the discussion of this issue and unpause it after the break.

Vertical text doesn't play nicely with font-style and font-stretch

Dynamic text size

<heycam> github: https://github.com/w3c/csswg-drafts/issues/3708

jcraig: For a long time we've had scalable fonts that are based on the Desktop Web.
... It took us a while to make it work on all extreme cases.
... We would like to support low vision users who have extremely large text sizes.
... Forcing such giant font sizes on web pages would make most web pages unreadable.
... We would like to have a way to opt in to larger font sizes.
... as an author.
... We would also like to propose a feature that allows web pages to detect large font sizes and adjust the sizes of other elements.
... We have some aspects of this that are available today: You could detect based on min-width in ems, but that does not work consistently.
... Right now there is no standard way to opt in to this that works across all browsers.
... Most browsers on mobile systems don't want to break their users' layout.
... We have examples where it would be very difficult or even impossible to achieve the intended layouts today.
... [demo]
... I have applied iOS settings that render text extremely large and bold.
... I can show how different apps deal with this setting.
... Calendar switches to 3 or 2 column layouts.
... The Books app switches from a 2 column layout to a single column layout.

<fantasai> These are all very easy to do if you have flexbox/grid and correctly implement media queries in em units

<fantasai> or ch units

jcraig: In Mail, with larger font sizes, the title gets clipped but the email's time is preserved.

fantasai: Is the problem that we can't actually implement media queries with em and ch units because the web would break, but you want to have media queries with em and ch units?
... Everything you've demonstrated here is totally possible with em and ch units in media queries.
... On mobile you're not returning the correct values because that would break. So what you're saying is you want real units?

jcraig: What we want is an ability for an author to say "I can handle any font size you throw at me."

florian: How possible is that this signal becomes worthless over time as it gets copied around, and we need to add still another signal?

chris: People are rapidly going to find out that just copying this around will break them.

jcraig: The reason we don't turn this on by default is that web developers *don't* find out that it breaks them.
... They haven't turned on these large fonts on their system.

<chris> fair point, retracted

jcraig: The first part of what we need is the opt in to the higher font sizes. The second part is the media query part.

fantasai: In order to do the kind of layout transformations you want, you also have to know how many letters fit on the screen. You'd use the min-width query.

jcraig: That would get us some of the way.

fantasai: Having just the media query for the font size is not enough if you can't relate it to the size of the viewport.

florian: You can't compare the font size and the viewport because the lengths have different units.
... The thing you call an opt in would also opt in the media queries to behave properly.
... Whichever opt-in we have needs to opt in both to behave how things were originally intended.

<AmeliaBR> `@media (min-height: 10em)` only works if the window root em size is accurate. So if we don't reveal the accurate preferred em value except in an environment value, you'd need to use `@media (min-height: calc(10*env(user-font-size)) )`

fremy: If you have a user font size variable, you can use calc to obtain the right answer.

fantasai: As an environment variable, it would work out.
... But Firefox uses different font-sizes for different languages, so it would be multiple variables, not one variable.
... The size of ch is dependent on the initial font, not on the font that is used.

florian: There is a number of ways you can use environment variables to do what you want, but if the opt-in mechanism opted in everything, it would also work.
... Is there reason to exclude media queries from the opt in?

jcraig: It should not be excluded.

fremy: You want to be able to opt in only parts of a web site.
... If the developer in the iframe did the work to deal with large fonts, if it is embedded in another website that does not handle them, all the work is for nothing.

jcraig: The reverse is also true.

fantasai: If the widget is inheriting the font from the parent document, then it's going to have problems if the parent document picks a larger font, regardless.

fremy: You cannot say media queries behave differently for different parts of the same document.

florian: Yes, if you put a responsive widget into a non-responsive website, then yes, your responsiveness is wasted.

jcraig: It sounds like we're agreeing that it would be useful to have an opt-in for websites to express that they can handle large font sizes.

florian: And we do not agree on the media query part - depending on how we do the opt-in switch, that switch may also opt in media queries automatically.
... If we can't make the existing media queries work, we maybe need to add more media queries.

jcraig: That sounds reasonable. Once we have an opt-in we can experiment and see in what cases it's not good enough.

AmeliaBR: Having it in CSS would be better than having it in markup because you can put it into one shared stylesheet.
... In order to get useful media queries, the opt in has to be outside of a property.
... If somebody has explicitly set this opt in value, then the existing font-size keywords that were supposed to be relative to the user-chosen default font size can actually do that.
... Otherwise, the default size will be the legacy 16px.

jcraig: I think that sounds ok. But a new media query would be clearer in terms of what we want to communicate to authors.
... Without that, the complexity of doing layouts based on width and layouts based on font-size is going to result in lots of media query blocks. (?)

Rossen_: We need to work towards a resolution.

plinss: I'm concerned about adding yet another mode switch. Mode switches are bad. Can we do the right thing without a switch?

fantasai: I hate meta tags because you can't put them in a stylesheet and link them from everywhere.
... However, it seems to make the most sense to add this as a meta tag because it affects media queries and the initial containing block size.

<gsnedders> RRSAgent: make the minutes

fantasai: And once the mode has been switched, font sizes and everything else can start working the way initially intended.
... These things all belong together so we should just tack on a meta tag.

Rossen_: I do not hear agreement on exact technicalities.
... Let's have a resolution on having a way to opt in, even if we don't have the exact way of doing it.
... Objections on opting in to true user font sizes?

jcraig: We (Apple) tried to do this without a mode switch, by default, and all 200 000 apps broke.
... Even with an opt-in switch, it took years for all first party apps to support this mode.

fantasai: I don't like mode switches either, but the alternative is to add an entire set of units. A mode switch is a lot simpler.

AmeliaBR: I came in with the same concerns as plinss, but one thing I did bring up was that, at the user agent level, there should be reflection of the fact that there are two cclasses of users.
... Some users want fonts that don't want broken web pages, and some users want readable fonts even if pages are broken.
... It seems that most users will accept smaller fonts if it means that pages are not broken.

plinss: I have no concerns with a user switch. I have concerns with adding a switch to the web platform.
... If we have to commit the sin again of adding another mode switch, let's add it in a way that it can fade away in the future, and not such that content will break if authors don't anticipate the switch.
... There is real costs to adding mode switches.

myles: The resolution seems to be about intention, not implementation. Let's try to agree on that.

Rossen_: Objections to having the option to have true font sizes?

RESOLUTION: There should be a way to have true font sizes.

Summary of Action Items

[NEW] ACTION: addison: ensure we respond to css 3481
[NEW] ACTION: Amelia and tink to draft a proposal
[NEW] ACTION: i18n to look this issue of word separators next to newlines
 

Summary of Resolutions

  1. Igalia meeting is 10-7
  2. CSSWG meeting Monday 27 April 2020 - Wed 29 April 2020, Houdini afterward (pending booking confirmation)
  3. PR of css-contain-1, dropping style containment (at-risk)
  4. Add proxy-width/height/inline-size/block-size with values legacy | auto | <length>
  5. FPWD css-contain-2 being copy of css-contain-1 (including at-risk features)
  6. Adopt css-highlight-api as ED with sanketj, florian , and hober as editors; add issue into css-pseudo-4 for where it might be integrated pointing at the ED
  7. An anchor node only can be every box except a non-atomic inline box
  8. An anchor node can be any box except non-atomic inline boxes
  9. revert the change made in #3224, and add spec issues to define this
  10. republish the wd of css-multicol
  11. Add a new "pseudo-stacking context" definition and use it to define how backface-visibility works
  12. Move path() down to Shapes 1, adding it to <basic-shape>.
  13. Trailing "other-separator spaces" will hang, accepting fremy's PR.
  14. Impls can ship clip-path:path()
  15. Add Myles as co-editor to CSS Size Adjust.
  16. Specify text-size-adjust more fully.
  17. Remove section on animation and wontfix issue about paragraph about accessibility because no longer relevant
  18. It's undefined
  19. i.e., the presence of soft break opportunities between spans which change soft breaking opportunities is undefined
  20. Move CSS Writing Modes L3 to PR.
  21. Remove font-variant @font-face descriptor from Fonts 3
  22. There should be a way to have true font sizes.
[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version 1.154 (CVS log)
$Date: 2019/09/17 06:45:58 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/Not in April/Not in Spain, in April there will be one/
Succeeded: s/idea/ideal time/
Succeeded: s/Contain Size/content-size/
Succeeded: s/???/cbiesinger/
Succeeded: s/??/element upgrades/
Succeeded: s/addd 'rendersutreeinvisble'/add `rendersubtree="invisible"`/
Succeeded: s/non-/none-/
Succeeded: s/amelia/AmeliaBR/
Succeeded: s/?/SpeechSynthesis/
Succeeded: s/in email/in gmail/
Succeeded: s/Scopes/Skobes/
Succeeded: s/Ian Skobes/Steve Kobes/
FAILED: s/Ian Skobes/Steve Kobes/
Succeeded: s/kanbun/kaiji/
Succeeded: s/kaiji/gaiji/
Succeeded: s/alone/and such/
Succeeded: s/not/smfr: did not/
Succeeded: s/[...]/overflow:hidden/
Succeeded: s/it/doing path() in shape-outside/
Succeeded: s/astearns/AmeliaBR/
Succeeded: s/emilio/TabAtkins/
Succeeded: s/that's not/that's not what/
Succeeded: s/that's what/that's not what/
Succeeded: s/???/stantonm/
Succeeded: s/double-text/double-tap/
Succeeded: s/Florian/fremy/
Succeeded: s/anytone/anyone/
Succeeded: s/we don't care about/we do care about in a test with fuzzy parts/
Succeeded: s/Nigeal/Nigel/
Succeeded: s/isses/issues/
Succeeded: s/to compress/but then beyond that it goes to vertical, not horizontal overflow/
Succeeded: s/but then beyond that it goes to vertical, not horizontal overflow/to compress, but then beyond that it goes to vertical, not horizontal overflow/
Succeeded: s/advanced/against/
Succeeded: s/???: because the fonts/nigel: you're asking a lot of the implementation and reducing authoring flexibility/
Succeeded: s/?/COGA (cognitive)/
Succeeded: s/language specific/typographic mainly/
Succeeded: s/??08/3708/
Succeeded: s/cuse/cues/
Succeeded: s/=true/=false/
Succeeded: s/live environment/live regions/
Succeeded: s/variant/a variant/
Succeeded: s/sighted suers/sighted keyboard users/
Succeeded: s/?/jamesn/
Succeeded: s/spec/issue/
Succeeded: s/???/accessibility section in transforms/
Succeeded: s/UTF/UTR/
Succeeded: s/WG defining/WG that used to define/
Succeeded: s/???/nigel/
Succeeded: s/Kem Russel/Ken Russell/
Succeeded: s/.../in Web Assembly/
Succeeded: s/??/mstage/
Succeeded: s/mstage/mstange/
Succeeded: s/closest non-animated transform/closest animated ancestor transform/
Succeeded: s/astearns/Rossen_ /
Succeeded: s/are we ok with (?)/could dbaron suggest new text that describes that & addresses his issues (in time for publication)/
Succeeded: s/2819/2890/
Succeeded: s/No objections. We will move these issues to be tracked under L4./Rossen_: No objections. We will move these issues to be tracked under L4./
Succeeded: s/spec/speak/
Succeeded: s/heycam/thomas/
Succeeded: s/???/jcraig/
Succeeded: s/???/fremy/
Succeeded: s/(?)/Firefox uses different font-sizes for different languages, so/
Succeeded: s/two/true/
Present: Aleks_Totic AmeliaBR Brian_Kardell Florian_Rivoal Fronteers Google Igalia_and_Open_JS_Foundation Invited_Expert Mozilla Nigel_Megitt Rachel_Andrew Rossen_ Simon_Sapin birtles cam cbiesinger chris chrishtr dbaron drott drousso eae emilio futhark iank_ jihye krit leaverou majidvp mattwoodrow mstange myles oriol plinss prushforth skk smfr stantonm tantek xfq_ yigu zcorpan xfq TabAtkins SimonSapin heycam jgraham Léonie (tink) ZoeBijl mck dauwhe_ bkardell_ IanPouncey Irfan achraf aboxhall_ Roy Judy DavidClarke
Found ScribeNick: fantasai
Found ScribeNick: myles
Found ScribeNick: emilio
Found ScribeNick: heycam
Found ScribeNick: TabAtkins
Found ScribeNick: heycam
Found ScribeNick: TabAtkins
Found ScribeNick: birtles
Found ScribeNick: fantasai
Found Scribe: nigel
Inferring ScribeNick: nigel
Found Scribe: fantasai
Inferring ScribeNick: fantasai
Found ScribeNick: heycam
Found ScribeNick: fantasai
Found ScribeNick: mstange
Scribes: nigel, fantasai
ScribeNicks: fantasai, myles, emilio, heycam, TabAtkins, birtles, nigel, mstange

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 15 Sep 2019
People with action items: addison amelia ensure i18n respond tink we

WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)


[End of scribe.perl diagnostic output]