<astearns> (Rossen's Windows machine is loading updates)

<myles_> myles_

<Rossen> Rossen Atanassov, Microsoft

<astearns> Alan Stearns, Adobe

<jensimmons> Jen SImmons, Mozilla

<skk> Hiroshi Sakakibara, Beyond Perspective Solutions.

<ericwilligers> Eric Willigers, Google

<gregwhitworth> Greg Whitworth, Microsoft

<eae> Emil A Eklund, Google

<futhark> Rune Lillesveen Google\

<drott> Dominik Röttsches, Google

<florian> Florian Rivoal, Invited Expert

<rego> Manuel Rego, Igalia

<iank_> Ian Kilpatrick, Google

<krit> Dirk Schulze, Adobe

<smfr> Simon Fraser, Apple

<myles_> Myles C. Maxfield, Apple

<rachelandrew> Rachel Andrew, Invited Expert

<jihye> Jihye Hong, LGE

<TabAtkins> Tab Atkins, Google

<melanierichards> Melanie Richards, Microsoft

<surma> Surma, Google

<heycam> Cameron McCormack, Mozilla

<mstange> Markus Stange, Mozilla

<bkardell_> Brian Kardell, JS Foundation

<lajava> Javier Fernandez, Igalia

<philipwalton> Philip Walton, Google

<Vlad> Vladimir Levantovsky, Monotype

<glazou> Daniel Glazman, Privowny

<vmpstr> Vladimir Levn, Google

<koji> Koji Ishii, Google

<Rossen> https://wiki.csswg.org/planning/tpac-2018

<inserted> Scribe: gregwhitworth

accessibility mappings

aboxhall: this topic is due to a bug from display: contents
... the issue is that nodes with display: contents don't get a css box but the a11y tree is based on the layout tree
... everyone expected that this will just work but that isn't the case
... TabAtkins asked me to explain the a11y tree

<rachelandrew> description of display: contents issue here https://hiddedevries.nl/en/blog/2018-04-21-more-accessible-markup-with-display-contents

aboxhall: who here is a bit confused about the a11y tree
... when we say the a11y tree, it is not completely specified but there is an HTML-AAM spec but the tree is not specifically specified
... it is a tree of semantic nodes that are exposed to screen readers and other ATs
... you'll need to know the role, the label and the other properties that are necessary to provide the user the relavent context for the element their actively on
... what we do is map, indirectly from the DOM tree to this tree

emilio: in mozilla we hang it off the frame tree which is similiar, but it allows us to gather everything from shadow and display contents, not quite clear to him what edge cases exist

<rego> emilio:

emilio: it would be good if we can come up with a model that also works with shadow DOM

Rossen: for Edge, it's slightly different
... this tree that we're all referring to is actually ill defined, which I believe was aboxhall point
... we base it off the DOM tree and use the box tree only where necessary - they're not tightly related

<Chris_Lilley> hearing that the acessibility tree is vaguely defined is concerning. Is that because no-one could agree on a tighter specification?

Rossen: I can see why display: contents would be an issue

florian: it seems the Edge scenario is closer to the intent as DOM traversal is what is what should be kept

<futhark> futhark

futhark: when you say DOM tree, do you mean flat tree?

aboxhall: to me it makes the most sense to base it off of the flat tree
... it does mean that we do need a normative tree, if you are working on something that touches the accessibilty tree to please discuss it with us
... it doesn't just impact the a11y tree but it impacts focus - people have assumptions with how it should work

florian: I do think we do need a normative spec
... but we should avoid notes in the spec
... it makes an assumption and that is what is incorrect

TabAtkins: it covers it if it's not based on the box tree
... it has no normative meaning - it's just a note

florian: basically the problem comes down to no normative spec for the tree

jensimmons: are Google and Safari going to be able to fix this issue?

aboxhall: well, I'm working on it - for the past month
... we're going to base it off of the flat tree

gregwhitworth: is there a proposed solution?

aboxhall: I don't have one right now
... if there are people that want to work on a normative spec for the a11y tree - maybe it's a good discussion for the planery day with OS, Browser Vendors and ATs

Rossen: I would be very supportive of this
... regardless of where the work happens
... I want to use this as an opportunity to blend the CSS AAM task force going forward?
... because we want to avoid these types of issues
... I for one, am going to acknowledge that this isn't as good as it should have been and there are too many assumptions that were made
... the root cause needs to be addressed, let's not try to solve it here. You're on point that we need to be more diligent on getting ahead of this issue

TabAtkins: I like the idea of getting a plenary day session for this - if you have the technical accumen for this topic

aboxhall: I want to pick up on things - I think you're referring to the computed tree AOM
... we have the notion of a programatic spec for the computed value, and in order to do that we need to have an idea of the tree, so synchronizes those efforts

florian: I think we all intended for that specific feature the node should still exist in the tree

<jensimmons> what’s that issue number?

fremy: the text in the spec states that it should only be impacting visual layout

<astearns> 2355

<TabAtkins> https://github.com/w3c/csswg-drafts/issues/2355

fremy: it is more clear to me, so that should mean that this shouldn't impact the a11y tree

aboxhall: it is a bit of a tangent but that means it wouldn't affect focus as well

fantasai: that's in the box as well

florian: for that case, it is a bug then

TabAtkins: we need to get the right technical answer to resolve this

Rossen: I want to get back to - do we need to amend the display: contents spec in any way?
... are you looking for any particular change to the current spec?

<Rossen> https://www.w3.org/WAI/APA/task-forces/css-a11y/

aboxhall: I can't answer that right now, I'll need to look at the orange box that people are tlaking about - I'll take that offline

<fantasai> aboxhall, https://www.w3.org/TR/css-display-3/#the-display-properties

futhark: do we need to take into account anonymous table boxes for example

<fantasai> “The display property has no effect on an element’s semantics: these are defined by the document language and are not affected by CSS. Aside from the none value, which also affects the aural/speech output [CSS-SPEECH-1] and interactivity of an element and its descendants, the display property only affects visual layout: its purpose is to allow designers freedom to change the layout behavior of an

<fantasai> element without affecting the underlying document semantics.”

Rossen: that was why we brought up the CSS AAM which is to deal with that situation specifically
... table fixup, deals with that situation specifically
... I want to draw attention and try to this task force and request help
... this is a great issue that we should look into
... now that we have the issues in there we need to work on them

TabAtkins: it feels like one of the display editors should be in that

<Chris_Lilley> aboxhall, the text is in <div class="advisement"> which happens to be styled orange

fantasai: I'm not interested in editing in any other specs

rachelandrew: I'm interested

<aboxhall> In what spec, could you link? @chris_lilley

<astearns> https://www.w3.org/WAI/APA/task-forces/css-a11y/

Rossen: to avoid yays or nays, if you're interested - go get signed up - the link is in IRC

<Chris_Lilley> the one fantasai linked to

Rossen: go ahead and +1 if you're volunteering to IRC

<Chris_Lilley> https://www.w3.org/TR/css-display-3/#the-display-properties

Rossen: having said that, aboxhall is there anything else you'd like to talk about?

aboxhall: I agree with TabAtkins to see the display editors, it would be nice to see things not ship until a11y issues are resolved

Rossen: how things have occurred - fantasai was on all of the calls that we had, flex ordering for example

<rachelandrew> +1 would be interested in being part of the a11y TF

<aboxhall> @chris_lilley thanks!

Rossen: this lead to definitive text in the spec but is flexible that allows people to innovate
... what I'm trying to say, is that these issues aren't lost on us and aren't an after thought - we can always do better though

fragmentation

fantasai: the suggested was to add a margin break property which controls how margin behaves at page breaks

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

fantasai: if you have to start a new fragmentation then the margin after it is preserved, for example a new margin heading
... if you're at an unforced break then it isn't preserved - this makes sense because margins are there to create space between things
... so this would allow you to keep or discard
... auto, keep, discard are proposed keywords in fragmentation L4
... this is the only thing in that level

florian: this property exists in the antenna house formatter

Rossen: is there any discrepency on the type (columns, page, etc)

fantasai: no they all behave the same

jensimmons: I beleive this fixes one of the things that bugs me with multicolumn

fantasai: we would have to be clear that it would occur with the different fragmentainers
... there are different set of issues that are dealing with margins that aren't fragmented

TabAtkins: would this apply to general BFC?

<jensimmons> rachelandrew: what’s the number of that bug?

fantasai: no

TabAtkins: to me that sounds like the thing that Jen just asked for

<rachelandrew> 1939

fantasai: we need to determine if it works with the first fragmentainer or not

<jensimmons> This is the bug we need fixed. https://github.com/w3c/csswg-drafts/issues/1939

<florian> https://www.antennahouse.com/product/ahf60/docs/ahf-ext.html#axf.margin-break

gregwhitworth: and it's the same 1:1 scenario?

florian: yes

TabAtkins: I'm curious why they only allow an optional 'keep' for after margin

fantasai: because the only option is keeping it because currently it's always truncated

Rossen: this propety, if we bring it forward to fragmentation 4...

<emilio> So, is `auto keep` a valid value? That sounds wrong

fantasai: we could also put it in box 3 or 4, etc
... there's little requested, this is currently the only thing

Rossen: any other opinions about margin break?

emilio: does it allow the auto keep value to be correct, because that's kind of weird

florian: I recommend we open an issue on that

emilio: sure

jensimmons: I don't want to bikeshed the name, but is margin-break the right name?

fantasai: we have margin-decoration-break as well so this carries that forward

<TabAtkins> AH behavior: https://github.com/w3c/csswg-drafts/issues/253#issuecomment-229367559

iank_: this only applies to forced breaks?

fantasai: this is expected to work on anything that has a margin

Rossen: ok, I'm hearing people are in favor for break L4

<TabAtkins> auto=discard on unforced breaks, keep on forced or start-of-container; discard=discard on all breaks; keep=keep on all breaks

Rossen: people can open issues against the proposal
... Objections?

RESOLUTION: Add margin-break to break L4

<TabAtkins> end-side break is always discard right now, regardless of break type; option to specify "keep" for those too.

<TabAtkins> <br dur=20min>

<heycam> scribenick: heycam

gap properties for block layout

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

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

fantasai: basically the request from authors is to get rid of the margin at the very top and bottom of an element
... so top before the first element, and bottom of the last element
... suggestion in one is to have a different box-sizing value of some kind
... other suggestion was can we have gaps to do this, add gaps to block layout
... I don't thinkI want to add gaps to block layout
... margin collapsing is its own special thing, fairly complicated
... but we can solve the problem by having a property that gets rid of the margins in the interior of an element
... I think tables do this automatically in quirks mode
... so this proposal is to add a property that would do this, and have an on/off switch, or do it for all items, or only in flow items, or something
... I want to see what people think about this, and whether to add it to the css-box-3 spec

TabAtkins: we already have a use case for it in css specs themselves
... notes, examples, etc. have a :first-child { margin-top: 0 } rule, which works unless you start the element with raw text
... so the necessity of making this actually robust seems fairly clear to me

<fantasai> https://github.com/w3c/csswg-drafts/issues/3068#issuecomment-417486499

fantasai: there's a rough proposal in this comment

<fantasai> margin-trim: none | in-flow | all

fantasai: up for bikeshedding, etc., but that's the starting point proposal

florian: that would work on elements that establish a BFC?

<Jia_An> join #tpac-chat

fantasai: yes, also reasonable to do on flex containers

TabAtkins: does it work on blocks that don't establish a BFC?

fantasai: yes

iank_: is this the same thing as the -webkit-margin-collapse?

TabAtkins: I don't know what those are

fantasai: it doesn't control collapsing, it switches to discarding

TabAtkins: might just be a terminology issue
... I don't know what those properties do

iank_: I believe one of the values nukes the whole margin collapsing result
... and just makes it go to 0

fantasai: this is different in that it keeps the margin of the element itself, it kills the margin of its first child

TabAtkins: the reason why this is important, rather than putting prop on first child, is when the first child is a text node
... if there's an element right after that you want to keep the margin
... either that or have the ability to target text node, which I would rather avoid

iank_: is there an example of that in an issue somewhere?

TabAtkins: I'll find one

<fantasai> <div>

<fantasai> some text

<fantasai> <p>more text</p>

<fantasai> </div>

<fantasai> <div>

florian: if you select the first child with a selector, it might be display none, which would do the wrong thing

<fantasai> <p>some text</p>

<fantasai> <p>more text</p>

<fantasai> </div>

eae: sounds like a good idea
... would like to see an example

fantasai: in this example, in either case, you don't want margins at the top and bottom of htethe div
... you just want the margin to go away because you've specified how much space you want between the border hwich is visisble, and hte text which is visible as 'padding'
... if you were trying to rely on hte :first-child selector, you could not do this correctly
... since it would select the <p>
... which is after some amount of text
... this is the example Tab pulled from the specs

TabAtkins: it ends up happening rarely in CSS, since it relies on the first text child not having links in it
... which is rare

Rossen: what spec is this going in?

fantasai: I would suggest css-box-3, which has no new features right now
... it's just what's in CSS 2 with updated terminoligy

<fantasai> https://www.w3.org/TR/css-box-3/

TabAtkins: I agree

Rossen: would margin-break go there too?

fantasai: there or fragmentation level 4
... which is where box-decoration-break is
... should xref from here for sure

Rossen: proposal is to add margin-trim with the values as above

TabAtkins: does the all value affect all floats touching the start edge of the container?
... want to make sure that's a reasonable thing to do

iank_: I'll have to check

Rossen: should be straightforward
... you're positioning your floats in the beginning of your container, and at that time you can decide to trim the margin
... you're not going to affect anything below you at this point
... the thing that will be a bit iffy is when you start pushing margins to the next line
... want to make sure you're not losing the margins, but these are impl details

fremy: does the all value also affect the margin at the bottom of a float?
... that seems more problematic
... you don't know when you place the float if you're going to be at the bottom of the element

fantasai: if you get to the bottom and the float is what it's causing it to be taller, you can back up to the border edge
... but you're right that is a trickier situation than the top

florian: if the margin of the float is pushing the bottom edge, and you can just remove it by changing the rest of the layout, it's fine
... but if removing it entirely, some lines could intrude where they couldn't before
... trim only the amount of the margin that is extending

iank_: does this eat just the first and last margin of the first element? or eat the whole collapsing margin?

fantasai: the whole collapsed margin

florian: the element, its first child, etc., as long as they're collapsing

Rossen: just to be sure, when we talk about the first float, we're talking about floats that are at the beginning? two or many adjacent?

florian: yes because your goal is to get visual alignment

Rossen: just want to be explicit since we keep talking about "the first"
... but with float you can have many

TabAtkins: all margins touching the start edge

RESOLUTION: Add the margin-trim property with values [ none | in-flow | all ] to css-box-3

florian: now that we have this and the thing we resolved on before the break, discarding margins around frag breaks, if we go back to Jen's use case
... the first para of first multicol column, we can address it with the thing we just created
... maybe we should also address it with the margin-break thing we were discussing

fantasai: I think I would lean towards having both of those properties controlling this particular break

florian: in the frag context, you probably want the same beahvioru after the first forced break, and at the beginning
... because there's no desire for the second chapter to look different from the first chapter

<TabAtkins> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/6305 <-- an example of the "zero out the margins of first/last child" strategy giving bad results

florian: the summary is that margin-break:discard, the value that causes the margin to be discarded causes it to be discarded not only after breaks, but also at the beginning of the first fragmentainer
... when you explicitly opt in to discarding things, not only discard around breaks, but also at the start

<jensimmons> and at the end?

florian: effectively you count the start as a forced break

fantasai: proposed resolution is that margin-break controls not just margins at fragmentation breaks, but also at the beginning and end of the fragmentation chain

Rossen: and this will be an additional requirement on margin-break?

fantasai: yes

Rossen: and this also applies at the end, not just the start

RESOLUTION: margin-break controls not just margins at fragmentation breaks, but also at the beginning and end of the fragmentation chain

<gregwhitworth> florian & fantasai: is there a reason that we NEED two seperate properties that are doing the same thing, just in two different contexts?

<fantasai> gregwhitworth, yes, you want to control behavior at breaks and behavior of a container separately

<fantasai> gregwhitworth, also one applies to the element's own margins and one applies to its contents :)

Improve column-fill and make it backward-compatible

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

<gregwhitworth> fantasai: we should chat during a break

<fantasai> kk :)

rachelandrew: this was recently raised by Morten Stenshorn, basically saying that we seem toh ave interop with chrome/edge/webkit column-fill:auto about balancing
... when block-size is unconstrained, balancing is forced
... it says Gecko doesn't force balancing in this case
... and Gecko appears to follow what's now in the spec
... I did some digging, the spec was changed in 2012 by Hakon, commented out some text, which led to this interop issue
... Morten is suggesting that we should fix the new spec and make it backwards compat, so column-fill:auto forces balancing if the block size is unconstrained

florian: another consideration here is I don't know whether we only do this for compat reasons, or if it's use case driven
... the issue was discovered by trying to fix one of the problems of what the interop impls do
... column-fill auto is supposed to say don't balance
... fill the first column as much as you can
... except it doesn't do that unless you contrain the height
... if you're in a grid, or if you have a min-height, maybe you do want to start not balancing and take the min-height into consideration
... height was not fixed to a number, but it is contrained is size
... so we're trying to patch our way out of that
... if we start with the Gecko behavior, filling as much as you can, then wrap, that solves that problem
... the fact that we have mostly interop, not full interop, we can decide

rachelandrew: I've run into the issue of wanting to have a min-height
... if you have a small amount of text, andi t's going to fragment into 3 columns, weithout being able to do the min-height thing, you get short bits of text
... but if you want to say make it at least this height
... that behavior is useful

florian: if you have the Gecko behavior as a starting point, you would use max-height instead
... when it reaches that it starts wrapping

rachelandrew: certainly a use case for that

dbaron: the issue you raised about grid reminds me of an issue we talked on last week's telcon
... seems like the same thing

fantasai: I think morten was suggesting it balances only when it's uncontrained
... if you have a min/max height that's a type of contraint

florian: it's not what they currently do
... if min/max/height are all auto, but you are contrained by being a grid item...?

fantasai: that's contrained

florian: that would work for me

fantasai: you could say if height is max-content or equivalent in behavior, then we consider that unconstrained
... and it balances

rachelandrew: that makes sense

florian: seems to me that would work, and not be too disruptive, I'm not convinced it's more useful
... are we trying to minimize the cost of changing impls?
... that plus web compat plus the idea that when you give something an auto height, it's supposed to fit it to content
... balancing as part of that kind of makes sense

fantasai: is also suggesting "don't ever balance" should get its own value
... the proposal is to accept Morten's suggestion that column-fill:auto does balance only when the height is uncosntrained, which emanse the beahviour is equivalent to min-content

florian: I think I agree, just confused about min vs max-content

fantasai: I think they're defined to be the same thing?

florian: this is one of hte cases where they might want to mean a different thing
... the min would reasonably be the wrapped size, and the max be the unwrapped size
... and it's the unwrapped size that makes sense here

dbaron: I think this is probably going in a direction that would be too vague
... so not worth getting to that detail
... if you want a proposal for switching, it needs to be clear about figuring out which case you're in
... the way you just defined it there are still ambiguous cases
... if you ahve a min/max height that probably isn't going to apply in your situation but might in another ?
... if you're in a block where you have this much content, and you have a max-height that's way down there, ...

fantasai: ??

dbaron: there are a pile of situations like this

rachelandrew: I'd be happy to have a go at writing these situations down

florian: just to be clear the reason we're going after the Gecko behavior is to minimize the cost of changing?
... or any other reason?

fantasai: it's called auto...

rachelandrew: I'll bring these back to the group after writing it up

fantasai: current proposal, if there's no min/max constraint, and the height is specified to be an automatic size that's equivalent to min-content

What happens to the mbp of the empty fragment created by a spanner being first-child of an element

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

rachelandrew: this may well be that it is covered, not convinced in the text
... when we resolved last time on 1072 about when the spanning element is a first child, we end up with an empty fragment, and the mbp ends up above it
... you get this strange issue, not specced, that if you have mbp its gets split across the columns
... I dont think it's behavior people want to expect
... would like it to be sure it doesn't happen

<Seinnd> whats going on in here? Who are you talking to heycam?

fantasai: I think the fragmentation spec doesn't allow breaks within padding
... it's not possible to split it across all 3 columns

rachelandrew: is this something that should be specced?

fantasai: I think it should be ok, you can write a test for it
... the top mbp should all be as one unit in a single column, the only reason to ever split is if you have a situation where the fragmentainer is too short

rachelandrew: so might not be an issue in the multicol spec

florian: if the spanner is a child of a thing with a top margin...
... in general it's a thing that makes sense if it's the first thing
... earlier today we added properties to opt out of this problem

rachelandrew: at the moment the behavior is not what anyone would want
... so probably can close this issue, I will check this

<myles_> is the a web platform test for this?

<fantasai> rachelandrew, https://www.w3.org/TR/css-break-3/#possible-breaks

RESOLUTION: close this issue no change

Margin collapsing does not make sense with column-spans

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

dbaron: I think there are a few different things going on
... I'm not sure which we've already solved
... one is that one thing, at the time, nothing said that the columns inside a multicol create BFCs
... the underlying question is can margins on column spans collapse
... 2 questions under that
... 1 is can the margin on a column span collapse with another column span right next to it
... that one, we could maybe argue about
... there are believable arguments on both sides
... other question is can a margin on a column span collapse the first thing in the multi col part in the col span (??)
... last time we looked at hte spec, it looked like it could collapse

florian: the spec is vague enough to read it that way

dbaron: the spec defines when margins can collapse, and nothing says they don't

<fantasai> I like Morten's proposal in https://github.com/w3c/csswg-drafts/issues/2203#issuecomment-431695940

dbaron: I think I would strongly like to define that the margins of column spans don't collapse with margins of things in the columns
... then there's the qn of can one column span's margin collapse with another
... there's a bunch of text in the issue I haven't looked at recently

fantasai: Morten posted a proposal, we don't have a strong definition of the multicol layout model in the spec
... he proposes a model for exactly how the different formatting contexts interact
... I think it makes a lot of sense. it gets us what dbaron said, but does that by defining the multicol container as being a BFC, and for it to contain column span and column containers, which are siblings, and they are laid out in a BFC, so the margins between spanners collapse
... but the spanners define their own BFCs so they don't collapse with things in the columns
... it's quite straightfrward and we should adopt it

florian: I believe we've previously resolved that does say hte margins between siblings spanners collapse, and that spanners and content in columns do not
... at least in examples

Rossen: we could defer this to later on after people have had a chance to read it

florian: or I suggest we resolve on spanners collapsing with each other, but not content in the column
... but not on the mechanism to achieve this
... which we can do later

RESOLUTION: margins between adjacent spanners do collapse

RESOLUTION: margins between spanners and any other non-spanning boxes do not collapse

Revisit text-align shorthanding text-align-last

github: https://github.com/w3c/csswg-draft/issues/3117

word-wrap/overflow-wrap: break-word should affect min-content

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

<astearns> (summary: https://github.com/w3c/csswg-drafts/issues/2682#issuecomment-431503466)

florian: we have 2 things. we have overflow-wrap:break-word
... which says that if the line is too long, apply line breaking, if it still doesn't fit, break anywhere
... it doesn't affect intrinsic size
... if you have text in a table cell that says if i'm too long wrap anywhere, because teh table cell is sized to the intrinsic size
... same thing in flex boxes and some other situations
... we should have had overflow-wrap:break-word affect intrinsic size
... Mozilla found it's not web compatible to do that
... WebKit an Chrome have that switch, which doesn't the same thing as overflow-wrap:break-word plus intrinsic sizing, but it's on the wrong property
... the word-wrap property
... so there is some web compat pressure, but not an overwhelming amount, since even tho we've been talking about this for a while, both Edge and Firefox have resisted implementing it
... given that overflow-wrap:break-word should have done the right thing, we should add a new value that does so
... overflow-wrap:anywhere
... we already have an anywhere value in another overflow property
... line-break:anywhere allows it all the time, overflow-wrap:anywhere is only if you need to break
... maybe that will be enough and the web will slowly learn to use that rather than the WebKit thing
... if it turns out not to be the case, we should have both, rather than just breaks the property that otherwise makes sense

eae: I agree with that, it makes sense to spec the right behavior and we would support that

florian: I propose we resolve on adding overflow-wrap:anywhere, we don't resolve on word-break:break-word, but only come back to that if web compat forces us to

RESOLUTION: Add an anywhere keyword to overflow-wrap

myles: are overflow-wrap / word-wrap no longer going to be synonyms?

Rossen: no they are

Revisit text-align shorthanding text-align-last

<Rossen> https://github.com/w3c/csswg-drafts/issues/3117

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

fantasai: we noticed nobody implemented text-align as a shorthand for text-align-last / text-align-all
... wanted to check in with the WG to see if they want to keep the spec as is
... original behaviour was they were separate properties, depending on the impl there were different relationship between the properties
... text-align-last only applied if text-align was justify, in IE
... but in Gecko text-align-last applies always
... the discussion that led up to the shorthand was to improve the ergonomics
... making it possible to set text-align-last on alignments other than justify
... but also making it less likely that you would accidentally have text-align-last setting your last line differently from the rest of your text once you've switched it to cernter or right

Rossen: you're tying it to IE's behavior?

fantasai: if we decide not to have shorthanding, it would be less error prone to have IE's behavior
... or we could decide to have the shorthanding

florian: the thing in the spec is based on WG resolutions
... there are subtleties when nesting bidi, diff languages
... the spec handles that, but nobody implements
... I think the spec is good but only if it's going to be implemented

dbaron: is there going to be a compat problem if we implement this in 2 years?
... given what exists today?

fantasai: if the text-align-last property is set earlier in the cascade than the text-align property
... I think when we made this decision, I think we did some kind of a nalysis and if people put both in, they put text-align-last second
... don't know how true that remains, since that was a while ago

florian: seems plausible that the -last one come after
... in the meanwhile there's no interop

dbaron: do all engines implement text-align-last?

fremy: yes

florian: yes but differently

dbaron: if chromium were willing to change, others would be happy to follow

<myles_> https://caniuse.com/#feat=css-text-align-last

dbaron: changing without chromium risks people writing content for chromium after the change

florian: impls aren't aligned with chromium today anyway

dbaron: hard to know if this will be a problem or not

myles: I'd like to voice support for the shorthanding approach

fantasai: for now we keep the spec as is?
... our goal is to get text level 3 CR by the end of the year
... which seems reasonable given the issues that are open, but this is one of them

myles: you could always defer it

fantasai: text-align-last is already implemented so not having a spec for it is a bit weird

florian: by reaching CR, we'll write tests and file bugs and they'll get fixed, so it should be all great

koji: how does text-align-last differ in impls?

fantasai: the spec says text-align-last is a longhand of text-align, but no impl of this right now
... currently they're independent properties
... the reln between the two varies per impl
... IE only honors text-align-last if text-align is justify, and Gecko always honors text-align-last

fremy: we fixed that in the latest version of Edge
... we didn't fix IE, we fixed Edge

Rossen: so Edge is closer to Firefox now

florian: there are more unimpl values on this property that will start to exhibit more different behaviors, shorthand vs non-shorthand would do very different things

Rossen: I think as impls start to come on line with additional support we'll discuss more of this

RESOLUTION: close this issue no change

Allow letter-spacing to have unitless values like line-height

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

fantasai: there are several related issues here
... one is this one, another is wrt text-decoration
... myles raised a similar issue on that spec
... several places relating to text where we currently allow lengths, ems are nice in these cases, you want letter-spacing or whatever to be font size relative
... but they don't inherit as lengths
... they inherit as absolute lengths rather than a font size fraction
... you probably also want to calc them together
... %s do fulfill this role in other places
... other option is to add another unit like frs, that kind of represent lengths
... so in this case you couldn't add 1px + 5%-of-font-size
... the problem with %s is that right now word-spacing uses them to mean the percetnage of the width of the space character
... it's also reasonable, and something that should inherit as a relative thing
... we have abs lengths, we have some kind of proportion of width of space, and proportion of font size, and maybe come up with some other things we'd want in terms of font metrics
... this is an open ended question about how to solve this value
... for letter-spacing, word-spacing, text-emphasis-offset, text-decoration-width, ...
... that would allow haing a proportion of the font size and make it inheritable as a proportion

florian: the place where we have it now is line-height, as a unitless number, which isn't great

jensimmons: is it too late to use ems ?

florian: yes since they will resolve down to an absolute value and inherit
... and it has been like that forever

<fantasai> Here's the text-underline-offset issue - https://github.com/w3c/csswg-drafts/issues/3118

florian: continuing with unitless numbers is bad because of Typed OM

myles: this solution sucks, but don't know of others

TabAtkins: don't use numbers for things that aren't numbers. for new units, mint a new unit suffix, otherwise calc has troubles

florian: is % used in these properties for word-spacing only? or in other places?

fantasai: so far the %s are only used in word-spacing. the only imp is Gecko, and usage is very minimal

florian: if we're not stuck on that, switching the meaning of %, and separately having a length units for the space width, that could be more consistent

jensimmons: so use % to mean % of the current font size;

florian: yeah

fantasai: we already have the infrastructure for calculating %s and having them inherit as %s

jensimmons: the other alternative is a new unit like em but different

fantasai: yes
... usability wise, %s would be ideal here
... would be great for line-height property, but might be a lost cause

jensimmons: would you suggest adding it to line-height?

fantasai: line-height is the only place where % calculates just like em

dbaron: there are other places. font-size
... in general, we can describe computed values the way we want to for %s, and we haven't done that mostly for length units

florian: I think I still stand by the proposal to use % for this, and retire the use of % in word-space from its current meaning, and introduce an sp unit to mean the width of a space

<dbaron> heycam: would it be weird that 'sp' would compute down to a length like 'ch' etc.?

<dbaron> florian/fantasai disagree over what 'sp' would do

fantasai: I could see use cases where you want either behavior
... tab-size is an example
... right now we use bare numbers for that
... might want to have the tab size remain constant throughout the document

florian: for tab size it's not sized in spaces, but spaces plus letter spacing
... for that example it's not going to be that unit anyway
... I was thinking sp would work like ch

<fantasai> https://developer.microsoft.com/en-us/microsoft-edge/platform/usage/css/word-spacing/

florian: so letter-spacing, word-spacing, text-decoration-width, text-underline-offset -- have a % in all of those

RESOLUTION: Add a % value to letter-spacing, word-spacing, text-decoration-width, text-underline-offset that is an inheritable proportion of font size

fantasai: for sp, word-spacing, the current behavior you do want it to inherit as a proportion
... e.g. maybe you want to double the word spacing, or collapse the word spacing to zero, or cut it in half
... and you want the proportion to inherit through
... so not sure if collapsing to an absolute length is useful
... so what we're missing here is the other type of unit

florian: we want another thing that behaves like %
... only for word-space?

fantasai: it might be useful for letter-spacing as well

florian: let's bike shed in the issue
... investigate a bit more

fantasai: confirm that Mozilla is ok with changing how they interpret %s on word-spacing?

dbaron: I'm ok with it
... it would be good if there were a resolution on what the syntax for the thing we've already implemented is
... at the time we change the existing syntax to something else

Text-spacing is too strict

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

myles: this is about text-spacing property, has a buynch of examples that control spacing between script changes on a single line
... desirable for mixed CJK and latin on a single line
... good typo style says if you have a bunch of ideographic characters then some latin words, between those two things should be a bit of extra space
... also things like because CJK punctuation tried to fit in a whole em block there's usually a lot of white space
... two punctuation characters next to each other is to push them together
... this is a good thing
... the concern we have is that there are different typographic design houses with different style guides
... and how much space to add between full width kana vs a latin character, etc.
... so different design studios have different rules abotu where they insert these spaces and how much to add
... we'd like to implement this property, but the definition is very strict
... lists which characters and how much space to add
... we understanding this came from jlreq, and that's a good starting place, but since this is up to typo conventions of the platform you're on, it would be good to looosen this for some wiggle room
... I've listd a few examples

florian: without going throguh the examples, at the conceptual level yes there are different opinions on spacing
... some of these topics we can find agreement on, others not
... for people who don't care, it doesn't matter
... for people who do care, they will only turn it on if it's predictable
... if they can't quite know what they'll get out of it, they'll do it manually

myles: this is a property for changing general behavior, I understand a particular publisher doesn't like the way a particular impl or the whole web does it, and they may impl it thsemelves
... but a ua should be able to improve the typography of the entire web

astearns: if you loosen things, you have an inconsistency between UAs, and authors are put in a bind
... the problem your'e pointing out means we need more properties to change the way we deal with spacing to hit those uses cases
... so a publishing house could say this variation is the one I want

myles: I don't think the proposal is contrary to that
... the thing that I'm aiming for is a way to have platform dependent spacing
... also having a way to have a specific well defined one, that's great too
... conceptually an auto value is distinct

florian: could we keep the existing auto value as that? [...]

koji: I think I'm with myles in general. I agree with florian that some people want exact typographic characteristics, but currently we dont have anyhting
... two things that people want. if we dont have either, better to start with a looser definition
... if they say they really want some particular behavior we can add some more strict definitions

florian: I think having an auto value would be nice for that general case of 'I want better typo'
... I'm concerned that this will cause compat problems
... that's when you end up with 1 line in one browser and 2 lines in another
... I wouldn't be opposed to an auto value, but that is a concern
... make the existing values fuzzy doesn't sound great

myles: i share concern about web compat
... there would need to be an investigation phase

florian: adding another value would be nice
... if we start changing in different browsers what they do that sounds scary

myles: the question about whether it should be the default value, I don't think we have information yet

florian: I suspect auto can't be default

fantasai: i would love it if auto did beautiful typo by default

drott: ...

florian: there are many things affected by this property. in the french context, you have a space before a column, a narrow non breakable space
... but not in markup
... this property allows you to inject the right kind of space
... you could give some flexibility to the browser, to choose 1/4em or 1/6em
... there's also things relating to collapsing white space
... e.g. in CJK punctuations
... the boundary between characters

drott: my question was how many values would we need
... to make it possible for the user to specify that
... within a run of the same script could be handle by opentype
... but how many additional ones would be needed

fantasai: the spec triggers the opentype features when the settings are set
... you might want to be able to control particular spacing operations, so we will use the right OT things, but it won't do them automatically
... trimming/spacing controls depends on context
... and it crosses text runs in the same language
... OT can't do this for us
... but we can use OT to do the glyph transformations or make full width be typset half width for example

myles: so you're asking how many combinations are required to do....?

drott: one was 1/4 em ...

florian: the existing property have 15 keywords
... not all combinations of them are valid

drott: for these 15, I'm trying to get an idea of how many lengths you'd need to specify
... just to gauge how many additional values you'd need

fantasai: if we're adding control over lengths, it would be in a separate property, so you could switch the behavior on and off without having to reset at every stage the length you want to set

florian: do we want to resolve on an auto value, which lets the UA do whatever it feels like?

fantasai: the initial value is normal
... happy with that or add an auto to do something

myles: is there interop on what normal means?

florian: yes, the initial value is what the web does today
... it's just not good typography
... for now, the auto value, isn't the default, since it's different from what UAs do

fantasai: if you want to try having it be the initial value ...

florian: that's going to break every good typographic website
... if you do it on top of them doing it manually
... maybe the spacing between latin and ideographic might be web compatible?'
... I suggest adding an auto and experimenting with it

fantasai: if they're experimenting to see with what the initial value can do, may as well do it for normal itself

myles: right now I think adding a new auto value is the best way to go

RESOLUTION: Add a new text-spacing:auto value, which is not the initial value.

florian: I encourage looking at what subset of auto behavior could move to the initial normal value

-- lunch break until 1pm --

(1:10pm)

<eae> ScribeNick: eae

flexbox

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

TabAtkins: Align content for a flexbox, you can do align content on a muiltline flexbox but a single line flexbox does not respond to align content
... this is beacuse we have a behavior where we stretch the line. Not super happy that we made that choice.
... the problem is there are cases where there are cases where we'd like to align for single line. specifically for things like baseline alignment.
... By the current definition we can't do anything about it, it is always stretching. We can't add in the fake margin to cause it to align

fantasai: the lines are stretched but the individual items arent, if you want ot baseline align you can't do that.

TabAtkins: only moves the line, not the items.

fantasai: The proposal is to take apply to single line flex containers, would allow more alignment options for flexboxes. Not a good reason it isn't allowed alreayd. Main concern is whether it is web compatible.

TabAtkins: use cases, baseline alignment, no reason why a single line shouldn't be allowed to align but a multi-line does.

florian: A similar use case is when making lines, requires wrapping for alignment to work. Declaring it to wrap has caused it tow rok, I don

't need wrapping but it isn't causing any problems. What's the problem with having to declare wrap.

TabAtkins: Not consistent with not wanting wrapping.

cbiesinger: Makes sense but please explain align items vs lines

jensimmons: the idea that long term that people have to know that wrpa is needed isn't ideal./ Better to have something that works for single line.

TabAtkins: compat risk is in two cases, single line row of flex containers and non-auto cross size. Shrinking to the sdize of the elements anyway.

<cbiesinger> s/baseline items/baseline align items/

fantasai: If you did self alignment which pushes everyhting to the top and everything is shrink wrapped and the flex container is taller, you then have extra space.

TabAtkins: Auto-height won't have the problem.

<fantasai> TabAtkins: Fixed height will

TabAtkins: A column flexbox whos columns are all fixed with would have changed behavior with this proposal
... Those are likely to be rare cases.

fantasai: We probably want to run a use counter on this before committing to it.

florian: Either that or chrome tires it and reports back.

astearns: Preferences?

cbiesinger: I'd rather do a use counter

TabAtkins: I'll open a crbug.

astearns: Collect data and report back?

TabAtkins: Yes

astearns: objections?
... We'll wait on data.

dbaron: Are we going to revisit once we have data?

astearns: yes

initial-letter

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

fantasai: Still open issues around better name for initial-letter property
... my favorite so far out of the proposed ones is initials-span

fremy: Why not drop caps?

florian: Also raised caps

astearns: Caps treatment?

fantasai: Not only caps

<fantasai> Also ideographic chars

astearns: We've spent a lot of time on this before without coming to an agreement, still an open issue. Preferences should be expressed on the issue.

spacing above initial letters

fantasai: Spacing above initial letters

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

dauwhe: We've been trying to sort our issues around spacing around initial letters.
... this gets somewhat complicated especially as it can have ascenders and marks extending outside. runs the risk of overlap. Something had to be done. The idea is to define boxes that helps us explain initial letter.
... One is visual box which is the bounding box without padidng and borders.
... you see at the bottom here and initial letter and the acsent mark extends outside.
... Initial letters have alignment requirementss

jensimmons: are these diagrams explanations of what we have in the spec or what you are proposing?

fantasai: What's the relationship between the top of intial letter and the top of where it's placed.
... If you have a paragraph and the second paragraph with an intial letter, has to ensure enough space between the two. We don't want content to overlap. We don't want to add too much space or it'll look bad.
... Intiial letter spec has a lot around how letter is aligned with other content in the paragraph and talks about how the bottom edge is aligned. Sometimes there is a decender, if there is a second line we don't want the decender to blend into the second line. Open questions around the top.
... Such as a border or the previous paragraph. Trying to answere the question about how to create space around the top,

dauwhe: We have the spacing box, no padidng and border, same as the visual box. It there is padding and border we have the union, taking the larger of the physical box and the border box, hopefully becauses clearer with some examples.
... We have four cases depeneing on padding border on the intial letter itself or the containing box.

florian: This is initial letters 3

dbaron: Can we not have margin collapsing?

iank_: That bit is pretty magical

florian: Isn't most of the dread around marging collapsing around margin collapsing through, which we're not doing here? Should be fine?

iank_: This introduces what looks like marging collapsing for inlines, which we do not do today

jensimmons: margin collapsing where you remove the ability for authors to use margins?

dbaron: The container is a block which cna have margin collapsing with many things already

dauwhe: Case 4a, no border or padding on initial letter or contianing block.

iank_: This is avoiding something earlier in the tree without a border?
... Say the previous box, nested five times in, has a border. Is it shifting down to avoid that border?

florian: This is collapsing the acsender with the margin

iank_: This is participating in margin collapsing?

fantasai: Yes, we're not going to get sensible results if we don't do that.
... We sent margins on our paragraphs to get enough space between our paragraphs. If there is acsent authors don't want to create more space if it fits within the declared margin.
... That is not what you typographically want.

florian: In the example currently on the screen you wouldn't be able to tell them apart.

fantasai: If you have sections which don't start on their own page, which happens often, and you're expecting three lines worth of spacing between secitons you want that to always be three lines worth, regardless of ascents on the intial cap. Also want to make sure it doesn't overlap with the previous section if it is taller, so needs to be able to extend the margin.

dbaron: My worry about this is that ir probably more than doubles the engineering complexity of initial letter. Adding margin collapsing, my gut feeling, is at least 2x the engineering cost.
... it's more stuff, nothing in initial letter was all that complicated, was a relatively simple feature up until now. Margin collapsing is very complicated and performance sensitive.

astearns: Is it possible to have a solution without margin collapsing solving the non-overlap case.

fantasai: Would require you as an author to know the distance between cap-height of glyph and glyph bounding box. Would work but be font specific.

dauwhe: ...and authors would have to do it for each letter

myles__: The acsent is sticking out of the box, why is this different from any other case where text is outside it's layout box?

fantasai: In this case we potentially have a lot of extra content outisde of the box. Could say that we don't care if we overlap the ink with the previous line.

florian: Latin scrips don't stack up a lot, other writing modes have cases where there is a lot of stacking and potentially more ink overlap
... lineheight often reserves space for this, in this case we align with the top of the bounding box so anything that reaches out reaches out far

myles__: My response to fantasis point, by default in css, we overflow and don't clip.

fantasai: By default we try not to have it be unreadable

TabAtkins: Can and should do it as a generic case where you never have acsents running into previous content. Would make initial letter simpler if it wasn't a part of initial letter

fantasai: If we were to do it for text in general we'd take a different approach.

florian: You don't want to do it in a small feature

fantasai: You're more likely to run into problems here, it's a bigger chunk of ink that would overlap than a normal line of text
... People don't tend to run into this for normal text and writing systems with more stacking tends to have a taller line height.

TabAtkins: Can we settle on a simpler model that pushes it down to avoid ink overlap?

fantasai: In that is likely to be less of a problem, have it overlap, and have authors fix it, rather than introduce extra spacing.

TabAtkins: I like it

astearns: Do we want to raise an issue around dealing with this problem in a generic case?

fantasai: Case of line boxes is a little different. With lines of actual text rhythm is important and the text is smaller. Not convinced that you'd want to have the same solution.

astearns: Is there anything with meaning in this proposal for initial letter?

fantasai: I think it's really a question of how, if the working group objects, it puts a strict constraint in what we can do.

iank_: I think people are going to need implementation experience to see how much work this would be. IF David is saying this will be complex that scares me.

florian: Should we put a note in the spec about that?
... Do we specify the behavior as described, overlap with preceding content, and also put in a note explaining the thing dauwhe presented and say "this is what we really want, if you want to implement go ahead"

iank_: The only thing that scares me there is that for some implementation this would be easy, for others hard.

astearns: Clarify in spec what would happen with insufficient margin.

fantasai: We would have to be clear that the proposal being considered changes behavior, not just adding a new feature (switch)

dbaron: I'd be curious if other implementors have same reaction as I as with regards to margin collapsing complexity. Another example, what if you have a float that is anchored within the block with the initial letter but before the initial letter, how does the collapse of the margin influence the tentative collapse of the float?

iank_: In our current layout implementation there is no way we could implement this sanely. In our new one, maybe. I agree, very complex

futhark: If you have an imaginary margin for the initial letter collapsing as if it was a block, if you change the font, you'd reflow and layout the text before we know the margin.

dbaron: In the presence of floats you don't know if the initial letter is at the top of the box as the float might push it lower. A lot of complexity

iank_: Super scary!

astearns: Sounds like we're not willing to make any changes to the current spec

fantasai: We need to agree on some desired behavior. what behavior we're going for.

myles__: My proposal would be to use the layout box of the glyph for the layout behavior and not consider the bounding box

astearns: What I remember you saying, don't move the content down.

fantasai: Would lead to more correct behavior in most cases, much more tangible than the alternative. If we went with the other approach, where acsenders take up space, authors will have to compensate with negative margin per glyph. We'll never be able to go back and fix it.

fremy: If you draw a border around it then everything needs to fit inside of it.

fantasai: inline blocks are layed out differently from inlines.

koji: if the glyph overflows the inline block that doesn't work

fantasai: cap-height is used for sizing and positing of the initial letter.
... only if cap-height is the alignment used
... Doesn't dictate the size of the initial letter box, includes ascent
... Initial letter box by default size to the bounding box. Glyph bounding box would have a lot of extra space around it.

koji: Davids proposal is very simlar to this

fantasai: Does not change how inline boxes background are is painted. Here the background area of that box coinsides with the gklyph bounding box

heycam: What is meant to happen when you don't have as many lines of text as the height of the intial letter?

fantasai: Defined in spec, clearing. The intial letter is part of the first line, everything below that is an exclusion area, everything will wrap around it, even if it is the next block. Like how floats work.

heycam: The exclusion area also includes the decenders?

fantasai: There isn't anything special about it. It's all below the first line, all exclusion area.

iank_: If you have two paragraphs and they're nested. what happens them?

fantasai: If one of them is a BFC then BFC might get narrower, not sure.
... The proposal on the table, if border or padding is used then the initial letter must be contained within the paragraph.

astearns: If the initial letters container has no border or padding then the glyph content above the alignment point for initial letter is not considered for layout?
... Objections?

dauwhe: In general, content area includes everything up to acsent, why did you phrase it as you did?

fantasai: Acsent might be too high for some fonts.

astearns: Second option, that fantasai was against. If we assume that the author would add enough space to avoid overlap that would require negative margin and by font specific.

fantasai: You could have more slack there, with the negative margin approach it's more strict, different amount of space per character, per font. The negative margin is specific to the font and the glyph, really bad.

astearns: dauwhe are you okay with default to overlap?

dauwhe: I'm totally fine with that, majority of use-cases would not be affected. Would only apply to a minority of content.

astearns: Any other objecitons?

RESOLUTION: If the initial letters container has no border or padding then the glyph content above the alignment point for initial letter is not considered for layout.

<myles__> ("alignment point" usually means "cap height")

RESOLUTION: Note to be added that the default behavior may change in the future.

<fantasai> the margin box of the initial letter must be inside the content box of its container

RESOLUTION: The margin box of the initial letter must be inside the content box of its container.

astearns: Any other initial letter topics?

fantasai: Going back to dbarons initial question. Be clear about whether it is created space between the top of the first line and the container. Whether the line box itself is increased or if a different kind of height is added?

<fantasai> dbaron points out it is detectable by how vertical-align: top behavies: if the item is aligned to the top of the first line or to the top of the raised cap

RESOLUTION: Add an example that shows default overlap

<fantasai> I think in Sydney we decided the top of the first line minus the raised cap, so suggest we resolve on that

<fantasai> proposed resolution: initial letter does not increase the height of the line box

astearns: what mechanism pushes everything down then?

fantasai: The initial letter itself is able to take up space. The initial letter box itself takes up space.

astearns: Does that satisfy your question David?

dbaron: Could you say what you proposed yourself again?

RESOLUTION: initial letter does not increase the height of the line box

fantasai: I think that's it for initial letter. We have other inline layout stuff.

overflow-3

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

florian: intrinsic sizing, currently the spec says that, in the block direction, is from the beginning of the content to the first forced or unforced break.
... That is problematic in that we don't know where the first unforced break is until layout
... Would suggest we change it to the first forced break. From start of content to first forced break.

dbaron: Two thoughts, one is that I hope the content that is after the first forced break contributors to the intrinsic size of something. Not sure what but should contribute to something.

florian: Only talking about the discard case now.

dbaron: For discard that seems reasonable, for some other cases min and max content would do different things. Min content would look at first break opportunity.

<fantasai> while max-content looks until first forced break

astearns: In cases where there is a fixed height then discard

florian: We should only conider forced breaks only for the purpose of intristic sizing, for other purposes the spec stays unchanged.

fantasai: I think this makes sense

RESOLUTION: intrinsic sizing only affected by forced breaks

<fantasai> it would be problematic I think for the 2nd fragmentainer and beyond, but for the first fragmentainer it's doable and reasonable

long block ellipsis strings

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

florian: I have a paragraph with lorem ipsum, the width is very narrow, we line clamp it and have ellipsis. What should happen when the ellipsis itself is longer than the line. One option is to consider the ellipsis unbreakable and have it stick out.
... The alternative, it is wrappable, and wraps up into the previous line.

myles__: How does the implemention know which line to start on?

florian: I feel it is an edge cases that will rarely happen, first option seems a lot easier.

TabAtkins: The wrapping behavior doesn't solve the problem of it being too wide

florian: Do we need to solve the porblem where it could wrap. I suggest we don't.
... Third way is leave it undefined, don't like it.

TabAtkins: Should be similar to have we do ellipsis now, remove enough characters until it fits

fantasai: This seems easier, don't have to care about the many ways of doing wrapping.
... I think the proposed resolution is to go with the first option

Proposed resolution: ellipsis is treated as unwrappable and will extend outside

TabAtkins: It's not great to overflow but at least you can see it.

astearns: Objections?

RESOLUTION: ellipsis string is non breakable

block-overflow, ::first-line, and ::first letter

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

florian: If you have max-lines 1 your ellipsis stirng will be on the first line, will it be styled by the first line style? If it is long enough to extend to start will it be styled by first-letter?

RESOLUTION: There is no interaction between ellipsis and first-line or first-letter

TabAtkins: When I've seen this sort of thing show up in printing it is not styled as drop caps or first line, distinct style

fremy: If you say max-lines 1 you don't need first-line in the first case?

Allowing (or not) alternate ellipsis behavior for block-overflow

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

florian: A part of the spec that says it's undefined. Gives two options. You layout your text and insert your ellipsis and remove content up until it fitst. Properly inserted text and you redo layout.
... Then there is a may. If you are time-pressed there is an easy way, inserted the same way as text overflow. Does not affect layout, paint time effect./
... Not great that spec allows two different behaviors.
... There is a next level of spec that allows other behaviors. Should we remove the may and make the correct behavior mandatory.
... Someone suggested that we might want to do an intermediate. You do the right thing when removing content but the insertion of the ellipsis is allowed to be a paint time effect.

astearns: If the ellipsis removes the entire last line would that change the line-height?

florian: Would retain a strut to preserve line height.

heycam: What happens with interactions like bidi reordering?

fantasai: I would imagine that the ellipsis would be bidi isolate

heycam: Also other interactions?

fantasai: If the ellipsis is rendered in a font that is taller than the line it is rendered onto the line would be taller which could cause that line to be droped

florian: That problem doesn't necessarily need solving.

heycam: Removal of glyphs, back up to however many glyphs needs to be dropped.

florian: How far you're allowed to back up, if you have hyphenation or in japanese where you can break anywhere. Line wrapping opportunities.

myles__: So not glyph based at all?

florian: Not half glyphs, at least one glyph, often more

astearns: proposal as I understand, remove content as required to ensure enough space, leave a strut as needed, and then add ellipsis at paint time?

heycam: Logically trim of pieces of the DOM that won't be rendered?

florian: You don't drop the line wherever, reuse the same logic as used for line breaking for fragmentation. Consider the last line to be shorter to allow for the ellipsis.

astearns: Would this be better for screenreaders?

florian: That is one case.

astearns: Any concerns about removing content and then paining ellipsis?
... Mats saied:

flow the block as if block-overflow doesn't exist

if it caused overflow, then shorten the available space to accommodate the size of an ellipsis and flow the last line again

repeat 2 until there is no additional overflow or the line is empty

during painting, render an ellipsis in the reserved space in the last line (same as a text-overflow ellipsis)

florian: Repeat is potentially needed to reflow. Proper layout for removal.

astearns: One additional thing: If the line is empty, preserve the height.
... Any concerns?

heycam: I don't like the searching and dropping bits to adjust the line height.

florian: tempted to say yes, haven't thought about it in detail.
... Would look a bit odd if you had a japanese word with ruby that has been dropped but still have a large gap above the line
... I do think we should make it narrower, don't want large gaps. Not common but would look really bad.
... Not taking to CR anytime soon, edit it in and then revisit once speced?

RESOLUTION: Edit in Mats proposed solution from issue 2905.

<inserted> Scribe: fantasai

Math on Web Pages joint Meeting

<glazou> Arno Goudol

arno: I used to be in CSSWG many years ago, but no longer with that employer so here representing myself
... Wanted to talk about opportunities to make representing math on the Web better

daniel: I'm co-chair of Math on Web Pages community group\

<arnog_> hello!

pkra: I'm an independent consultant working with STEM publishers

<dauwhe> s/?:/pkra:/

<glazou> Peter Kreutzberger

<VolkerS> Volker Sorge (MathJax)

VolkerS: I'm here in my role as 1/2 of mathjax development team. I'm mainly on teh a11y side and parsing, but know a bit about the css

arno: We only have 25min before the break, so we're going to try
... Don't expect to solve the world's problems, but wnat to talk to you about some of the challenges we face in using HTMl+CSS to present equations on the Web
... There's lots of solutions that do that, not that it's unsolveable, but what we think is worth exploring is how we can make the authoring of this content easier using CSS
... Using a lot of workarounds and hacky solutions
... Have some solutions of improvements to make it easier for this type of content.
... Also want to look at improvments that are not just beneficial for authroing mathml content
... But some of these solutions could also benefit others
... Talking about someof the things improtant to us, and solutions to those problems
... First of all we care a lot about quality of the rendering
... Our goal is toa chieve the same quality on the Web as on print
... no reason why you can't have the same precision in layout and same typographical quality on teh web as you have in print
... We recognize that getting there will take some time, but want to shoot for
... One issue we have, a lot of layouts we have to do in css for math, is that we have to use a lot of inline styles
... Improved a lot so we don't ahve to do as much compuation on the client side to do positioning
... CSS added a lot of additional features which gives us more control to do layout
... But still many cases where we have to bake in inline styles
... We'd prefer not to do that
... ... content on the fly
... If you modify the content, vertical alignment, inline styles ahve to be recalculated
... This is acceptable if you're authoring a library or tool, but if we want the authoring to be more accessible
... to be able to author math content with a text editor, need to get past this
... so need a solution for that
... would also like solutions that improve the stability of the layout
... So if you make some changes to the content, would like to be able to do taht without modifying the rest of the layout, having to recalculate everthing and re--inject inline styles into the markup
... Math fonts is a sort of emerging technology
... For those not familiary, they're an OpenType standard that lets you put inside a font side metadata that will allow adapting mathematical glyphs, e.g. stretched fences and integrals
... It's great to have that part of the font file
... Today, oftentimes you have to carry them alongside a hard code knowledge of specific fonts. which is terible
... This isn't great because user can't just change the font
... So having metric information about the layout, very promising technology
... so that's an overview of where we're looking for improvements
... Some of thec hallenges we have
... Not an exhaustive list
... Some of them we can sort of work around, but it's ugly
... Focusing on ones where the workarounds are the ugliest
... And try to have improvmenets that benefit beyond just math
... One example is stretchy fences
... HEre's an example, it's geneology
... Wwhen you have a geneological tree, you connect the parents and offspring with long brackets
... This is somethign very common in math, that's used for group equations
... matrices
... And other cases
... Point of this is to remind you taht this is something that's uesed beyond math cases
... doing stretchy fences is possible today, but requires a lot of trickeries and is very fragile

<jensimmons> We (dauwhe, florian and I) were just saying this yesterday — it’d be awesome to have a ‘stretchy’ open backet

arno: have to composite multiple glyphs together and hope they dont' break as the layout changes, zoom level is increased, etc.
... Wouldn't it be great if there was a simpler way to do this with CSS?
... Especially to use the stretchy bracket as the border of a box.
... and have the renderign engine take care of that

Myles: Idea that you just described, stretchy... would you expect that the browser would create the form of the stretchy glyph itself or pick out glyphs from a font?

arno: Ideally, information from the font would be used
... in traditional typography, e.g. serif font and sans-serif font are different
... Unicode has codepoitns for this
... So ideal world, we'd use the info from the font
... Moving on to another challenge
... baseline alignment
... It's one of thsoe where it's not an unsovled problem, there are ways to do them, but all of them involve inline styles and positioning and vertical align and all unpleasant
... Depens on teh content, and if the content changes, have to change the values for the line
... Want to move away from inline styles as much as possible
... Needed for lining up equations
... But also needed for lining up fonts and icon text

arno shows example from his doc

arno: Don't have one specific solution in mind
... There are some imperfect solutions today, and some discussed e.g. in css-inline-3
... Having that incorporated into inline layout model would be fantastic
... We'd love to make ourselves available if you have more questions
... IF that's the direction that you'd like to go

TabAtkins: In the example the baseline is being taken from some descendant. It's not an arbitrary position.
... If that's the case, I think the implementation shouldn't be too unreasonable, because we already drill down into descendants to find a baseline
... So just need to be able to have a child say "I'm the baseline for this container" and the container to look fofr that child
... This other example doesn't have such a case, the baseline is totally arbitrary place

heycam: I've always thought that there shoudl be some way for external svg elements should be able to declare where their baseline is

fantasai: There were proposals in the past to be able to specify where the baselin of ann atomic baseline is. (Was deferred to later, not prioritized)

koji: If there is another example that doesn't have text of the same font size, how do you align it?

arno: If the size changes, would still use the baseline. Would still want to align along that axis.

koji: so not really aligned to that red line (running along the alphabetic baseline)

arno: There's another axis for the exponent, e.g. aetc.

emilio: Webkit and Gecko have MathML implementatiosn where you could do this?

arno: We want improvements so you could express things with html and css only
... Built in support is great, but ...

emilio: Why?
... Why not use MathML which was explicitly designed to do this?

arno: There are some use cases where MathML doesn't work.
... For example, some software does interactive editing.
... To be able to do the layout with CSS + HTML is better

emilio: I don't know why you wouldn't be able to mutate MathML

astearns: There's some cases here that aren't MathML, like the genelological case

florian: Another case where MathML isn't ideal, the type of MathML needed here is the presentational version, but for a11y the semantic version is better
... coudl render to HTML+CSS
... Also presentational MathML is less interoperably and robustly implemented, so use a different technology
... store the semantics differently and render to HTML+CSS

arno: So let me go quickly to another example of things that we're looking for
... Here is enclosures, which is a way to annotate a mathml equation
... This is something that is often used to highlight ? oequation
... This is also defined in MathML, but would also want to use it in other context
... want to use those constructs in other contexts
... These are currently difficult to impelemnt using CSS + HTML
... Need to do the alyout twice, calculate the size of the bounding box that you want to decorate
... We hope it to be easier

TabAtkins: I woudl think that a lot of this can be done in the Paint API
... We've done a lot of work with Google teams about shaping around content, and would love to get more use cases
... Talk to iank next to you :)

myles: When you render to HTML+CSS, presumably teh result is positioned... how?
... is it abspos?

arno: No
... Software I worked on -- there are others out there -- mathdive, as much as possible the layout and positioning of glyp[hs is deferred to the layout engine
... So horizontal positioning is done by the HTML. I just have to do some adjustments, esp for stacking, of the boxes
... Used to be much more difficult to do
... Other implementations that used abspos for glyphs, but I thik that things have progressed enough
... Now looking at the remaining gaps

myles: But you don't use grid/flexbox?

arno: Some implementations are
... Theyr'e looking into it
... A good opportunity to simplify some of the layotu, especially for stacked constructs
... baseline alignment
... but in terms fo making it able to ahve fewer inline styles, it's a good way
... Few more things to talk about
... Roots, a special case of enclosures
... stretch fences
... Accents and decoratiosn are a realted topic
... A few other topics
... More on teh list, less straightforward or more specific in their use cases
... So watned to focus on these
... Wanted engagemnt with this community, how can we address these things
... Use some features in CSS, or some features you're working on for next level of the modules
... Happy to be soundign board, provid use cases
... So taht's what we're looking for

astearns: Is this document public?

arno: can make it public

florian: Please output to HTML or PDF and send to www-archive@w3.org
... more long-lived than google docs

astearns: Thanks, can work on some or all of these issues
... for now, let's work on break

<br type=tea end=4pm>

Joint meeting with WPT

<TabAtkins> ScribeNick: TabAtkins

zcorpan: A year or so ago this group adopted a testing policy for some specs, including OM and OM-View
... And also specs in CR, tha tnormative changes should be coupled with wpt
... I want to udnerstand how this policy is working in practice, and if there are any blockers to using this for spec editors
... If there should be someone to work on testing specifically, or if it should be editors' responsibility.
... What is the process, and what do we want it to be? What, if anything, is blocking no-test-no-merge policy for CSS specs?

florian: I think what happen is what we feared would happen. Some editors, like myself, who are responsible for a few specs but not th eoverall health of CSS, were able to stick to that policy. But Tab and Elika can't do that without dropping the amount of work they do on specs, and we don't want them to do that.
... And nobody's picked up the tests to go with their changes.
... So, it's not just the three of us in this WG that do specs and tests and such. But the policy as a group, is indeed lbocked by the fact that there's not enough people writing tests to go along with the edits.
... For some editros it's reasonable to drop spec output to increase test output, but not for other editors. I don't know how to solve that.
... I'll keep doing my part, but... I don't think it's possible for the WG unless we have more people to do just tests to compensate.

Chris_Lilley: We need more people to do edits, is the thing.

fremy: Same point - I disagree we should say there should be spec-specific people, and I disagree that Tab and Elika should be reducing their output to write tests. We have a big group, we have a lot of ideas. We have big companies here, we should make sure we staff the testing group specifically.
... If we don't have neough people to even do the editting work, obviously we don't have enough for the testing work.

rbyers: Of these changes that don't have tests, are there impl changes happening too?
... In Chromium, devs need to land tests at the same time. Does that apply here?

florian: A success here is the Contain spec. As an editor I focused on writing a test for every change I made, but we didn't have tests at the beginning. Igalia implemented, and wrote tests as they went; I also commissioned tests from Gerard.

dbaron: Another risk with not having tests is the impl doesn't notice the change.
... Because we don't have a great mechanism for making sure changes get into impls... there's still a problem with noticing the change.

foolip: Are bugs being filed in the issue trackers to track changes?

fantasai: Not systematically done or tracked right now. We have a label for changes that need tests, but not one to track things that need bugs.

Chris_Lilley: When I was doing Fonts 3, we were already well-tested and most things were imlpemented, so I was able to keep track of everything. But across all specs, they're at much different levels of implementation.

foolip: What's also been happening is the spec change is made, then we have tests written before the change that contradict them.
... But the big risk is changes that don't get noticed by anyone.

gsnedders: And the spec is then not implemented as written, because the change was never made in impls and no test was written for it, and that isn't noticed.

foolip: All the changes being made, what would happen if changes *were* blocked on tests.
... Where's the pressure to make changes in the first place?

fantasai: It comes from people giving feedback on specs. Some are implementors, who can write a test immediately because they're implementing, or sometimes they jus tnotice something but aren't working on it, and won't get back to it for a year.
... Some are filed by users of the tech that have issues with how it behaves. Some are filed by WG members.
... So some of these have incentive to write a test, others don't.

foolip: So either they care enough to share a burden, or they don't. In HTML, random person writes a PR, then we require them to write a test.

cbiesinger: Sometimes people in general will just file an issue that something needs to be clarified. It may not be clear what the right behavior even is, so it might be low-priority. By the time we get around to fixing the issue, the reporter might not even be around.

florian: We have many cases of people qualified to point out a problem, but not qualified to fix it.
... So it's we as a group that need to make the fix, and make the test.

jensimmons: I'd have a big problem with this group deciding that only people who have the time and skill to write tests can contribute to CSS. Taht's not a route we want to go down.
... I do think we need more test-writing. I've had conversations; there are many people who'd like to write tests, but there's no clear way to get involved.
... And even when they do get wind of how to get involved, the tools are complex and there's lots of blockers that make people give up.
... There are people in this group, like Greg and Rachel, that have said that is an important thing they want to work on.
... I think there are hundreds of people who want to contribute, with an easier on-ramp.

<florian> +1000 to what Jen said

fremy: I think to answer your question, the answer is "backlog". There's already more work pouring in everyday than this group can work on.
... We as a group still care about fixing the spec, because it's wrong.

foolip: For any big project, obviously there's a big backlog. Given the resources available, is it more effective to just work on the spec, or ensure that spec and test work happen together.
... Hypothesis I put forth last year is that if you do the test work, people will notice something has changed, and implementors will follow along faster.
... That's not proven, but if that's true, whatever amount of resources are available, doing this work together makes more sense than doing just the spec work.

zcorpan: I think the experience with HTML is that it does result in impl changes more consistently.
... Before this policy we'd sometimes have spec changes, not write tests, then revert the change because nobody implemented it.
... I think this proposal helps with that issue.

gregwhitworth: I still stand by what we said last year - we all have wpt.fyi externally, so we can see the changes.
... To Jen's point, I've set up some mentorships with folks; there's a lo tmore ramp-up to writing good tests than I think we realize. There's a lot of webdevs out there, but when we narrow it down, the number who have the time is quite small, but still something we should pursue.

<Rossen> a?

gregwhitworth: I'll grab some of the people that might be relevant and talk about this.
... I don't want us to focus so hard on the suites themselves. Is it worth spending 80% of time on the 20% of effort to perfect the testsuite?
... I don't want elika to spend so much time writing up tests just because she's the most knowledgeable.
... I bet we have about 70 people in this room. Some of us are tied to more implementors. So instead just think about a *single* test that fails.
... Putting together a *single* new test for a change that would fail in non-conforming browers would still be a ton of help.

foolip: And there's also the problem of big new features, where it's too formative to be worth writing a comprehensive suite.

TabAtkins: I think I can commit to writing a single test per change. Just as a signaling mechanism tha something has changed, that seems sufficiently high-value and low-effort that I think I can gate myself that way without a significant slowdown.

heycam: I think I agree that making tests at same time as changes is ideal. Given resource constraints of the group, wonder if it's more important to track things that do need tests; seems that could be mostly automated.
... So when we have free time, or external people look at something, or a new implementor comes in...

astearns: We do have a "Needs Tests" tag that we give to issues.

heycam: That's tied to GH issues; not all changes are tied to GH issues, particularly early.

dbaron: There's been a lot of talk about resource constraints for editors.
... Think about that in a different way.
... One of the things we end up doing a lot is we end up revisiting changes, discussing multiple times, because they're not implemented and now we have a compat constraint.
... There are reasons why, when we started using tests in software dev, even tho we spent more time writing tests, I think people agree that we overall moved faster.
... I think HTML editors found the same thing. Even tho you're stopping to do this extra work, you can accomplish more, because it makes the work more likely to stick.
... It also sometimes causes you to think more about the change, thinki about other cases.
... But mostly it makes it less likely we have to revisit things later.

<tantek> +💯what dbaron is saying

dbaron: So I think the "one test per change" is good.

florian: Another bottleneck is test reviews.
... I have 13 open PRs right now, oldest back from April.
... I can write as many tests as I want, but I can't review my own tests.

foolip: What do you do when tests get stuck?

florian: Poke, but often the best people to poke are Tab and Elika, and we're back to the bandwidth problem. ^_^

foolip: This is an issue for many groups.
... I don't think it's a tooling problem.
... Say we add a role for someone to go thru Needs Tests label, or to write together with spec changes. Unless that's blocking, and keeps blocking, any changes you make will be eroded.

florian: Another thing about test reviews is that they seem trivial, but they're not.
... Ask the editor, it's probably not hard. Ask someone else, it's not. Reviewing one test might be a 20-hour task, as you have to read the spec first.

dirk: For TRansforms there are some PRs I've put up, and they still need review.
... For editors of the spec, could we lift the requirement that someone else needs to do a review?

florian: I think it's good to have reviews, but if you're blocked...

<rachelandrew> having dug through all the legacy multicol tests recently, and inlined them in the spec, very grateful for the work TabAtkins did adding that functionality to Bikeshed.

<dbaron> I'm in favor of allowing editors to land tests without review.

gregwhitworth: And they'll get reviewed by the implementors when they review the test later anyway, when they see that tehey're failing it.

foolip: We could tweak wpt-pr-bot to not require reviews from certain people...

<gregwhitworth> https://www.irccloud.com/pastebin/LvLPxBCS/

<myles_> scribenick: myles_

<scribe> ScribeNick: myles_

<AmeliaBR> The problem with editors writing their own tests without review is that sometimes they are testing what they *meant* the spec to say, not what it currently says. Can end up with requirements that only exist in the tests, not the spec.

scroll linked animations

<jensimmons> sure

<smfr> https://wicg.github.io/scroll-animations/

majidvp: i want to keep this at a high level. Background: it's on WICG. we have in Chrome an experimental implementation. I want to inspire people who are experts on overflo to look at the spec. I hop we can turn the experimental implementatino to be shippable int he near term. It's useful for web authors in general.
... here are some demos

<majidvp> demo linke: https://scrolltimeline-playground.glitch.me/

<foolip> on the previous topic, I filed https://github.com/web-platform-tests/wpt-pr-bot/issues/47

majidvp: the prorposal for scroll linked animation was in 2014 by dino. since then there has been interest from Moilla and Chrome. Moved to WICG. Take a scroller and the scroll range to the scroler and map it to time. Then you feed it into the animation system. Then the animation is driven by the user scroll. It's declarative, so browsers can run it on their fast path. The effect can remain in sync with the scroller. Our implementation, we have a subset

that's implemented. THe simplest example is parallax.

majidvp: it's synced with the scrollbar.
... it's implemented with 2d transform. Most people listen to rAF and look at the scroll position and change style. But our example runs on the compositor thread, so it's fast.
... here's another example: you have something that trnslates ont eh horizontal axis as the user scrolls.
... it is very simple
... similar, here's another example: you swipe, and the bottom and top has some sort of fade and scale, and it's in sync with the scroll
... let's look at the simplest implementation.
... how doe sit work?
... let's start with the animation. Our implementation was done for animation worklet, so ignore the first 2 words (About worklet animation and passthrough)
... so it's like a worklet.
... the keyframe and scroll timeline is interesting. Usually it's the documetn time, but this is a scroll timeline! you're mapping a scroll source (mhy scroller) and the full scroll range to a time, with is 1000 ms. So scroll offset 0 to max is time offset 0 - 1000

so i have a duration from my keyframe which is 1000, and the animation translates from y=0 to some negative value.

majidvp: as I scroll from 0 to maximum, the background translates 20% of the amount, giving you parallax
... doesn't have to run on the main thread, no event handlers, and it's simple and declarative
... a scroll linked animations, in the spec, has a CSS syntax. we haven't implemented that, so i don't have any feedback. the basic feeling is that it work spretty well
... questions???
... we noticed during implementation that the spec hasn't through about writing modes and directions
... normally when you chagne writing ;mode or directions, the scroller chagnes. normally the horizontal scroller goes from left to right, but if the writing mode is RTL, the scroller is reversed.
... the physical scroll offset (Scroll left and scroll top) when you switch the scroll direction, they stay the same. So my scroll righ would be the maximum value and as i scroll it goes to 90

**0

majidvp: the scroll timelines should be logical. So when you chagne the scroll direction to be RTL, you want the effect to match that
... the current time should match the scroll origin, not the physical scroll offset
... the spec doesn't talk about that but I have an issue
... as you chage writing direction, the timeline will match that
... please look at the spec and find other issues!
... another implication: say you want to translate something

jensimmons: question: are you proposing a CSS spec that works with CSS & HTML only, or are you proposing new CSS which requries JavaScript?

majidvp: the spec has syntax so it works for CSS only, so you could, according to the spec, there's enough syntax for CSS. We haven't implemented it yet.

<fantasai> ACTION fantasai review the scroll-animations spec

<trackbot> Created ACTION-874 - Review the scroll-animations spec [on Elika Etemad - due 2018-10-29].

jensimmons: I think it would be great to make sure that use cases are easy to tdo in CSS-only. More complicated thigns can require javascript

majidvp: yes. I'll show you the syntax.

jensimmons: getting rid of the JS is the most exciting part.

<tantek> +💯 jensimmons "would be great to make sure that use cases are easy to do in CSS-only"

majidvp: the psec says: what you want to di is to link your animation to a particular scroller. Here's an example ::presents to the class::
... the interesting bit is the animation timeline which is specifying that this is a timeline that is based on the scrol loffset of a certain element. It has vertical inline, and the two values at the end are the start and en offset, so you can be linked to a portion of the scrollbar instead of the whole scrollbar. we haven't implemented it. Please give feedback. e.g. how do you guarantee it only selects a certain element, what do you do when that

element goes away. When we implemented the Javascrip, we found corner cases

jensimmons: does it require pixels or do ems work?

majidvp: ems work

heycam: some people think / say that the use cases that scroll linked animations can solve are good enough that we don't need the animation worklet stuff. you ahve experience with both. what are your feelings?

majidvp: we haven't done the integration of a scroll timeline into web aniations. The demops use anbimation worklett.
... many effects can be achieved without animation workklet. But animation worklet is more expressive. You have a state and conditions adn you ahve the power of script.
... it gives you power to do the other 20% of animation like pull to refresh.
... it needs the scroll offset and the state (direction of the scroll and the last state that was action)
... also scroll to action. I understand we want to enable declarative stuff, but there are a whole bunch of effects that are not possible there. They sholud be possible.
... the other thing is scroll-linked that's stateless, do we want to enable animation work and touch other interactive effects that you're currently only able to do on main thread. Like multi-touch effect. Drag and drop, throw ssomething away, physical effects. We want to be declarative, but it doesn't scale well. Animation worklet lets you do scrolling effects, the 20% that's stateful, but also lets you do more sophisticated like scroll, gesture, etc.

They arec ompilmentary,

jensimmons: it would be great if there was a way the spec mandated that websites obey the user's prefers-reduced-motion setting. If devs (or their bosses) wants to override the user's preference, they can't.

majidvp: if we want to do that, it's better suited to web animations. Here, we're just adding a new timeline. The timing model lives inside web animations.

florian: prefers-reduced-motion is not prefers-no-motion. Subtle animations should be able to remain. Turning everything off is too big of a hammer

jensimmons: i dont' knwo abou the details. let's not bikeshed right now. CSSWG needs to enforce prefers-reduced-motion in any way we can

majidvp: interesting: a scroll timeline should respect the writing mode.
... however, the second part is most animations that people write today are transform animations. Transform is a physical property. So we're mapping logical input to physical result. It doesn't work well. An interesting idea would be to have a scroll timeline that works in logical direction for transform. Maybe transforms should have a version that is logical.
... transform-inline and transform-block rather than transform-x and transform-y
... just ideas.

fantasai: for the CSS property, we try not to have positional propertesi. Instead we want definition syntax, and rely on types to organize syntax rather htan ordering. you probably dont' need to pick the scroll by id selector if you default to the nearest scroll container. Then scroll can be a keyword. Or maybe it takes a time range arugment
... when we have percentages that allows you to deal (or lengths) when you know exactly where an item is, like a scroll animation to trigger when it comes into view, we want to encourage peopel to maek resizable webpages. Using fixed lengths is not a good way to do ti. Maybe we can use the scroll-snap properties. "this is what it means to be 'at that element'" and then that becomes a time point along the scroller, whcih has a length along with it, but

the author doesn't provide the lenght, we calcualte it for them. Then the author doesn't need to use fixed layout or a bunch of JS calculations

majidvp: yep.
... the problem of depending on the size of the scroller, and percents curerntly are relative to an elemnt, some effect depends on the percentage of one, and some depends on offset. So simliar syntax to snap points are okay

fantasai: you can reuse those properties, you just have to reference the element. "the offset i'm interested in is when 'this lement' is in its snap psotion, whether or not snapping is turned on'

majidvp: another issue is sometimes because this API maps a scroll range to a tiem range, the time range could be selected by the author, if you specify you rtime range to be small, you can have quantization error. 1000px maps to 1ms, most browsers will lose precision if you're not careful
... maybe there is a solution to reduce the foot gun

fantasai: if you don't privde a time range, how do you do ti?

majidvp: by default the timeline takes the laegest time range of the associated animation. So animations have duration, it sues that. It's a good thing.

fantasai: yes.
... encouraging tpeople to use default arguments .... put a note in the spec warning authors not to use too-small time ranges

majidvp: i'm not an editor fo a spec, so i'm going to try to talk to editors and encourage them to move it to CSSWG so more people look at it
... i also want to ship a subset of this. now it has CSS and WebIDL. A practical subset of it. it could be useful.

astearns: when you say "ship" what do you mean

majidvp: righ tnow you can do an origin trial for animation worklet. M71 - M73. The earliest time we could ship something is that.
... as we implement we find corner casfes, and I'm hoping there are good solutions. So I need more eyes on this.
... this proposal has been started since 2014
... i really hope to get some traction. We have the only experimental implementation. Firefox have some patches but they haven't landed. Original proposal from dino had an implementation in Safari
... So the only real one I know of is ours

smfr: webkit's implementation your'e talking about is "scroll triggers" but we removed the code because we didn't advance it in a while. We like this proposal. I want to explore "scroll triggered animations" because it's interesting

majidvp: there are 3 types of scroll animations. 1) moves as you scroll, in sync 2) triggered by scroll, when you reach a scroll offset, but the animatino is time-based. The sepc has both but we removed scroll triggered animations. Motivation: scroll linked animations are the ones you want ont he fast path. The one that is exposed to the main thread is asynchronous and it's best effort, so it's difficult to get in-sync scrolling. For triggers, as you hit a

point, you start something that's time based. That could be done on the fast path. Your start point could be delaeyd. it's not the end of the world. for those use cases, it's fine to have a scroll event and then trigger the animation. That's why the editors remnoved taht in favor of the first kind. I'm not opposed to fitting that model in here. Just wasn't as important performance-wise

smfr: the biggest challeng for scroll triggered animations is how to describe them declaratively

gregwhitworth: we are intrested. We have an engineer reviewing this.
... by "We" i mean "edge"

heycam: for us, brian and [Botond] would liek toget back to this and push it forward again. it's not in our short-term, it's in our backlog, but with renewed interested form other parties, it would move up

majidvp: i'm very excited there is interest.
... thanks.

fantasai: it's a great idea, would be happy to have it in the CSSWG

smfr: i wnat to draw attention to the proposal for logical transforms. Big chagne. Transforms 3 to figure it out????

astearns: woop woop
... CSS-UI

fantasai: yes please :)

CSS UI

<fantasai> scribenick: fantasai

Topic; Dark Mode

Dark Mode

fremy: Last time introduced MQ for others ot detect dark mode
... When we introduced, seemed highly requested and useful idea
... But I've been working on form controls lately, and one of the big issues is they are not stylable and not interoperable
... Obviously we want to make things better
... But it's annoying that you can detect dark mode, but can't switch controls from light to dark
... Most platforms these days have native dark theme conrols
... when I was reviewing spec for scroll bars, one property we introduced was proposing to intoduce dark scrollbars
... was thinking maybe we should generalize to form controls in general
... to decide to have dark form control

<tantek> reference: https://drafts.csswg.org/css-scrollbars-1/#valdef-scrollbar-color-dark

fremy: My roposal is to have just like scrollbars,
... dark controls vs light controls
... Wanted to see if other people were thinking about this
... thought it was a good or bad idea

smfr: Definitely thinking about how authros can tell browser that they have designed for light mode or dark mode
... Form controls is part of that, but also focus and other things
... Want a way for author to tell us if they desigend for light mode, dark mode, don't care
... Also some UAs may want to automatically invert colors on the web page

smfr; we do this in our email application

smfr: So do we allow authors to request dark mode? Allow authors to optin somehow
... Use a media query?
... There are some conflicting desires
... We would like authors to say "I have designed this page with light and dark modes in mind..."

<tantek> "Allow authors to optin somehow" sounds like a media query

smfr: Maybe a CSS property, color-scheme: light || dark
...

<AmeliaBR> Many browsers have different form styling defaults iff the author has not set key styles. So in that case, I would expect the browser to use their dark UI versions. But I really like the option of being able to set (as an author) appearance: dark

smfr: We're not sure that web authors should be able to have a mixture of light and dark controls on the same page

<AmeliaBR> (Wouldn't necessarily be for the entire page, could be for a section.)

smfr: Also acknowledge that pages can have iframes, don't want to propoagate into iframes
... So proposal for a property
... inherited, overlays with appearance, tells us which theme to use for form conrols
... Another version is a meta tag

florian: no, no no

smfr: And we have to figure out how the opt-out works
... How does author say "please don't darkify my colors"
... "please don't invert my content"

fremy: think automatic inversion is not something we're concerned about
... Maybe it's a meta info in the email header
... For websites, I really like the css property and I like the way you phrased it
... List all the themes you support, if you support dark thing and os is in dark mode, you'll get dark controls/select/etc
... ...
... Seems reasonable/sensible to me
... If you want to work on, or I should work on?
... Don't want to duplicate work
... I know we're not discussing on scrollbars, but they have similar issues

smfr: For scrollbar property, we have heuristics that look at body background color
... If author has a preference on theme, we'd use that for scroll bars. Can override with scrollbar-color property

krit: What about themes that are between light and dark

fremy: That's why you list all the themse you support
... Maybe have a list in preference order?
...

Rossen: High contrast mode, dark mode gives you dark color. High contrast feature specifically targets ensuring sufficient contrast between foreground /bg
... Because of that presmise, we'll go to extent of changing all bg and foreground colors to match OS scheme
... In order to allow web authors to take things in their hand, we have a high-contrast-adjust: none property
... This element and its subtree will be in control of the user and they can specify whatever colors they need
... It's something that was requested, to get OS colors
... Say I can do a good job of using them where I need to
... Why I was discussing env() spec to see where this is going
... Ideally expose some variables that will reflect bg and foreground colors at least
... And then control parts could internally be using environment variable color as initial value
... And then we don't have to specify the override properties
... Much rather go down that way for all of these controls
...

smfr: Our use case is trying to preserve internt of the author
... yours is match the os

dbaron: Some of what Rossen said sounded very familiar in that we had system colors in CSS2 in 1998
... THe ones in CSS2 were copied from the Windows API at the time
... I made some proposals in 2002 to extend the set to work better on othe rplatforms
... But some of what you're asking for is something we already have and decided to deprecate
... So it makes me wonder what we're going to do better this time and why we want a new version of the whole thing
... I've also been thinking a little bit about form controls since I know in the past, Gecko had done more to try to honor whatever the user's native theme actually was
... The end result was that users with dark themes got web pages that didn't work very well
... This might be a way out of that, but not clear to me how light/dark choices interact with user's choice of them
... and whether there are good APIs for this
... if OS APIs moving towards being able to tell light vs dark, or if moving towards no choice other than light or dark...
... Not clear to me what the OSes are doing

smfr: For us it's just light/dark
... be interested to know other OSes

dbaron: Desktop Linux has a very powerful theming system, so can get just about anything

astearns: Do you have something we can move towards,
... accessing specific colors to match OS colors seems out of scope for this discussion
... Anything more to discuss about the author specifying how to handle light and dark and letting UA to deal with that info

fremy: I'm OK
... I think we have enough to move on from now
... Will come up with a more concrete proposal
... Wanted to see if there was other interest, agreement on way forward

dbaron: One of my concerns is making sure that other browsers have the ability to use the ncessary OS APIs to get this information out
... Whatever you depend on should be on documented exposed APIs on Windows and Mac

fremy: for us it's a requirement, so yes

astearns: anything else?
... OK, close this topic

florian: can't find zcorpan, so gotta find a different topic than appearnace/fieldset

Defining Outline

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

florian: Outline property is quite loosely defined, and to a certain degree intentionally so
... Ther'es a design reason and a process reason
... Design reason is because outline is used for focus, and we didn't wnat to constrain too much how UAs draw their focus rings
... On the other hand, outlines are used for decorative purposes all the time, and not having inteorp there is an issue
... Process reason was that for L3, we were trying to wrap up and didn't have a clear proposal or interop
... So question is, now in L4, do we want to define this more precisely?
... Should we pick a behavior and have everyon conform to it?
... Or are we still thinking we don't want to constrain the outline.
... Wanted to see where the WG stands on these types of issues
... Should we try to constrain and find inteorp, or leave open to experimentation by UAs?

smfr: Special behavior in webkit only happens on auto style

florian: That could be a reasonable compromise
... let auto do whatever, then gradually narrow down behavior of the rest
... Specific issue triggering this discussion was raised by heycam
... Seems like you have some interest in increased interop?

heycam: Even if we didn't get to a world with mandated behavior, would be helpful to have more guidelines on which boxes contribute to the outline rectangle

florian: Was contacted by person from Google who works on this

Aleks: I'm implementing this, so that's my interest. My take on outline, I talked to fantasai about them
... There was a difference for us between focus outline and css outline, and that was annoying
... Would be nice to define whether focus and css outlines are the same or different, and if different then define css outline strictly for interop
...
... When you're tabbing through, you get the "tabbing outline"

florian: If you put 'outline: auto', do you get the same outline as the focus outline or something else?

Aleks: that's a weird edge case in my opinion

florian: current suggestion is to allow UA to do whatever for 'auto' style outline, and otherwise tighten up what the outline is

<tantek> outline was always intended to represent the focus outline, period. and if there's been a divergence it's because implementations were lacking, likely unintentionally.

florian: So I think that's a direction we can look into

fieldset

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

zcorpan: A few weeks ago I did a project to specify rendering model of fieldset
... There's active implementaiton in gecko and chromium
... Remaining issue is finding a way for web developers to turn off the rendering model that fieldset employes
... There was a proposal to use -webkit-appearance for that, but would be open to other ideas

florian: I remember fantasai filed a whole pile of issues against your spec
... Have they all been resolved?

<florian> fantasai: you got rid of the legend property?

<florian> fantasai: I don't think there should be one

<florian> zcorpan: we can look into that

TabAtkins: We don't have opinions against or for 'appearance'. Do have an opinion on whether it should work on random other elements
... If there's a case of "this is how it's turned on to fieldset/legend, and here's how to turn it off" that's fine

zcorpan: Enabling on random elements was more of a side effect, not a goal
... I'm also working on appearance property, and don't think it's a perfect fit for fieldset
... It doesn't affect layout on other elements, just changes what's rendered, typically
... So would be open to probably adding new properties for opting out to the layout model for fieldset

<florian> fantasai: I don't want to add to new properties that opt into a new useful layout model, but only work on one element

<florian> fantasai: if the goal is to only have a switch that work on certain HTML element, appearance seems appropriate.

<florian> fantasai: if we make a new property, it should be generally appicable

<florian> florian: +1

zcorpan: So do we want it to be generally applicable, or do we want it to be limited?

florian: The somewhat quirky version that's applicable to HTML is not nice to generalize as-is
... IIRC it does strange things to broders

fantasai: But isn't that what makes it special? Otherwise just use flexbox/gid

zcorpan: There are various interesting layout effects, but main thing is placement over the border

florian: clipping border is kinda weird

fantasai: Seems reasonable to me

fremy: Introducing a lot of stuff for this, and MS and Google agree that we don't want to add a generalizable thing.
... agree with fantasai, that if we're just trying to define for fieldset it's too much

<florian> fremy: I'm not even sure we need a way to turn it off, because why would you use fieldset if not for that rendering

<florian> fantasai: because fieldset has specific and useful semantics in form controls that you may very well want, but that doesn't mean you want that particular rendering model

<fremy> minuting is great with zcorpan additions

astearns: Sounds like y'all should have a hallway conversation or something, 'cuz we're done for today.

Meeting closed.

<pkra> Follow up to the meeting with the MathOnWeb CG. A simplified version of the document we presented is available on the GitHub wiki of the CG repository at https://github.com/w3c/mathonwebpages/wiki/%5BCSS-TF%5D-TPAC-2018-preparations

<pkra> Thanks again to the CSSWG for the kind invitation and good meeting!

<astearns> Trackbot, end meeting

This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/aboxhall/emilio/
Succeeded: s/aboxhall/rossen/
Succeeded: s/syled/styled/
Succeeded: s/interested in/volunteering to/
Succeeded: s/truncated/always truncated/
Succeeded: s/only allow/only allow an optional 'keep' for/
Succeeded: s/taht/that/
Succeeded: s/is visible/is visible as 'padding'/
Succeeded: s/margin-break/margin-break:discard/
Succeeded: s/... Morten/fantasai: /
Succeeded: s/size, it's/size that's/
Succeeded: s/that/that, it makes sense to spec the right behavior and we would support that/
Succeeded: s/WH/WG/
Succeeded: s/Edge/IE/
Succeeded: s/baseline/align/
Succeeded: s/??/jensimmons/
FAILED: s/baseline items/baseline align items/
Succeeded: s/remove/use/
Succeeded: s/???/myles__ /
Succeeded: s/proposals add but don't change behavior/the proposal being considered changes behavior, not just adding a new feature (switch)/
Succeeded: s/???/heycam/
Succeeded: s/florian/fantasai/
Succeeded: s/height/high/
Succeeded: s/YOu/You/
Succeeded: s/MathML/Math on Web Pages/
Succeeded: s/MathML/Math on Web Pages/
Succeeded: s/?/pkra/
FAILED: s/?:/pkra:/
Succeeded: s/??/VolkerS/
Succeeded: s/emtrci/metric/
Succeeded: s/tretchy ences/stretchy fences/
Succeeded: s/tohers/others/
Succeeded: s/layotu/layout/
Succeeded: s/no change was made for it/no test was written for it, and that isn't noticed/
Succeeded: s/wpt-review-bot/wpt-pr-bot/
Succeeded: i/ScribeNick: TabAtkins/Topic: Joint meeting with WPT
Succeeded: i/Math on Web Pages joint Meeting/Scribe: fantasai
Succeeded: i/accessibility mappings/Scribe: gregwhitworth
Succeeded: s/can use/can reuse/
Succeeded: s/[trails off]/put a note in the spec warning authors not to use too-small time ranges/
Succeeded: s/sue/use/
Succeeded: s/inaudible/Botond/
Succeeded: s/idea/idea, would be happy to have it in the CSSWG/
Succeeded: s/browser shave/browsers have/
Default Present: tantek, Peter, Krautzberger, Daniel, Marques
Present: tantek Peter Krautzberger Daniel Marques skk eae jensimmons astearns glazou myles Rossen heycam dauwhe koji smfr myles_ philipwalton lajava rachelandrew TabAtkins emilio surma mstange futhark ericwilligers melanierichards drott bkardell_ Vlad krit rego florian newton majidvp cbiesinger xfq Irfan dbaron
Found Scribe: gregwhitworth
Inferring ScribeNick: gregwhitworth
Found ScribeNick: heycam
Found ScribeNick: eae
Found Scribe: fantasai
Inferring ScribeNick: fantasai
Found ScribeNick: TabAtkins
Found ScribeNick: myles_
Found ScribeNick: myles_
Found ScribeNick: fantasai
Scribes: gregwhitworth, fantasai
ScribeNicks: gregwhitworth, heycam, eae, fantasai, TabAtkins, myles_

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 22 Oct 2018
People with action items: 

WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)