<tantek> scribenick:tantek

TabAtkins: (shows tabatkins.github.iospecs/css-shadow-parts/

<astearns> https://tabatkins.github.io/specs/css-shadow-parts/

TabAtkins: (shows https://tabatkins.github.io/specs/css-shadow-parts/)

deep combinator was too powerful

works for transfering single values

terrible for outside of that

in particular one element, e.g. heading part of your warning message

you have to expose a lot of custom properties

theoretically all 300+ CSS props

then xfer each one by one

worse if you try to style pseudo

s

huge combinatorial problem

variables fall down quickly if you want to allow ...

this proposal https://tabatkins.github.io/specs/css-shadow-parts that Shane and I wrote up

for letting authors expose an entire element from their shadow dom to other parts of the page

this would go into the dom spec

we'd add some piece

s

(shows feature in spec)

important part in CSS, two new pseudo-elements that appear on any shadow host

::part() and ::theme()

(summarizes proposal from link)

do allow some pseudo-classes on them

but can't depend on anything to do with the DOM tree, e.g. no ::part():first-child

one aspect of vars that is availabe to preserve is that they do allow you to target things further down in the tree

useful in practice for authors right now

::part() is one level, ::theme() is what this component chooses to expose plus what all its subcomponents choose to expose

TabAtkins: In general ::part is better to do, helps with encapsulation. But ::theme helps you do what variables do.

(shows example of a custom button)

TabAtkins: there are some suggestions for more features, e.g. elements may want to censor

e.g. give theme ability to exclude certain elements from being exposed

ready for FPWD

fantasai: ED?

TabAtkins: comments?
... I'd like to pursue this in the public repo, right now it is just in my personal github
... at the very least as an ED
... also ready for FPWD if group is ready for it

glazou: part is always exposed?
... but you need to expose it outside the shadow DOM?

TabAtkins: yes that is exactly the point

glazou: I understand the point, I'm puzzled that we need to add an attribute for that
... part serves same purpose as class

TabAtkins: but we don't want to expose arbitrary class(es)

astearns: we don't want to expose arbitrary class(es), why don't we say component say these classes that are allowed to style
... and then the selectors styling in the component could look like the selectors outside

glazou: I have another suggestion, give a list of attribute selectors, name and value

plinss: but then you're ...

glazou: unless ...

plinss: what's in the ... is not just the ... not just in the shadow tree, but something that is deliberately exposed
... and then propagate these things up to the root
... this is basically what I wanted but just wanted pseudos...
... can we do structure?

TabAtkins: no

plinss: it flattens the entire shadow tree?

TabAtkins: yes, because exposing the entire structure exposes too many details

plinss: ... so I'm find with that

fantasai: I don't understand the use case for theme

TabAtkins: vars right now can be used to target an arbitrary depth down the shadow tree
... same thing that theme does
... part gives you only one level
... not currently a way to block theme like vars

fantasai: why?

TabAtkins: e.g. to theme custom buttons regardless of where they are
... just by setting vars

fantasai: second question is ...
... just wondering if ryosuke has read your draft

TabAtkins: he has but doesn't like theme

fremy: why can we just not create a namespace of classes that we expose?

instead of a new attribute

classes that start with ...

TabAtkins: possible, but class has traditionally be treated as a user (author) space thing, and we don't introspect on the internals of class name

fremy: it seems like a bad idea to have to use part and class

TabAtkins: class for internal styling, use part for how external world can see you

dbaron: I'd be in favor of this moving to ED space

the structure thing that plinss brought up could use some more examination

I can imagine different things that all expose the same piece instead

and you'd want to expose that instead of having to mirror the names

TabAtkins: yes that is possible, trying to hit the minimal case right now

can carefully expose more structure

plinss: stack of custom elements?

TabAtkins: each pseudo can expose its parts

no particular reason author needs to know your buttons are x-button vs button

dbaron: one other point, I find the part and theme names confusing

TabAtkins: which part? (lol)

dbaron: the fact that they are very similar, but have very different names that don't tie them together

TabAtkins: like because "theme" doesn't indicate it is like "part"?

dauwhe: I certainly support ED on this

we have this problem in the ebook world

<gregwhitworth> maybe ::parts()

publishers creating styles

need users to override parts of it but not all

we run into lots of problems with the cascade

trying to allow user to control P but not H

TabAtkins: ... inside shadow vs outside shadow

(explains how to solve it)

<fantasai> +1 to ED

Rossen: so I heard a few in favor of moving to ED to begin with

Bert: I have a q

not sure I understand how you expose part

<gregwhitworth> we need a QA person ;)

do you need pseudo at all?

TabAtkins: the button already has children, the may or may not be exposed

you can take the actual dom children and pull them into the shadow dom

and two, letting you use the descendant combinator implies you can use child combinator

Bert: no at same level

TabAtkins: I would find that a little bit ...

big one is that child and descendant combinators already match the actual children

Bert: namespace issue ok

TabAtkins: pseudo gives you a clear context abou what you're matching

<TabAtkins> Because of how the cascade works for rules originating inside the shadow vs outside the shadow, you can prevent the outer page from manipulating particular properties on an element by just setting them from inside the shadow dom.

plinss: one thing I like about pseudo approach, in the ExtWeb approach, you can use ... to explain pseudo ...
... I can explain that that was a ... element all along

TabAtkins: our inputs are implemented with shadow dom
... any objection to ED space?

Rossen: does anyone?
... doesn't seem like it. go ahead and move it. resolved

RESOLUTION: move CSS Shadow Parts to WG ED space

Rossen: ... ?

TabAtkins: ... will go into ... and ... will go into ...

Rossen: let's go back to ...

<TabAtkins> The part attr will go into the DOM spec; the pseudo-elements will go into the SCoping spec.

Rossen: review of TTML
... we have Nigel joining us on the call

Review of TTML

<fantasai> ScribeNick: fantasai

Rossen: Asked a few weeks ago to review TTML current WD

<Rossen> https://lists.w3.org/Archives/Public/www-style/2017Jul/0007.html

Rossen: Some back and forth over email
... Provided feedback, first time by dbaron, 2nd time by Florian

Florian: Feedback I wrote wasn't sent to TTML, sent to us to decide if it was my position our position
... We haven't resolved on that officially

Rossen: Would ou want to summarize?

Florian: Roughly very similar to what dbaron saidhalf a year earlier
... Didn't review anything other than style and layout, but for this part
... You ahve a system that is very similar to CSS, but isn't CSS
... Some attributes take the same syntax, but have different semantics
... Some take a superset, some take a subset, some overlap in both ways
... We could do a mapping, but different semantics is a problem
... E.g. 'line-height' defines the height of the line box in CSS, in your case it defines the spacing between baselines which is similar but not quite the same
... Other times you and us solved the same problem in parallel and came up with a different solution
... e.g. your alignment properties are different from ours

<tantek> See also dbaron's review https://lists.w3.org/Archives/Public/www-style/2016Nov/0106.html

Florian: You can't really map to CSS, you can try but because of these differences, will come out wrong
... Implementing TTML will be completely different from implementing CSS
... Browsers have a CSS engine
... If not compatible with CSS, unlikely to work out
... There's a rough mapping in an informative part, but it's not really going to work
... I understand the history of starting from XSL:FO, but that's dead for client-side on the Web
... Out of context, it might be a good technology, but in the context of the Web it's hard to fit

<Zakim> nigel_, you wanted to ask which cases have different semantics for line height

nigel_: Fair summary
... Interested in specifics of line height issue

<nigel_> https://www.w3.org/wiki/TTML/CSSRequirements

nigel_: One thing, you mentioned an informal document that brings out correspondences to CSS
... here's a link
... we did quite a bit of this analysis
... we used dbaron's and your feedback (which we found)
... absolutely right that the syntax is different
... for us, compatibility with previous versions is important; breaking would be a problem for us
... a lot of the target devices are not browsers
... but there is a growing recognition that being able to render with CSS would be a good idea
... So there has to be a syntactic mapping, but wrt semantic mapping...
... We discussed with TAG recently, and hey had useful view that we should describe the mapping into CSS for this to be useful implemented
... Question of whether this mapping should be normative, unsure how much real world difference it makes
... Other recommendation from TAG was that if there were styling requirements
... then it would be really helpful if there were CSS equivalents
... If things that we need in subtitle / caption word aren't in CSS, we ask CSSWG to add them
... this makes it easier to implment with a CSS backing
... If we can get to any detail, even offline, want to know e.g. differences in line height semantics

myles_: I guess, we've looked into this a bit and our findings align with Florian's findings

myles: Our conclusions are in line with Florian's conclusions

myles_: We would be hesitant to implement if not aligned with CSS

(Myles represents Apple, works on WebKit)

Florian: Wasn't on TAG, don't know what they said
... But rather than have you define things and us define things in parallel
... better to define in terms of CSS, and if something's missing, then we add it
... Wrt subtle differences, determining how subtle secondary, if they are normatively defined independently
... then there will be differences, and even small differences are problems in deployment
... Differences between different and broken are subjective
... If the syntax layer needs to be different, this is a minor annoyance but fine
... But in terms of semantics, don't redefine separately what's already defined in CSS
... file bugs against us to add things
... Could go through long list of details on every property
... I took line-height as an example
... but given you have normative prose, there are bound to be differences

ack

nigel: I understan where you're coming from
... From TTML WG PoV, it's not always so obvious how to add things to CSS

<Zakim> nigel, you wanted to mention the spec timing issues

nigel: but also there is pressure to get a new version of TTML out, and if we had to wait for CSS, wouldn't be able to satisfy our community
... TTML2 could be seen as a req document, and align with CSS later
... I've not heard any dissent from view that these reqs need to be met
... So assuming there is a requirement, we do need to support them in subtitles and captions world
... As soon as we have access to CSS definitions we can add them back in
... There is time, actually
... We're in WD at the moment, the review endes in September
... we wouldn't be in CR until after TPAC
... If there is an opportunity to get some featues specified in CSS, could contribute to that in some way
... then there is time to fill some of these gaps
... most important ones that would be useful
... filling line gap
... text-resentation for ideographic scripts
... ruby
... font ???
... these would be useful

<Rossen> https://www.w3.org/wiki/TTML/CSSRequirements#disparity

<Rossen> https://www.w3.org/wiki/TTML/CSSRequirements

astearns: Not time to define new things in CSS, but time to review list of places where you're unsure if there's concordance
... I saw some things, e.g. where we do have the feature
... Would be nice to have semantics map, and syntax if possible
... Would be good to have someone from group review list to check for actual gap

Florian: We have a bit of precedence with this, with EPUB
... Where they couldn't quite wait for us
... This is overall not a story that ends veyr well
... Similarly to your situation,not all EPUB readers are browsers, but kinda
... When you ask to support things that are not CSS but kinda it's problematic
... Originally they asked us for stuff, and if we didn't deliver fast enough they tried to define their own thing
... But realized that doesn't work, so now are planning to just bug us to prioritize and fix things
... Wrt differences we were discussiong
... I wonder if it's worth doing, if we don't go all the way in
... If we can bring it to the point that browsers can implement
... Then it's worth
... But if it's not possible to implement in browsers, then making it less different is maybe not so useful

nigel: wrt displaying in browsers, they do

<Zakim> nigel, you wanted to talk about browser display

nigel: TTML has a profile IMSC
... one of the implementations is a JS implementation with CSS
... clearly there's a desire to present subtitles in browser
... I imagine same would be true for TTML2
... Experience of editor of IMSC had with creating imsc.js was that he ad to work around limitations of CSS quite a bit
... e.g. putting each character in its own span to tweak its position
... Some easier things to fix, like box-decoration-break
... possibly just understaning layout options in CSS better would help
... As you guessed, ppl will want to map to browsers better
... browsers natively doing is maybe ???
... Making decision based on whether browsers want to natively present TTML is maybe a step too far
... just about whether to present TTML at all, e.g. using JS libraries

jet: It seems like we're a bit torn in that browser venders see it as obvious to render TTML using our existing layout engines
... but the consumers of TTML might want custom layout in the future
... e.g. never render markup in front of a face, where browsers wouldn't even know where to start
... Need to innovate in ways beyond just render text in a fixed location
... Want to align on things like text rendering
... but polyfill things that we wouldn't know where to start dealing with

nigel: avoiding faces is done by author positioning
... but sounds really cool
... Hvae a question to you,
... TAG said it would really be good if CSS would support requirements
... Is that something you concur with?

Rossen: So long as the feature requirements that are specific to CSS come to us fit to overall model of what we're doing
... as long as they are coming as requests we will definitely review and consider
... for those that don't, not much we can do

Florian: For those already in the spec, you have a solution
... But for us what would be most useful is not to tell us to support the solutionof the TTML group, but to take a step back and tell us the use case
... Maybe the way you solved it is a perfect fit for CSS, maybe it's not but another approach would work
... Question is does the thing you care about fit into CSS?
... If so then maybe it will influence what we do in CSS, either importing wholesale or adjusting the capabilities otherwise
... Having only the solution without understanding the use case would not help very much.

nigel: One more thing to add... sounds like there are some actions
... Whatever those actions are, we've set aside time at TPAC
... best day for us would be Friday
... set aside time to invite to join us
... to hopefully come to some resolutions
... will send a formal invitation
... could also do THursday if preferred

Rossen: We have some requests pending for TPAC, I believe thursday is mostly gonna be fore CSS Houdini meetings, so that's likely to fil lthe day
... Haven't settled on thursday or friday, so dpeends on that
... Already have some a11y and few more groups that want to meet with us
... But def send an email

nigel to lurk for a bit

CSS Break

<TabAtkins> ScribeNick: TabAtkins

fantasai: We had a request from Nigel to add a value for the box-decoratio-break property. CAn you explain?

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

<github-bot> fantasai, Sorry, I don't understand that command. Try 'help'.

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

nigel: IMagine you're displaying subtitles, and for a11y you want to put a high-contrast background behind the text. Not on the whole <p>, just behind the lines.
... You don't want the bg to be tightly wrapped to the text edges - you want it to extend slightly out for readability
... But you cant predict the linebreaks.
... That's okay righ tnow with b-d-b: clone
... But then what if you have a span in the middle of the text with a different color bg.
... And the break falls in the middle of that other span.
... You want the span's bg to be what extends; you want to use padding to display that.
... So the most relevant bg color to "extend" is from the innermost element at the break, not the element that sets b-d-b.
... fantasai asked a good question.
... Should it be "most nested" or "most nested thing that *counts", paraphrasing.

fantasai: I think we have this problem generally with fragmentation.
... At the break, you want to ahve a little bit of extra padding with the bg beneath it.
... It's possible that maybe we can solve this by just saying "add this amount of padding at the break".
... Whether that solves this is, do you need borders too? Or just backgrounds.
... Like a border around the inline that only closes if it's the innermost nested border?
... Seems weird, I guess not.

nigel: I think for border-radius you want [...]?

fantasai: If both have b-r; normally we'd just slice and get the green and black backgrounds overlapping eachother on a clean break.
... If only the green gets a border-radius, you'll see the black background peeking out from under the green.
... That's a problem.

Rossen: I think this is in conjuction with the line-padding property in TTML, right?

nigel: Yeah.

<dbaron> a general 'break-padding' property sounds like it could be useful...

Rossen: box decoration and fragmentation, you're talking about linebreaking, nto general box breaking

TabAtkins: It can be about boxes too.

<astearns> I think it would be helpful to have a diagram in https://www.w3.org/TR/ttml2/#style-attribute-inlineAreaBreak that showed a rendering using each value for cases where there's a difference

Rossen: Sure, but that's not his requirement.
... Also something we don't have in CSS is line-padding that extends in every break.

<fantasai> dbaron, yeah, that's what I was thinking. But it doesn't solve the border-radius case he was describing

nigel: Line padding was introduced to IMSC when border-radius wasn't available in TTML; at that point the only styling you could do was bg-color and get a square box.
... Now with b-r it's gotten more complicated, and probably need to extend it a little further than just the line-padding semantic, to include the other bg effects (or things that otherwise affect the background)
... Your point about targeting line areas specifcially is well made.
... If there was a way to say "for each line in this <p>, apply this styling" that would be really helpful, but that doesn't seem to exist yet.

fantasai: I think it would be relatively easy to describe as only things that work are background and things on the box, not background.

<Rossen> Here's nigel's example https://github.com/w3c/imsc-tests/blob/master/imsc1/png/linePadding2/0.000000.png

fantasai: Once inheritance applies it's hard.
... We have this problem with ::first-line; it's a mess, lots of bugs, spec isn't precise enough despite our efforts.
... But if it's just about "background here, put a b-r on it", it's not too hard.
... Not high prio to do in browsers, but wouldn't be too hard.

iank_: We don't have an architecture that can support that (styling lines individually). It's several years away.

Rossen: The existing model of line boxes in most impls, certainly in Edge, is not easily extdendable to support this. Not impossible, but it would be quite hard.
... Tho this is a valid use-case and feature.

fantasai: What's line-padding?

Rossen: Imagine you have a span - I posted on of Nigel's examples - that adds bg to the current inline. And the span breaks. You can put padding on the span - you'll get padding at the start and end of the span. If it fits on one line, great; the bg will extend a little past the text.
... But if the text breaks in the middle, you have some padding on start of first fragment and end of last fragment, but all other broken edges have no padding.
... line-padding feature adds padding to every break-edge.
... Basically to the linebox itself.
... if the linebox has background, it extends.

fantasai: The linebox is wider than that actually, but I get what you're saying.
... Taht makes sense, and I see how adding border-radius would be tricky.

nigel: Doing just the inline-padding isn't the only place we want to do something with line areas.
... Another feature, fill-line-gap, says "draw background areas between lines".
... Hard now, because character heights are UA-dependent.
... So can't specify a padding-top/bottom that correctly fills in the space between lines.

fantasai: Question I have - you ahve a line of text with some line-spacing, say 1.5. You're seeing there's a bg below the text, and a .5em gap between the lines.
... When asking to fill the linegap, you're filling that .5em space, what happens at the top and the bottom? Do you add .25em at each? So each line gets .25em of bg above and below? Or just between the lines?

nigel: At the moment we don't say.

fantasai: Ok, thiat's a really important question to answer in CSS.
... Second question, if two lines have different lengths, what happens?

<Rossen> line-box-margin: collapse

nigel: Probably we take whatever answer is most convenient.
... But as far as I know you can't set a padding value, because you can't calculate it...

fantasai: We should specify that...

TabAtkins: Why's it hard? Just the diff between font-size and line-height, right?

fantasai: Not quite - the bg area isnt' the size of the line height box of the inline that's used for layout. The area around an inline - in 2.1 there were two ways to calculate the area, based on font metrics, and impls might do different things.

Rossen: This is going a bit off topic, can we bring it back to b-d-b?

<nigel> [css-inline] Define the content area of inline boxes #814

TabAtkins: So it sounds like b-d-b: inner-clone badly solves border-radius issues, and limiting it to just background is better solved with a break-padding property?

<fantasai> break-padding also causes problems with border-radius

fantasai: So I think those are the main two request from Nigel, this and figuring out the fill-the-gaps issue.
... Which I think is best done by making impls interoperable, then just using padding on the element.
... If we have a consistent box height, then having a line-height of 1.5 and a padding on inline of .25em above and below *should* fix the gap; if it doesn't, we should fix that.
... And for the other issue of cloning spaces - it seems the solution you're proposing doesn't actually solve the problem.
... It's not just "clone most nested"; if there is b-r involved, you want to spam that innermost b-r all the way up, so the lower backgrounds dont' show up underneath the topmost's b-r.

Rossen: So yeah, the feature request is something we'll work on, probably as part of Break. We'll go from there!

letter spacing

tter-spacing should not apply to the end edge of a line/span?

koji: Text 3 letter-spacing specifies that the letter-spacing after the last character of an element should be eliminated.

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

koji: Concern that, while this is better, it may not be web compatible.

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

koji: Our team prefers it be opt-in, so existing pages still work but authors can choose the better model.

<kochi> all right :)

koji: It looks like Sebastian and François agrees

fantasai: I know it's different, I wanna know if it actually causes a problem.
... Adding extra stuff is extra cognitive laod on the author; it would be better ot just do the right thing.

koji: We have a bug requesting this feature for years.
... He wants to stop using negative margin to cancel the space.
... If we change things, his pages' compensation will instead ram the characters together.

fantasai: Right, question is how many people will have that problem, and how many will be *fixed* by the change.
... If you have a large amoutn of letter-spacing to cancel, so large negative margin, and there's text after, that's a problem.
... But if it's a small letter-spacing, it'll have less than ideal spacing but still *okay*, but lots of other pages will have improved letter spacing.

koji: I think it's a little self-contradicting - people want this feature to care about it, and people who care can apply negative margin today.

<fantasai> myles_: I don't think that's necessarily true

<fantasai> TabAtkins: I've never realized I needed to deal with this case

myles_: There's a diff between caring about letter-spacing, caring and noticing there's a problem, and caring, noticing, and trying to fix it with this hack.
... What's stated in the spec is generally the correct result. I'd like to implement it, but I share fantasai's hesitation that we don't know how much will break.

fantasai: I'm not hesitant, I think we should try it.

fremy: letter-spacing is used eveyrwhere on the web, so even if a tiny fraction care enough to use the hack, it'll still be a lot of web pages.
... And browsers are mostly interoperable today. I don't think it's a huge problem to keep current spec, add new glyph-spacing property that works properly, and tell authors to use latter.

myles_: glyph-spacing is bad name

fremy: Sure, anything works.

myles_: I think making two solutions, one broken and one working, isn't great. We should investigate fixing the one.

fantasai: Someone has to ship it then.

myles_: Or crawl for it.
... Look for letter-sapcing and negative-margin on the same element.

Florian: Hard to tell automatically if it's bad.

fantasai: Have to investigate the *inherited* letter-spacing value, and if negative margin on the element.
... That's the pages that are trying to work around it.
... But there's also millions of pages that aren't trying to fix it, and will look better when we change it.
... So it's a balance of how much bad it is.
... Slijghty worse appearance, or readability is affected.
... So you have to actually look at the page.

bdc: Huge letterspacing is bad design by default, while negative letterspacing i soften used for proper kerning.

<fantasai> If it's mostly just slightly worse appearance, we're winning: there are many many more pages that aren't trying to compensate.

bdc: So there, we'd have the opposite issue - if we remove the space after last letter, we'd have bigger space between words than we currently have.

fantasai: If you apply letter-spacing to whole paragraph, no impact.

ack

dbaron: This isn't th efirst time it's brought up - maybe web compat, don't know, a little afraid of it.
... If it is web-compatible we should stick to the current design.
... If we wanna conclude it's not, we need more evidence than brought so far that it's not.
... Until we have evidence that it's not, we should stop trying to discuss it every six months.

<tantek> agreed with dbaron

<astearns> +1 to dbaron

fremy: I've seen a lot of websites using letter-spacing for not letter-spacing itself; icon fonts and aligning, letter-spacing of 1px because "it looks better on my PC", ...
... I'm concerned it'll be a lot of webpages, but I"m not sure how to figure it out.

<myles_> I think dbaron made the point I was trying to make, but much more elegantly than I did

TabAtkins: Do a good collection of affected pages via a crawl, then we can just sample them to whatever accuracy you want. Basic stats.

<tantek> or at least provide URLs to illustrative examples (didn't see any in the issue)

koji: I'm not clear on the next actions.

<tantek> (illustrative real world examples, not artificial data URls etc.)

koji: I think someone has to do a collection and figure out whether it's problematic or not?

myles_: Someone somewhere has to prove that an impl that follows the spec is not web-compatible.

<fantasai> TabAtkins: WG likes the current spec, and puts burden of proof on implementations to prove that it's not Web-compatible

<fantasai> TabAtkins: Need to evaluate pages where they have negative right margin that matches to the letter-spacing

<fantasai> TabAtkins: And then see if they are actually broken

koji: So who will do this?

myles_: Whoever wants to change the spec.

koji: Spec has been there for five years so far...

fantasai: Yeah, nobody has stepped forward to implement this.
... We want a spec and impls to match.
... So first option is somebody impls and ships and sees what trouble they have.
... Second is somebody does a crawl and checks the stats.
... Broken vs sligthy suboptimal; we dont' carea bout latter, because w'ell fix a bunch more pages.
... Third is we do what we did with control characters, where we all ship at same time.

Florian: Option 1 where things just ship, there are release channels for early info...

bdc: I don't see how the crawl is possible really - the margin might be a little different than th espacing, they might have negative spacing and positive margin...

fantasai: position margin is fine; it doesn't cause overlapping that hurts readability, just puts in a larger gap.

bdc: So I'm in favor of just keepign the spec as it is.

fantasai: So in favor of moving forward, do impls have a pref on which strategy to use?

koji: To me this is a nice feature, but not worth spending a week doing a crawl.
... So I'd much rather have another property that does opt-in.

fantasai: That won't give us useful information.
... Majority of people aren't paying attention to this, or aren't caring enough to do anything about it.

myles_: I think, going along with Elika, you can track the # of times you encouter a website that uses it, but that's only useful as a fraction, and you don't know the denominator.
... I can say 1k websites use the property, but we don't know how many sites considered it and didn't use it because it was bad for them.

fantasai: [repeats three options]
... And I think the WG is generally agreeing that changing the spec isn't a valid fourth option.

Bert: Gradual change; reduce it by half this year, then quarter next year, eventually it's nothing.

Rossen: So I don't think we did very good with the third option.
... Anyone want to do option #1?

[crickets]

Rossen: Anyone wants to crawl?

[crickets]

Rossen: So we're at same position as before.

fantasai: Question on #1 - we had zero interest in impl and shipping it.
... But if someone was to give you a patch, you just had to ship it, then what?

myles_: I'm happy to investigate it, I want to make this work. I'll impl and see if it doesn't work.

Rossen: Sounds good.

<dbaron> I think Gecko would be happy to try taking a patch.

<dbaron> Probably don't have the resources to do it in the near future.

ACTION Myles to investigate changing letter-spacing impl to match spec regarding spacing at start/end of element.

<trackbot> Created ACTION-857 - Investigate changing letter-spacing impl to match spec regarding spacing at start/end of element. [on Myles Maxfield - due 2017-08-11].

<br dur=15min>

github-bot, end topic

<fantasai> ACTION: fantasai to write test cases [recorded in http://www.w3.org/2017/08/04-css-irc]

<trackbot> Created ACTION-858 - Write test cases [on Elika Etemad - due 2017-08-11].

bidi mixed directions

letter-spacing and word-spacing applied to which side

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

koji: Problem from user perspective is that when letter-spacing is applied to a bidi-mixed string, Blink and Gecko has sometimes no l-s, sometimes double l-s, it's hard to predict.
... WK and Edge add even letter-spacing.
... It's not specced in CSS2, CSS3 defines quite different algorithm that solves this problem.
... But it requires some complex impl.

fantasai: CSS3 just says letter-spacing is applied after bidi reordering.

myles_: If we end up shipping what we resolved in the last topic, I tink that'll mean that the Blink behavior of switching which direction you add l-s to, you won't need anymore.

<fantasai> https://www.w3.org/TR/CSS21/text.html#spacing-props

myles_: bc then letter-spacing isn't on "left" or "right", it's on "inside".

fantasai: 2.1 defines it as "between characters" - double or nothing is just wrong.

<fantasai> CSS2.1 defines letter-spacing as "between" characters

fantasai: CSS3 is more precise "between adjacent typographic characters, after bidi reordering". No ambiguity.

<fantasai> https://drafts.csswg.org/css-text-3/#letter-spacing-property

myles_: So what's the proposal, making it legal to have double/nothing?

koji: Proposal is to match WK/Edge.

myles_: Oh, okay, great.
... So that's what the spec already says, right?

koji: If spec says between chars, this might be an impl issue.
... Most impls apply it to the left or right of characters.
... Edge and WK apply it to the line-right direction, so always "to the right" regardless of direction.

fantasai: ANd if we apply the previous topic's resolution, the user can't tell whether it's line-left/right.

koji: Blink/Gecko apply it to end side of resolved bidi direction.

Florian: Can't you detect it with backgrounds?

fantasai: No, l-s doesn't occur at a boundary; the l-s at a boundary is determined by the element containing both of them.

dbaron: I think the current spec is solid, just a decent bit of work to implement.

astearns: So reading of issue is just that Blink/Gecko need to change behavior to match spec?

koji: Yes.

RESOLUTION: No change, Blink/Gecko require bugfixes.

Applying letter-spacing after line breaking

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

koji: As fantasai just mentioned, diff between CSS2 and CSS3 is that 3 says apply l-s after bidi-reorder.
... But bidi-reorder applies after line-breaking,

<fantasai> CSS2.1 implied after bidi-reorder. L3 specifies explicitly

koji: Which can change the number of "between" spaces there is to add letter-spacing.
... So after we add letter-spacing, the line width can change, shorter or longer.
... So I think this is a worse issue than what it's trying to solve.

fantasai: You ahve to include the letter-spacing when figuring out sapcing and line-breaking.
... This is same as kerning.

koji: We don't redo kerning after bidi.
... Because changing line widths after break is really bad.

fantasai: Yeah, def don't want to change line-width afterwards, that's bad.
... So that measn you have to consider letter-spacing before breaking the line.
... But since bidi-reordering happens after breaking the line, you won't know where the letter-sapcing goes until after doing the reordering.

myles_: Do you have an example of this breaking?

koji: [looks it up]
... Last bit of example 16 in Text.
... There's a 2em spaccing between the characters in the span, but reordering separates the letters.

myles_: I understand now.

fantasai: If you have that example, bidi-reordering puts two letters nexxt to each other that weren't next to each other logically, do you perform shaping and kerning between them?

myles_: Ours won't cross bidi boundaries.

koji: We're trying to do better at shaping across element boundaries, but only in logical sequences, before bidi reordering.
... I believe we're trying to match Gecko's behavior.

fantasai: Yeah, difficult; we're splitting up letters in an element, so where does the letter-spacing go?
... Per spec, you don't put the letter spacing between letters of the element and letters outside the element.
... So I see you point that it's hard to measure correctly.

koji: If we follow Edge/WK impl and resolve the previous l-s topic, there should be 2em space on the right of C.

TabAtkins: line-right edge - in logical order, it separates the letter from the next logical letter.

fantasai: Example: you ahve a para with 1em letter spacing. Inside you have a span with 0 l-s. Between the last letter of the span and first letter outside the span, there's 1em letter spacing, where does that attach?

<p> f_o_o<span>bar</span>_f_o_o</p>

fantasai: Another span with borders and padding. You do linebreaking calcs.
... Then you cut the line and do bidi reordering, but it has b-d-b: clone. Now you have two pieces with padding around them, where befor eyou had only one. Now what?

<p> f_o_o_<span>bar</span>_f_o_o</p>, rather

koji: I was reading b-d-b for the first time this morning, and thought of that exact problem.

dbaron: Okay, at bidi *resolution* time, the element would split into two separate fragments, and thus both get borders.

koji: But you don't know how linebreaking will happen yet.

TabAtkins: If there's only enough room for 4 letters, so the "c" and the aleph are next to each other, is that still two independent spans?

dbaron: We don't unclone them - they stay separate fragments.

<dbaron> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0Aspan%20%7B%20border%3A%20medium%20solid%20blue%3B%20background%3A%20aqua%3B%20%7D%0A%3C%2Fstyle%3E%0A%3Cp%3Eab%3Cspan%3Ec%D7%90%3C%2Fspan%3E%D7%91%D7%92%3C%2Fp%3E%0A%3Cp%3Eab%3Cspan%20style%3D%22box-decoration-break%3Aclone%22%3Ec%D7%90%3C%2Fspan%3E%D7%91%D7%92%3C%2F

<dbaron> p%3E%0A%3Cp%3Eab%3Cspan%20style%3D%22box-decoration-break%3Aclone%22%3Ec%D7%90%3C%2Fspan%3E%3Cbr%3E%D7%91%D7%92%3C%2Fp%3E

<dbaron> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/5292

dbaron: That might not be an intentional decision; they might have thought about it as normal linebreaking and this behavior just falls out.

fantasai: I think it's okay to allow impls to do that.

<fantasai> TabAtkins: So the c and aleh would still be considered separate fragments, even though they are adjacent

<fantasai> TabAtkins: and the letter-spacing between them would be controlled by the parent

<fantasai> fantasai: I like this solution

<fantasai> TabAtkins: Wouldn't be too complicated, and would give sensible results in most cases and sensible-enough results in the rest

<fantasai> TabAtkins: During bidi resolution, you split them into separate fragments, and behavior falls out from that

koji: So we'll lose the letter sapcing between bidi runs.

TabAtkins: If the bidi runs are in the same element, yes - they'll use the parent's letter-spacing.

<fantasai> Proposed that bidi resolution would result in splitting an inline in infinite space will always create two fragments, even if they end up adjacent due to line breaking.

line-break: break-all

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

Florian: line-break:break-all isn't a great name. Should we find a better name?
... I think all names are bad, but I can't come up with a good one.
... This value allows line-breaks everywhere.
... word-break:break-all allows for breaks between letters, but not between punctuations, spaces, etc.

line-break is terminal wrapping, word-break is just hyphens-wherver-you-want

Florian: Trying to do better ignoring web constraints is hard, trying to do better *with* web compat is near impossible.
... line-break:break-all is the newest one, with best chance of renaming.
... Unforutnately it's got the best name, I think.

koji: I don't mean it's badly named, just that same keyword on similar property doing differently is confusing.
... Particularly if we have a shorthand for both hof these.

fantasai: shorthands can do custom syntax; we'll definitely redesign the whole thing if we do a shorthand
... Shorthand would be *great*, we can make it all make sense

koji: I understand it's possible, but if we're naming now, why choose "break-all"?

fantasai: We didn't have a better one.

koji: Line-break:terminal?

<fantasai> Rossen: anywhere?

<fantasai> Rossen: any?

<fantasai> Rossen: all?

<fantasai> TabAtkins: That would force a break between every character

[a few people like anywhere]

<fantasai> Rossen: anyone care?

<fantasai> TabAtkins: I think re-using the keyword is bad

<fantasai> [several other ppl care]

Rossen: So from the people paying attention, any objections to renaming break-all to anywhere?

dbaron: How widely implemented?

fantasai: Nowhere, it's new, we added it this year.

RESOLUTION: Rename line-break:break-all to line-break:anywhere.

Florian: I have a PR for this change; other than me changing this keyword, can the editors approve it or tell me what's wrong?

fantasai: Yeah, at lunchb.

RESOLUTION: After edits from this meeting, publish new WD of Text 3.

text-spacing fullwidth punctuation collapsing

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

Florian: In CJK, full-width punct takes a full-width box, but they visually fill half o fit
... Japanese expects that when they're next to each other (like two close-parens), there will not be a big space, they'll be collapsed visually.
... The font contains spaces, but it needs to be canceled out in some cases.
... We have a rule in Text 4 that says when to do this.
... One rule is overcomplicated. We did it wrong because JLReq wasn't specific enough.
... Case is where you have a closing punct followed by an opening one: `)(`.
... If you did nothing it's 2em long, we want 1.5em long.
... Closing, half-space, opening.

fantasai: Collapse away the adjacent half space.

Florian: We specced that each is .75em long.
... Proper is to keep all space on closing one, remove all space from opening.
... Difference is barely observable, we should match.

fantasai: Did the people working on those things consider the case of different-sized fonts?
... Second paren is half the size of the first one, then what should happen?

Florian: That's where it becomes observable.

fantasai: I think probably 75% on each side isn't the right answer, so we should change it, but also not convinced we should always use the first.

Florian: Unsure. Murakami says to do it the other way, and InDesign does it the other way, so we should match.

fantasai: One thing we often do is look at print examples, and find where they're not handling cases.
... I think we should choose one or the other; we could use innermost or outermost...

Florian: They're same level.

fantasai: Always use bigger one?

myles_: That'll cause space to change when font-size animates?

TabAtkins: It'll do that no matter what.

Florian: I think we should match pubs, with a note about if someone has cases not considered, let us know.

fantasai: Korean mixes font sizes a lot; rather than ruby they just reduce font-szie

Florian: But they use latin punctuation, not full-width, so this doesn't apply.

myles_: I think it makes the most sense to do what everyone else does as a first pass.

fantasai: Happy with that if we follow up with JLReq to make sure they think about this case.

Rossen: ARe you current JLReq laiason?

Florian: Not yet, I have something later about that.

koji: I think previous spec is ambiguous, just says "put a half space between them".

Rossen: So can we resolve to accept change, put a note in, and follow up with JLReq?

RESOLUTION: Accept change matching JLReq's punctuation spacing, put a note into the spec about maybe needing more complex stuff, follow up with JLReq about the topic.

Renaming the dynamic and static profiles of selectors

Rossen: Mail sent last Saturday.

<Rossen> https://lists.w3.org/Archives/Public/www-style/2017Jul/0039.html

<fantasai> https://www.w3.org/TR/selectors4/#profiles

TabAtkins: So I've seen enough feedback by now that I agree that "static/dynamci" is confusing. Dynamic makes people think of JS. Let's talk about it over lunch and come back?

Orthogonal Flow Constraint: viewport vs scroller

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

fantasai: We resolved to use the nearest scrollport height for orthogonal flow fallback height.
... But that can be auto. ICB is always fixed; we want this to be fixed as well.

<dbaron> Should it be the nearest scrollport that's non-auto height?

<astearns> nearest scrollable definite-height ancestor?

<astearns> dang, dbaron beat me to it

Rossen: When I was working on this, the logic I added was to keep looking for the nearest ancestor that imposes a fixed height or scroller, and if scroller is height:auto I think I keep going up.
... You can go figure out the viewport size, but that doesn't buy you much.

fantasai: I think you want it to be a size you can calc without doing layout.

Rossen: Which is doable if you find a fixed ancestor.

fantasai: If you look for fixed size and subtract mbp, you run into problems we saw before with stretch, where you get so much mbp you're zero size.
... Also, our goal if you're doing autosize is to not make it larger than what you can see in one screenful; goal is to fit a line of text they can comfortably read. Nearest fixed container might be larger than the viewport.

<fantasai> Rossen: But then you'd have that problem with other things

<fantasai> TabAtkins: The other things are intended to scroll vertically

fantasai: It's very important that a line length is less than the size of the viewport, so you don't scroll back and forth.
... So nearest fixed container might violate that.
... This is why we used viewport instead of some random number.

<fantasai> TabAtkins: If it's as big or smaller than the viewport, then even if it's not perfectly nice, the user can sroll it into place and be able to read comfotably

fremy: You're preventing people from using transforms. They might want large initial size, then scale it down. You'd prevent that.

<fantasai> TabAtkins: for transforms all bets are off

<fantasai> TabAtkins: We could clamp to smaller of the scrollport and the viewport

Rossen: Using smaller of fixed-height ancestor or viewport sounds okay.

fantasai: If your parent is fixed size, we already clamp by that.
... But when we don't have a fixed size, we don't want to look up thru multiple layers of auto and find a size bigger than auto.

Proposal: orthogonal flow fallback height is min(100vh, nearest fixed-size scrollport ancestor's height), no caring about mbp or anything.

+ logical swap for other ordering.

+ available size of immediate container, which normally controls size

<fantasai> min(100vh, nearest fixed-size scrollport, available size)

fantasai: Looking at spec, you choose smaller of "containing block size" and "ICB size", and the issue/discussion was about replacing ICB size.

<fantasai> current CR is min(100vh, available size), previous resolution was min(available size, nearest scrollport)

TabAtkins: So just adding one more bullet to that list, for nearest fixed scrollport.

RESOLUTION: Add "size of nearest fixed scrollport" to the list of things you clamp orthogonal flow inline sizes to, editting the CR.

<br type=lunch dur=1hr>

github-bot, end topic

<dauwhe> scribenick: dauwhe

renaming selector profiles

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

astearns: dbaron added the issue, there was some discussion during lunch, but no resolution

<dbaron> github: https://github.com/w3c/csswg-drafts/issues/1694

astearns: let's try to put realistic suggestions in the issue

dino suggestion on variables

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

dino: [approaches podium]
... I'll explain it backwards
... we're proposing a new var function
... instead of exposing user custom properties
... these are defined by the user agent
... "constant" means you can''t change it
... user wants to control type size on iphone
... css can't detect that
... you can query the UA value, and then use calc to respond
... User agent properties
... rest is similar to CSS variables
... I show lots of examples... font size, foreground/background color...
... like user pref for black background/white text
... some dyslexic folks want low contrast
... so CSS could query UA and then respond
... or we could use safe areas when projecting to screen of different size

glazou: it's coming from UA and system?

dino: yes

iank_: could you draw the safe area on the blackboard

dino: this has been a concept in TV
... some TVs you wouldn't see the whole frame
... so there was a title safe area, where you know pixels would always be visible

myles: modern TVs fake this,

dino: if you have a circular display, the safe area might be in the middle

glazou: I like this
... open question: could be extended to system colors?
... we'd have to find common names for system colors on all platforms
... 2nd thing: I'd like to see a 2nd part with JS elements to detect system change events

dino: you can't do MQ

glazou: being able to detect theme change, or that you switched to night view.... would be cool

bdc: like underlying idea of prefers-reduced-motion MQ...
... so why do we want a new thing?

dino: unlike MQ, you want to know a value
... given one of these values, tell me when it changes

bdc: i don't see a difference

Florian_: i don't think so
... reduced motion is not about make things slower... it's about doing something else

dino: for reduced motion, sometimes we fade in instead of moving in
... we're generally not removing animations

astearns: I want to ask about support

dino: this raises issue on css var spec
... but I don't know where the property lists go

astearns: if we don't have access for @supports, how do we author?

<dbaron> you could always do @supports (color: constant(foobar)), no?

gregwhitworth: these are defined by the UA
... how are we not going to end up with the -webkit- prefixes unless we agree on everything?

dino: these are new properties
... just like a normal property

gregwhitworth: they'll be standardized?

dino: yes
... we want them to be universal
... don't know if they should be prefixed with --
... so they know they can't set, maybe it's ++

melanierichards: let's say the ua stores the value
... the user hasn't overwritten defeault value of foo
... would it be undefined?
... as an author, I'd only want the value when it was overwritten by the user

dino: good question

Florian_: it's a nice hammer we have here, we should be careful with it
... the examples of things are less comfortable with, as they could be solved in other ways

dino: I'm mostly interested in font size and inset ones

Florian_: for font size, why don't you change REM

TabAtkins: REM is font size on root element, this is initial value

Florian_: this will be one rem if not overridden?
... for inset, we've been discussing a similar problem, and were trying to solve some other way?

dino: haven't looked at other solutions

myles: what's the other one

Florian_: first, a media query for shape, another is another MQ about 'if I place something there, is it visible?'
... third is using shape inside: display
... let's not rush into defining through this, as it might prevent us from exploring other solutions

fremy: I have same concern as surma
... why don't reuse var function?
... we could use namespace for var function
... so we don't need new function
... just variable under new namespace

dino: i don't mind
... but we used the name constant to remind user they can't change it
... under the hood it uses same code as variables

fremy: I think it's better to reuse namespace inside var

Rossen: thumbs up on the idea
... we've had lots of requests
... in terms of getting font size and background colors

<fremy> fremy: e.g. { color: var(user preferred-color) }

Rossen: respond to high contrast, etc

<Florian_> var(system safe-area-inset)

Rossen: would be insteresting to see the path forward
... and to summarize how much stuff you want to expose

TabAtkins: performance would be better than variables
... you don't control the values

plinss: what about UA changing while you're animating?

dino: we should have current color blink text :)

<Zakim> Bert, you wanted to ask do you need the word "constant"? Isn't 'contant(foo)' easier written as 'foo'?

Bert: constant looks like an identity function. can't you use the ID itself? use "fontsize"?

Florian_: we need comma fallback

fremy: if you have properties like font-family you couldn't use it

TabAtkins: this would add an unlimited set of global keywords to CSS
... functions prevent that

gregwhitworth: one should be scroll-bar-width
... arrow color,

glazou: I want to expand on unlimited sets of global name
... we want to make sure nothing is shipped until everyone agrees on how it works
... let's keep it clean

TabAtkins: you only need a few smart devs with houdini, then everyone can use libraries

glazou: it's like what fremy said, it's a namespace
... I think we can reach consensus on the names

astearns: two more

SimonSapin: what about fallback?

dino: you could do comma zero

<SimonSapin> SimonSapin: fallback same as in var()?

<SimonSapin> dino: yes

gregwhitworth: I think our biggest request is high contrast, which we map to system colors
... it became a problem because not everyone does high contrast theming
... we may have foreground/background, do we need accent color and accent color2?
... I foresee problems
... so fallback is what you get

dino: I hear general agreement
... concerns about constants vs var with namespace
... melanierichards wants to know when user explicitly change
... them, someone else wants to ahve events

myles: unset is same as "i don't know what you're talking about"

astearns: general consensus that this is interesting

grid issues

TabAtkins: we have grid issues

fantasai: the gap one?

<rachelandrew> https://github.com/w3c/csswg-drafts/issues/1696

grid-gap

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

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

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

TabAtkins: we decided that grid gutter should be reset by shorthand
... authors have given feedback that the opposite is true
... so are annoyed to reestablish their gutters
... so we propose to change that, and stop resetting gutters in shorthand

fantasai: that's the basis of that
... the other issue is 1696

TabAtkins: the grip prop is already complex
... worst case is having some gutters you didn't intend
... a proposal to handle this and other author feedback is to rework how we handle gutters
... rename them and apply them to all layout modes where it makes sense

fantasai: we had originally designed them for multicol

TabAtkins: didn't make sense for column gap to be reset by grid

fantasai: so we undo the link, undo grid prefix
... make colgap and rowgap apply to flex containers
... this is highly desired

TabAtkins: they want min spacing between flex items and flex lines,

fantasai: one comment is can we have one set of properties to make it easy to learn

astearns: is it hard to change flex distro algo?

TabAtkins: it's easy

fantasai: as a last point, nice to obsolete border-spacing
... controls spaces between cells, and it inherits

TabAtkins: it's the only layout property that inherits

fantasai: if we could redesign, it wouldn't inherit, and would be logical

TabAtkins: normal would be zero by default, in grid and flex, and 1em in multicol
... because all the gridgap stuff has shipped, so we have to keep

<Rossen> the gap property is coming! https://lemontree.se/wp-content/uploads/2014/10/titles-Mind-the-Gap-Large.jpg

TabAtkins: only thing we break will be grid gap reset

fantasai: we need shorthand for column gap and grid gap

Florian_: column-gap would be shorthand for grid-column-gap etc

fantasai: none of them inherit

bdc: there's a proposal for a new gap shorthand?

fantasai: the proposal is to alias grid-row-gap

astearns: it's not temporary

fantasai: it might be permanent
... the goal is to use column-gap and row-gap, and have a shorthand for the two of them

fremy: track-gap

fantasai: people are using shorthand more often
... we'll have to run some data, but we might be able to remove the longhands

TabAtkins: one less alias to maintain

Florian_: weird to use grid stuff to reset your flex

SimonSapin: they would be aliases?

TabAtkins: one is shorthand of the other

fantasai: page-break properties are shorthands of the break-* properties

SimonSapin: so these would be shorthands with one longhand each

TabAtkins: they'd both access the same underlying value

SimonSapin: what happens in CSSOM?

<fantasai> SimonSapin, https://www.w3.org/TR/css-break-3/#page-break-properties

astearns: sounds like there are 3 things
... 1 changing what's set by grid shorthand
... 2 adding connection between the various gaps
... 3 is some shorthand for all this

TabAtkins: 4 doing table cleanup
... but it would be nice to have everything use same gaps

astearns: are there any objections to changoing grid shorthand to not reset column and row gaps?

RESOLUTION: change what grid shorthand resets

dbaron: who will be first to implement?

Rossen: we'll do it

bdc: might not break anything

astearns: will only change behaviour if they set gaps, used shorthand, etc

rachelandrew: most people are not using shorthands

plinss: they do pretty much whatever you tell them to do at this point :)

astearns: so edge is willing to go first?
... we're yet to release the updated grid

Rossen: I wish we didn't have to do the aliases

astearns: the second thing: any more discussion on column-gap and row-gap applying to all layout modes with gaps?
... there will be a communication issue

iank_: which layout modes?

TabAtkins: multicol, grid, flex, and maybe table

fantasai: multi-col, grid, and flex all respond to the column-gap and row-gap properties

dbaron: which property has the normal value?

TabAtkins: column-gap and row-gap
... for multicol it will be 1em, which is no change

astearns: what does column-gap normal do in grid and flex?

TabAtkins: Zero

dbaron: column-gap already has a normal value

astearns: we're adding normal to row-gap

dbaron: this is renaming thing for grid back to the old multicol things

TabAtkins: yes

dbaron: same syntax?

TabAtkins: yep
... adding normal keyword to row-gap

fremy: do we need grid-row-gap and grid-column-gap
... they are not interoperable

TabAtkins: why

fremy: in the sense that lots of browsers don't support grid
... so there are not a lot of websites that use grid, and they were made in the last six months

TabAtkins: maybe,

fremy: to me this is a breaking change

TabAtkins: if they are using grid-column-gap etc it will break things
... we need to look into how often they are use
... default to safe answer of aliasing them

Rossen: can we resolve?

astearns: any other comments on using these in grid, flex, and multicol

<fantasai> I agree with Tab, let's keep the aliases for now but look into dropping them

dbaron: this is new feature for flex?

TabAtkins: this is the most requested feature for flex

bdc: the gap shorthand property is part of this resolution?

astearns: we will have a shorthand, we're just not sure what it's called

fantasai: we don't have to figure it out now. one thing at a time
... proposed resolution; existing column-gap and new row-gap with same syntax apply to flex, grid, and multicol, and alias to current props

dbaron: is handling of percentagges between the two consistent?

Florian_: multicol didn't have percentage until recently
... not implemented yet
... spec says % should work in multicol

TabAtkins: the definitions are identical

astearns: no concern?

TabAtkins: they're the same

astearns: any objection?

RESOLUTION: column-gap and row-gap apply to flex, grid, and multicol

bdc: we could use gap as the shorthand

TabAtkins: do we have three letter properties?

astearns: options for shorthand are "gap" or pre=existing "grid-gap"

<dbaron> the only 3-letter properties in Gecko are 'top' and 'all'. A whole bunch of 4-letter ones, though...

astearns: we have to maintain grid-gap as shorthand, but that could be a discoverability problem

<Rossen> https://lemontree.se/wp-content/uploads/2014/10/titles-Mind-the-Gap-Large.jpg

astearns: the proposal is to add a shorthand for column-gap and row-gap that is just gap and aliased to grid-gap

fremy: I don't know if we have a shorthand aliased to a shorthand

<glazou> LOL

myles: the question isn't that you have it, it's that you can do it :)

astearns: any objection?

fantasai: I think it's unnecessary aliasing, but I won't object

Rossen: there's probably not a ton of content out there,
... I would prefer not to ship grid-gap at all
... I don't mind aliasing the grid ones for a while
... given this is six months of a feature, I'd be surprised if we couldn't do this

rachelandrew: I'll update all my stuff. I've already tweeted :)

fantasai: rachel and Jen can get the information out there
... but they can't create a forcing function for people who've already been trained
... but microsoft can do this by not shipping grid-*-gap

Rossen: that means interop pain for us

fremy: I'd rather not write a bunch of aliasing code that we're going to remove in six months

fantasai: it's not going to be difficult for you, it will be annoying for authors during the transition

Rossen: I don' think this is a q of implementaiton
... we'll decide about aliases internally
... I won't promise we'll ship without grid-column-gap etc, but

astearns: the hope is that we're early enough that we can eventually remove

Rossen: when we ship

Florian_: grid is unusual in that most browsers shipped in a very short time
... even though it's only six months, but a lot happened in those six months

iank_: the main compat risk is chrome mobile(???)

<fantasai> TabAtkins, can you run a search on occurrances of grid-row-gap and grid-column-gap?

astearns: proposed resolution: add gap shorthand

<TabAtkins> fantasai, probably

RESOLUTION: add gap shorthand

astearns: do we want to talk about tables?

fantasai: we have a solid proposal

TabAtkins: a single convenient interface to everything that can have gaps

dbaron: the weird thing about border space being inherited
... applies only to table with border-collapse : separate
... border-collapse is inherited
... most tables will be separated

fantasai: unless you are setting column-gap or row-gap on a table already, then there's no effect
... the new propoerties don't inherit

dbaron: if applies to table, then will apply to sides of columns, and row gaps apply to tops/bottoms

fantasai: we're not saying border-spacing reads out from column-gap
... if the value of column-gap is normal, then look at border-spacing prop

dbaron: that would be weird if it applied inside, but not around edge
... the full value plus padding on table element

fantasai: actions are to have these acts to apply only to the interior

dbaron: I think that's a bad idea

TabAtkins: either don't apply at all, or affect outside?

fantasai: this is low-priority

TabAtkins: it applys to every table

astearns: one solution is to not change tables
... that's my general rule: don't mess with tables

fantasai: fallback issue
... table displays are used for fallback in flex/grid
... since it acts similarly
... we will have authors using flex or grid model with these gap properties
... in implementations that don't support them, they will fall back to table
... but they don't support new gap properties

gregwhitworth: so it won't matter

iank_: I find this strange because we're not messing with table

s

astearns: proposed resolution: don't have the new gap properties apply to tables

TabAtkins: where do these properties go

RESOLUTION: Tables are not changed

TabAtkins: align is the best place
... it only applies to things taht are content-distributed
... grid and flex will have sections pointing to this

astearns: and multicol

rachelandrew: same as any of the align stuff

Florian_: we need to fix grid, but just add it to other spec

TabAtkins: we need a section in grid

Florian_: in flex maybe not

astearns: nothing to correct in flex, just informative

RESOLUTION: Add gap properties to align spec

Rossen: how far along is this spec?

fantasai: trying to get to cr

astearns: I think we're done with gaps for now!
... are there other grid issues?

Rossen: Do we want to go over many of them?
... we don't have to discuss all of them now

astearns: keep remaining grid discussion to 30 minutes

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

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

percentage children of stretch grid items

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

TabAtkins: flexbox has special text defining if your flex item is stretched and flex item is definite height specified
... grid doesn't have the same text, but some bits of it imply that
... so it would be useful to have it apply to grid
... easier 'cause it's sized according to tracks
... rossen said this should work
... for the same reason as flex
... 1320 is the same thing
... any opinions to the contrary?

(silence)

astearns: any objection?

RESOLUTION: copy from flexbox to grid: do what 1320 says :)

RESOLUTION: copy from flexbox to grid: do what 1319 says :)

fantasai: axis names is an editorial thing

looking for next topic

fantasai: we only use it in a couple of places
... I don't think it's causing problems
... there's a request to add a note, and we're fine doing that

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

Rossen: is there an issue about intrinsic ratio?

fantasai: 1149?

Automatic Minimum Size for grid items should not min against content size

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

TabAtkins: in flex we do to some effort to find minimum size
... if it's image we try to figure out what information is important
... this is useful because flex uses this to size the image
... grid uses the info to size the track, and then lets the image size to the track
... the big difference is say you have a specified size of 100px and intrinsic size is 50px
... we use 50px in flex
... grid doesn't have to worry about shrinking
... "So, we think the right fix is to just change Grid's automatic minimum size to be the specified size if it exists, else the transferred size if it exists, else the content size."
... this better matches author intent for automatic minimum sizing of images

(tab draws on whiteboard)

scribe: image is 50px
... put in grid container, set to 100px
... in flex, minimum value is 50, it's allowed to shrink to that
... in grid, we prefer to say let's stick with 100, 'cause the author said so
... and avoid risk of overflow

Rossen: additional piece: if you open the test case

https://test.csswg.org/suites/css-grid-1_dev/nightly-unstable/html/grid-minimum-size-grid-items-007.ht

TabAtkins: sets itself to 100px, but grid width is 10 x 10
... if we went by previous algo, track would be 50px
... maintaining aspect ratio is important

astearns: any other comments?

Rossen: this one has height set
... current spec says minimum of instrinsic and transfer?

fantasai: use specified if you have it, content if you don't

TabAtkins: edge does it
... any objections?

astearns: hearing no objection,

RESOLUTION: is either it's defined size, content size, or transfer size

(do what 1149 says)

fantasai: there was one about stretching tracks

find another topic

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

TabAtkins: have I seen this?

fantasai: 1150

Stretching tracks fails to feed back into sizing algorithm

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

fantasai: the issue here is that the stretch alignment property takes effect
... at the end of the algo
... you size the cols, then use size of cols to set height of rows
... at the end you do alignment
... that's generally fine
... cause alignment don't change track sizes
... but stretch does
... if you start with this example, you have image with intrinsic size, col sizes to intrinsic size, then try to size the rows
... and we use the size of the columns because there's an aspect ratio
... and now the item that's 100% wide fills the track in that axis, but then overflows the row
... the suggestion is that the stretching phase should be accounted for in the sizing algo

TabAtkins: makes sense

fantasai: we'll try to incorporate this into the algo, then will bring to group for review

TabAtkins: is auto track and stretch distro the only thing that does this?

fantasai: yes

TabAtkins: then this makes total sense

fantasai: the proposal is to handle the streching at each phase of stretch sizing

astearns: would it make sense to have a note in align?

fantasai: flex already has this kind of integration

Rossen: stretching and last baseline tend to have feedback back into the layout algo

<fantasai> astearns: Yeah, so should have a note pointing to the appropriate section of grid/flex

RESOLUTION: integrate stretching into track sizing algo

fantasai: ONE MORE THING

one more thing

fantasai: we have several discussions about how baseline interacts with grid sizing
... gonna try to make that work, and then bring back to WG for review

astearns: that sounds like the right hting to do

fantasai: the other was discussion with max on aspect ratio of images

Rossen: that might disappear with a previous resolution

fantasai: it's different
... nothing to do with minimum size
... the issue that max was talking about, you could set min size to zero and still hit it
... we've resolved to reject feedback, but we assumed we have interop
... I'll double-check

Rossen: next steps for grid
... baselines is one of the potential behaviour changes coming
... outside of those, are there any other major behaviour changes?
... most issues here are editorial

fantasai: most of them are editorial
... I won't know until I fix issues and do DOC
... there are some fiddly auto-sizing things

astearns: let's take a gap

<br duration="15min"></br>

multicol

<jet> astearns: rachelandrew will be editor

RESOLUTION: rachelandrew to edit multicol

writing modes

<jet> astearns: normative change to CR draft

<jet> astearns: need a new CR and tests

RESOLUTION: a new CR of writing modes after edits and tests

<Florian> https://github.com/w3c/csswg-drafts/issues/1391

APL

<astearns> https://www.kri.sfc.keio.ac.jp/en/lab/aplab.html

<jet> Florian: Advanced Publishing Lab started in Keio university

<jet> Florian: Japanese industry driving potentially a new CJKlreq req

<jet> Florian: group wants to inform CSSWG of their requirements

<jet> astearns: C & K in scope?

<jet> Florian: not sure, but likely

<jet> astearns: please update the group as needed

inline layout

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

<jet> Florian: from weaknesses of vertcal rythm

<jet> Florian: found lineheight issues from that investigation

<Florian> https://github.com/w3c/csswg-drafts/issues/938#issuecomment-314690847

<jet> Florian: I did a bunch of testing ^

<jet> Florian: shows how browsers differ

<jet> Florian: more interop than expected

<jet> Florian: Safari & Edge are the same

<jet> Florian: Chrome differs

<jet> Florian: Firefox differs

<jet> Florian: when lineheight is a number or length vs. normal

<jet> Florian: refers to diagram from Tokyo discussions

<jet> Florian: (see github issue for diagram)

<jet> Florian: can't figure out Chromium baseline alignment

<jet> Florian: why does chrome behave this way?

<jet> Florian: we should fork the issue for general lineheight

<jet> Florian: we need to define base behavior of lineheight

<jet> fantasai: because rhythm depends on lineheight

<fantasai> fantasai: because the trigger to round up for rhythm depends on the computation of line height

<fantasai> myles_: and you can double spacing in some UAs not others if those computations differ

<fantasai> fantasai: right

<jet> Florian: goal is general interop on lineheight

<jet> astearns: discuss divergence on lineheight:normal

<jet> Florian: can isolate individual bugs

<jet> ACTION: Florian to file bugs with each case [recorded in http://www.w3.org/2017/08/04-css-irc]

<trackbot> Error creating an ACTION: could not connect to Tracker. Please mail <sysreq@w3.org> with details about what happened.

<jet> fantasai: we don't have a spec for these issues

<fantasai> astearns: but we have interop except for chrome

<fantasai> astearns: so Chrome should figure out whether there's a reason to diverge, or whether they will fix it

<fantasai> astearns: and then we can spec the result of that discussion

<jet> Florian: for lineheight:normal Chrome differs by using the top of the tallest used fonts

<jet> Florian: will file a bug on that one

<jet> koji: we need to see the test

<jet> Florian: we'll debug later

<jet> Florian: I had to find fonts with tall ascenders and long descenders

<jet> Florian: Firefox font metrics differ

<jet> Florian: not sure why

<fantasai> myles_: If a browser changes the metrics they read from a font, every web page will look different. At least for us, that would be almost certainly unlikely to happen.

<jet> myles: if a browser changes metrics per font, every web page will render differently

<jet> Florian: in some cases Firefox is the same

<jet> dbaron: platform API's differ for metrics

<jet> koji: everyone has 3 font metrics

<jet> Florian: Chrome & Safari same on Mac

<jet> Florian: Chome & Edge same on WIndows

<jet> myles: some fonts are just weird

<fantasai> myles_: For at least font on at leats one platform, at least one of the metrics of the font returned by the system API doesn't appear anywhere in the font

<jet> Florian: the tests aren't clear re: metrics, but does show the divergence

<jet> Florian: I checked the content box for inlines--also no interop

<jet> Florian: on Chrome, doesnt depend on font metrics or lineheight

<jet> fantasai: spec says content box can't depend on lineheight

<jet> Florian: Firefox depends on font metrics and not lineheight

<jet> Florian: notes Chrome bugs

<jet> fantasai: is it 1 em?

<jet> fantasai: 1 em is at least predictable

<jet> Florian: not 1 em

<dbaron> FWIW, Gecko has 4 platform-specific font backends: (1) FreeType (used on Linux and Android), (2) Mac (3) GDI (Windows) and (4) DirectWrite (also Windows)

<jet> Florian: more testing needed

<jet> Bert: CSS2 recommends 1em or height of the ascender to descender

<Bert> ". The height of the content area should be based on the font, but this specification does not specify how. A UA may, e.g., use the em-box or the maximum ascender and descender of the font. "

<myles_> dbaron: macOS has CoreText and CoreGraphics and they may disagree

<Bert> (This is from CSS2)

<Bert> https://www.w3.org/TR/CSS2/visudet.html#inline-non-replaced

<dbaron> myles_, I think we're using CoreText

<jet> astearns: it differs depending on the platform font subsystem

<myles_> dbaron: 💯

<dbaron> myles_, er, wait, there's a pointer to both objects :-P

<myles_> dbaron: 💯💯✅

<jet> Florian: Firefox differs with Outlines

<dbaron> myles_, InitMetrics seems to use mostly CG* APIs

<jet> Florian: outline allows a lot of leeway

<jet> Florian: and Firefox diverges most

<jet> Florian: please review the tests

<jet> astearns: file the bugs and have the browser engineers challenge

<jet> fantasai: we want interop and sane behavior so file spec bugs not browser bugs

<jet> fantasai: resolve on content box height?

<dbaron> myles_, I think we use Core Text only for fonts with color bitmap glyphs

<fantasai> Florian: we have 3 behaviors, Chrome I can't figure out at all. Doesn't seem to depend on line height or font metrics

<fantasai> Florian: Firefox ....

<jet> astearns: if we file a Chrome bug, we can get interop

<jet> astearns: despite no spec

<jet> fantasai: we should specify what the TTML folks can use

<dbaron> I think there are probably much larger audiences than the TTML folks who care about this.

<jet> Florian: using ascender/descender lengths is unpredictable

<fantasai> dbaron, not sure who that is, but pretty sure they'd agree on having something controllable and predictable

<jet> dbaron: may be concerns re: e.g., accent marks not hanging out of the background

<jet> dbaron: and that might be more important for Vietnamese than for English

<jet> Florian: content box depending on font metrics is very unpredictable

<jet> Florian: we can resolve on Safari/Edge behavior re: lineheight:normal being a bug

<jet> Florian: lineheight != normal returns different sizes

<jet> astearns: curently not a spec violation

<astearns> but we should probably make it one

<jet> fremy: we can't resolve if we don't know what to spec

<dbaron> I think it is a violation of https://drafts.csswg.org/css2/visudet.html#inline-non-replaced

<jet> fremy: please file more specific issues

<jet> Florian: we'll split the topic

<astearns> dbaron: fair - "The 'height' property does not apply <to the content area>" does seem to be relevant

<jet> fantasai: file issues against CSS inline and CSS2

<jet> Florian: I tested 2 ways: line stacking and with border. same results

<dbaron> I guess it's violating the "should" that it's based on the font

<jet> fremy: spec proposes 2 solutions

<jet> fremy: not sure how we choose either

<jet> fremy: I need to check Edge code

<fremy> fremy: but maybe we consider line-height to be intent from authors they want control

<jet> Florian: interop is fixable

CSS Rhythm

<astearns> https://groups.google.com/forum/#!msg/mozilla.dev.platform/cnEN_sccXJY/1ddo5XifAwAJ

<fantasai> ScribeNick: fantasai

koji: I'd like dbaron to explain his opinion

dbaron: Current approaches are going to lead to things that are fragile wrt behavior between browsers, or even same browser on different platforms
... where you get double-spacing of line sin unpredictable situations
... There are alternative approaches which would not lead to this problem
... But I'm not interested in focusing on this right now

dauwhe: are you concerned about just the inline step sizing, or all of css rhythm?

dbaron: Right now not looking at anything
... I'm discouraging ppl from implementing this feature because I don't think it's something that should be implemented

koji: Same issue as double-spacing

dbaron: Some of the ways to solve it might be to use an entirely differnet design, whereas github issue is trying to keep the same design and trying to find small fixes for double-spacing

koji: Your concern is different font metrics causing different result is the problem?
... Original issue was line-height normal causing problems

Florian: There's a general problem and a specific case of that problem
... general problem is when different font metrics or different ways to implement line height or things of that nature cause the layout to work just fine in one browser
... and to be entirely double-spaced or randomly double-spaced in another browser
... That's the general worry

<dbaron> or different font availability

Florian: within that space, this github issue identifies one case where this happens
... if this is the only case where this happens, maybe dbaron's worry goes away
... If there are more instances of similar worries, we'll need lots of patches

dbaron: Another major case is font availability, where you have a font available on one platform and not on others

koji: I heard one example
... but dbaron's concern seems to be a different case

Florian: it's the same
... if line-height-step is a user-defined specific value
... and line-height is a different user-defined value
... then this is generally predictable
... if line-height is smaller than line-height-step generally okay
... If there's one line that has a superscript and double spaced that line it's kindof okay
... but double-spacing entire the page is a problem
... If you set [various combinations, varous results]
... Different fonts, different ways to read metrics from the font, different implementations of what 'line-height: normal'
... cause differences

dbaron: I'm not sure that even line-height: <number> is predictable, requires testing mix of elements

<dbaron> ... where some have font fallback

<dbaron> fantasai: another case that could cause problems is different line wrapping,e.g., if superscript and subscript end up on the same line

Florian: Point of feature is normalization of line heights so a few lines double-spaced probably okay, but all lines not good
... primary font doesn't have CJK and other font does, then many lines with mix of fonts
... line-height to specific number, it's okay
... but if you have spans in the middle of that, you might trigger problem often

<dbaron> fantasai: it's broken if the author sets something precisely expecting no gaps in the general case; they'll be upset if they see gaps

<dbaron> fantasai: you won't have a case that's extremely painful for the user

<Rossen> fantasai: it's definitely broken if the author didn't expect any gaps but there were some. If there are few gaps there shouldn't be that much of a confusion

astearns: author shouldn't use this if they can't stand occasional double spacing

jet: on dev.platform, was a question of whether authors really want this feature
... Haven't heard demand from authors outside Koji here in this room
... Do people want that

Florian: People do want vertical rhythm, absolutely

<myles_> jet++

jet: Chromium has it behind a flag, have people been building websites with it and saying "yes I absolutely want this", haven't really seen that

<jet> fantasai: people want vertical rhythm, but is this the feature that will solve it?

<jet> fantasai: we want this spec to be robust and integrate with the rest of CSS elegantly

<jet> fantasai: I don't think this feature fits that description

<myles_> fantasai++

<tantek> fantasai++

<dauwhe> fantasai+^+^+

fantasai: Our goal for features we design here in the CSSWG is to be flexible, robust, poweful, easy-to-use, and understandable
... We intend for them to fit within, integrate with, and enhance the CSS system
... Not be a hacky workaround to some particular issue
... I don't believe this feature fits that design requirement.
... Additionally, I don't think it does a good job of addressing the use cases
... Absolutely, people want control over vertical rhythm
... But their problems aren't largely about lines within a long wrapped paragaph of text being slightly off-kilter
... The breaks in rhythm are largely introduced by block-level interjections in the flow of text
... Things like headings, figures, tables, and block-quotes
... This feature does not address these use cases
... It at best allows a hack of turning these block-level elements into inline-blocks in order to use this feature to control rhythm.
... I don't believe this feature is well-designed.

astearns: I absolutely agree that block-level interjections are also a problem, but I don't agree that they're worse than line box stepping

<dbaron> fantasai: much of the jitter in line boxes is due to...

koji: I thought kobayashi-sensei explanation in Tokyo was more understood
... discussion wasn't
... what he said was what Alan said
... not sure about Latin, but for Japan
... what he said was when block-level interjection is big enough he wants other factors wins over getting back to original rhythm

astearns: my impression was that his opinion was that it was acceptable but still not enough

koji: I talked with ppl who attended, ppl agreed with me
... maybe translation problem
... What he explained was vertical wrhythm when objects intervene
... Should be done like justification, so that each text block and image and blockquote are like characters in the "line box" of the page
... each space to have equal lenght is more important than returning to the rhythm
... line grid can do it, or maybe other features, but then have to adjust grid after intervening objects
... but line-height-step or block-height-step doesn't have this problem
... What sensei didn't say, is making block height to step

dauwhe: A couple things, one is that I would love to see some East Asian examples of how this feature fixes problems of East Asian typography
... examples have been in Latin, so hard for us to see the goal of this feature as designed
... Also want to say that wrt Latin typesetting in general, I agree with fantasai
... Last thing we want to change is line height of the blocks. This is the worst result, lowest priority. Prefer to adjust spacing around blocks
... So I would like to see more targeted use cases for the case of East Asian, since in Latin this is not as appropriate

Florian: In Latin text, you have ascenders and descenders so the visual edges of the line is irregular
... Whereas in CJK if the spacing is irregular, it is very obvious
... So a small superscript that sticks out and slightly shifts the line is really bad

dauwhe: it's pretty bad in Latin, too

Florian: So that is one part
... Another response is to fantasai
... wrt her design goals of CSS
... Early incarnations of this feature were very much not robust
... We have made changes to decrease its powerfulness to increase its robustness
... I don't think it's robust enough yet
... When I'm done with fixing interop on line height, then will look at robustness of this feature
... I'm not sure we can make this feature robust enough, but either way this depends on how we fix interop of line height calculations

koji: We seem to be discussing two topics, one is fundamental design and the other is this problem of oduble spacing

Florian: The design of this feature makes it easy to use in some cases and very broken in others. If we can't fix this, we can't use this feature

koji: Fundamental to vetical rhythm that some authors want to take as much step as font metrics says
... if font is taller, want to take more steps, as much as needed to fit font
... whereas in some cases we consider accidental
... and that happens in line grid, too

astearns: Same concern about accidental double spacing of everything is a problem both for rhythm and for line grid
... and we can't take either of the proposals if accidental double spacing of everything is prevalent enough to be a problem
... Accidental double spacing is prime example of the design flaw
... still talking about double spacing

koji: what if double spacing happens in line grid, too?

myles_: I don't think anyone has made the argument that line grid should ship instead of this
... people are simply objecting to this feature on its own merits

(or lack thereof)

Rossen: First comment about jet's comments
... What jet mentioned earlier about lack of examples / requests, we've had a lot of requests internally
... mostly ppl building multicol based layouts
... fairly impossible to make things align in terms of line breaks
... To that point, what fantasai said earlier whas right on the money
... Most of the problems aren't due to lines, they're mostly due to headings and other blocks that are not multiples of line height

<astearns> headings are not lines?

astearns, no, but I can't explain and minute...

:/

<astearns> (I know they're blocks)

<dbaron> Florian: his comment was looking for evidence that tjet's particular solution addresses the use case, not evidence that the use case was important

Rossen: I was hoping to know, it's been already 1.5-2yrs that we've been working on this

<tantek> q

Rossen: It's certainly the case that in CJK the use cases seem to be predominatnly based on just lines and line sof text without that much blocks or other things int he flow that contribute to irregularity
... in those coases perhaps line grid makes sense, maybe that's the best thing to do there
... at the same time, most of the objections I hear constantly against it
... are based on the other sets of requirements
... which are for multicol block-level stuff we were talking about

fantasai: No, there's two sets of objections one is the block-level concerns the other is the robustness concerns

<TabAtkins> ScribeNick: TabAtkins

fantasai: part of the robustness concerns is all this non-interop stuff for line-height in general is part of it
... Other thing is that the way we do line-height calcs in general creates jitter.
... So even if we have line boxes with same height, that doesn't the jitter case that CJK needs us to solve.
... So even without browser variance, even with a strict vertical rhythm, within the linebox the line moves, and line-height-step doesn't fix that.

<myles_> Rossen: Many of the requests that we (Microsoft) has had for this style of feature are caused by interjecting blocks in between many flowing lines of text. [myles: therefore those aren't solved by this particular solution]

fantasai: So if your concern is within a paragraph keeping a rhythm, we need to fix interop *and* maintain the baseline-to-baseline height.
... Beacuse of the way we center content in the linebox, if the content is slightly larger but doens't spill out of th elinebox, it'll jitter.

koji: If you solve that, even when you do, if the font-size is differnet, you'll still need line-height step.
... So it doesn't seem to be a reason not to do line-height-step.

fantasai: The only case you need l-h-s is if, in the middle of a paragraph, you want to double-size a particular line because it includes larger content.

<Zakim> tantek, you wanted to ask how long has Chrome been shipping it behind a flag? and shouldn't we see at least experimental sites using that in the wild by now?

<dbaron> I could bring back line-box-contain with stepping extensions that I think would be more robust, at least for some values of line-box-contain.

tantek: How long has Chrome been shipping this behidn a flag?

koji: a year or so

tantek: For a feature we all agree conceptually there's demand for, we should have seen at least a handful of experimental demo sites using them.
... We haven't seen that, or if we have, please provide the urls.
... Second is, I'm increasingly concerned with shipping features that *almost* work, but are fragile and easily break.
... Having witnessed all the float/columns confusion, having it break easily, that makes people distrust CSS as a whole.
... Would be unfortunate to have the whole concept damaged as a result.
... So that's why providing the block-level solutions might make it *just* dependenable enough to make it usable in production.
... It won't be perfect, but can it be *reliable enough*.

<fantasai> astearns, the reason I'm saying that headings aren't lines isn't that they aren't made up of lines, of course they are. But generally the problem isn't havng each individual line snap to a multiple of the base line height, it's having the heading as a whole snap to that multiple.

<fantasai> astearns, because for headings you don't want to have large line heights or gaps between the lines

<astearns> fantasai: let's talk about this after

koji: I tried to talk to some webdevs; my feeling so far is that the experimental flag buidling sites works in US, but not in intl, where pops are smaller and people are less willing to spend effort helping standardization.

<fantasai> astearns, you usually want them quite tightly spaced, in fact, because they are a larger font size

koji: So they generally say "we'll try when it ships, but can't spend much time before that".

<fantasai> astearns, but you want space around them, and you want the total space taken up by the heading -- like the total space taken up by a figure or table or blockquote -- to fit into the rhythm

koji: For robustness, as far as I understand, your "robustness" is different from fantasai's concept.

tantek: Could be.

koji: I think you're more about accidental jumping.
... I think earlier we were talkinga bout, when we get the future stack thing - if it gets off the grid, it accumulates.
... That part is design - Japanese vertical rhythm is different from Latin's.

Florian: Earlier fantasai was saying that this feature isn't quite good enough; while it solves locally the size of the line, it doesn't do the position.
... Earlier feature did address that, but made it more fragile.

astearns: It solved that using the baseline ratio.

Florian: So that's a bit of the difficulty with this feature.
... I haven't given up hope, but I don't know if at the end of the process it'll still be useful.
... Currently kinda useful and kinda fragile; was earlier more usefula nd more fragile; will it be useful at all?
... So we have a feature that's either too fragil eand not useful enough, or one that's too difficult to figure out.
... Otoh, there's a simple and useful feature that solves the block side of the problem, which we most agree isn't quite enough.
... But I don't think anybody thinks the block feature is insufficiently robust, or not useful.
... So I recommend people start on that, rather than being stuck.
... As to whether this is still useful when it's robust, dunno.
... IN parallel, I think it would be nice to try and make line-grid simpler in terms of impl.
... Nobody's been willing to bite the bullet yet.
... If someone can find a magic solution, prizes!

fantasai: I don't think that finding the third solution is as impossible as you think.
... First, we need to solve the jitter problem.
... We're wasting our time if we don't solve that.
... Requirement for any solution, and it's not specific to l-h-s or line-grid
... We just need to fix line layout.
... We need to continue and prioritize the work that florian has been doing, to fix line layout.
... Second, we need examples of where this specific feature is a solution to a problem.
... I think this is solving a problem of fixing line-heights within a wrapped paragraph, by doubling the spacing of that line, and I dont' think anyone wants taht in general.

dbaron: I think one thing we should look at to address this is having whatever the solution is be a bit more of a mode switch than what we're looking at.
... To some degree line-grid is such a mode switch.
... 14 years ago I had a proposal for line-box-contain, in the ED for linebox for a decade, shipping in Safari for a bit...
... That tried to add all the detail for how to consider what should affect the linebox.
... But to a good extent there's only three values that are important.
... One is what we do in quirks mode, one is what the specs say, one is what devs actually want.
... it's a little complicated, but it's in the spec, hard to find.

astearns: So in addition to box-sizing, we should have line-sizing?

dbaron: Not where I was going.
... One of the things is that you have a property that says "i want a line grid at a certain size". Whether it's a full-fledged grid or a slightly weaker thing.
... I suggest that, once that grid is established and for all the blocks that use it (presuming you can turn it off for some descendants), we switch line layout to another mode.
... WE stop stupid things, like honoring line-height on inlines.

<fantasai> dbaron+++++++++++++++++++++++++++++++++++++

myles_: +++++

<dauwhe> tell it, brother!

dbaron: Only honor line-height on boxes. Honor border or margin-box size on inlines, so if they actually overflow the line, they make it bigger.
... But if you're at line-height:1.25, you don't get the 1.25 buffer on them.
... And from there we can figure out baseline alignment to the grid.
... So I think having a non-inherited proeprty that establishes a line grid or step-sizing space, is better than an inherited mode switch, like line-box-contain was, because it serves another purpose as wlel.
... While it has some mode-switching purposes, mode-switches aren't that great. Doesn't cascade well.

<gsnedders> dbaron++++++++

dbaron: Has some of the effects of a mode switch, but not all of them.

iank_: A new inline layout...

dbaron: Not that different. Still doing inline layout.
... line-box-contain had a bunch of values that were like "block", "inline", "replaced", "text", "ruby", "glyphs"...
... When you did your linebox height calc, you looked at the list and only considered those.
... The standard behavior is "block inline repalced" i think

<Bert> https://www.w3.org/Style/Group/css3-src/css3-linebox/#LineStacking

dbaron: Quirks mode is more like "text replaced" or something
... But people don't really want inlines considered at all, you just don't want glyphs to overlap by default.
... The principle isn't complicated, it's just a new step in line layout that controls what you consider.
... The mode switch would be about changing what you consider in that step.

myles_: I think it's still in WK prefixed...

iank_: It's removed from Blink.

astearns: See if it helps enough for this use-case?

myles_: Which use case? ^_^

Florian: Having discussed a variant of this for several times, I think coming back in a few months with the same discsussion isn't helpful.
... I think it's clear that koji and fantasai disagree on whether robustness is important/etc.
... I think it's important if koji could show sites using this feature in ways that trigger double-spacing, and say "yes, this is what the author wants".

fantasai: No, you want sites using the feature that show why this is good, and the other alternatives can't solve it.

astearns: We want to evaluate the shipping solution, to see if it addresses the use-case.
... We have a shipping solution, we should have evidence that it's enough for some set of people.

Florian: And specifically, I want to see these examples hit the conrer cases, without authors getting bad results.

astearns: Whether the extant examples hit the corners or not, we can use them to push them into the corners.

Florian: Other than that, I don't think it'll be useful to have elika tell koji it's not useful, and koji saying it is...

koji: I'm saying tha trobustness is different between Latin and CJK.

Florian: Sure, I'm not trying to rephrase; it's just that rehashing the same discussion without new info isn't useful.
... In the meantime there are concrete things we can work on, like improving lineboxes. Maybe dbaron's stuff
... In the meantime just rehashing is harmful, it blocks us from doing similar things.

tantek: I think this conversation has brought up some new stuff.

fantasai: My and dbaron's points were brought up in Tokyo.

<Bert> (A public link: https://www.w3.org/TR/2001/WD-css3-box-20010726/#the-line-box-contain)

<gregwhitworth> Decent amount of vertical rhythm libs in CSS & JS: http://kyleshevlin.github.io/shevy/

tantek: I think some new stuff, like eamples that use it

astearns: And I think line-box-contain is new.

tantek: So I think it's not fair to say it's a complete rehash.

astearns: But I agree we need examples, "this community won't turn on a flag" isn't a good enough response.

koji: Why doesn't printed material show this?

astearns: We need examples of *this particular solution* trying to solve things.

Florian: Looking at print doesn't help here; it illustrates there is a problem to solve, but not that this solution in particular solves the problem.

koji: Word isn't print - if you look at a word doc with different installed fonts, you get a similar problem.

Florian: Usually that happens because of switching between Word and OpenOffice, and people hate it.
... I'm saying that showing examples of *other* things doesn't help us see if *your* solution solves stuff.

koji: If you require that of every i18n feature, we'll never get it done...

Florian: We're not asking for everything, just for controversial things.

myles_: And there's another possible solution - dbaron's l-b-c.

astearns: Even without another, this particular solution has enough controversy that we want to see successful use of it in the wild.

<myles_> I meant line-grid in addition do dbaron's idea

astearns: Anything else to go into?

<gregwhitworth> worth noting -webkit-line-grid is on chromestatus

<gregwhitworth> none of the rhythmic sizing props are

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

<gregwhitworth> ^not sure if chromestatus shows experimental flag items or not

koji: Yeah. There are mutliple issues in here.
... ONe issue has a proposed solution, shane and tab came up with.
... It's about avoiding accidental jumps.
... I undersatand it doesn't solve all, but I want people to udnerstand the proposal and see if it solves part of the problem.

<fantasai> TabAtkins: So the ultimate problem is that when line-height is normal, it's unpredictable

<fantasai> TabAtkins: So if you set a line-height-step anywhere near the normal value, might look good on your screen not on others'

<fantasai> TabAtkins: proposal is that if lineh-height is normal and result of that would give you a light-height stlightly over your normal line-height

<fantasai> TabAtkins: based on some UA threshold of fuzziness

<fantasai> TabAtkins: Instead of doubling spacing, reduce to line-height-step

<fantasai> TabAtkins: It should hopefully correct any accidental slight overlap that you run into

<fantasai> astearns: why UA-defined squishiness

<fantasai> TabAtkins: figure out the right value later

<fantasai> TabAtkins: if we can agree on one later, great, but otherwise don't want to sink the proposal by arguing over value right now

<fantasai> Florian: I believe I understand the proposal but don't understand why it helps

<fantasai> Florian: If one browser normal is slightly smaller than step, and in toher browser slightly larger, then it helps

<fantasai> Florian: But if in your browser it's slightly larger than normal, but in other browser it's even more larger than normal

<fantasai> Florian: then you get single spacing in yours and double sizing in the other

<fantasai> Florian: So it changes the numbers that trigger the problem, but it doesn't make the problem go away

<fantasai> TabAtkins: Think set of cases that get fixed are goingto be more common than set of things that get broken

<fantasai> TabAtkins: In order tog et broken as you say, you need to set line-height-step smaller than your line-height

<fantasai> fantasai: Line height normal is unpredictable though

<fantasai> Florian: Line height: normal isnt' between 1-1.2, it comes form the font. It might be 2.7

<fantasai> Florian: within i18n contexts it varies a lot, even though you don't see it that much in Latin (aside from fantasy fonts)

<fantasai> TabAtkins: Ignoring fantasy fonts and Zapfino

<fantasai> fantasai: i18n

<fantasai> TabAtkins: You said there's larger variation in the consequences of the line box size due to non-Latin character set default fonts

<fantasai> Florian: I believe so, and I think Koji claimed that before I did

<fantasai> fantasai: I suspect you're more likely ot get that variation in Tibetan and Thai and other fonts that have lots of diacritics

<fantasai> myles_: I agree that fuzzy matching is a good way to solve language problem

<fantasai> myles_: Implementation knows exactly where all the lines go, so implementation has all the information it needs

<fantasai> myles_: rather more than the author even, cuz author doesn't have font metrics

<fantasai> myles_: so reasonable to have implementation make lines fit well

<fantasai> myles_: previous conversation needs to be resolved before we take this though

<fantasai> TabAtkins: might want to evaluate solution with this in mind tho

<fantasai> koji: I agree with myles that the accidental jump issue has needs to deal with some heuristics

<fantasai> koji: because in some cases we want to squash really tall fonts

<fantasai> koji: implementation can experiment and maybe a few years later we find very good values and want to standardize it but at this point better to experiment and get feedback

<fantasai> astearns: your experimental implementation, if you can get people to use you can get data on utility of squishiness

<fantasai> koji: Does that solve previous concerns?

<fantasai> astearns: Would anyone object to experimenting with this?

<fantasai> astearns: 2nd, would squishiness as described make anyone more interested in this feature?

<fantasai> myles_: not for us

<fantasai> astearns: So this squishiness doesn't help other implementers be interested in line-height-step, but seem to be no objections to Google experimenting with it

<fantasai> Florian: No objection to experimentation, less certain about adding it to the spec

<fantasai> koji: If not in the spec, we can't ship it

<fantasai> Florian: I don't want to ship this without a flag unless we have strong evidence that it is less dangerous than people have expressed worries about

<fantasai> Florian: changes to the spec discussed so far don't make me convinced

<fantasai> koji: Why can't you at least suspect it helps?

<fantasai> Florian: I suspect it does not

<fantasai> Florian: I expect it breaks some fixes some and it's a wash

<fantasai> Florian: If it fixes lots and breaks few, pls demonstrate

<fantasai> myles_: Do we need a resolution for Chrome to experiment behind a flag?

<fantasai> Florian: No, they want it in the spec so they can ship it without a flag

<fantasai> astearns: They don't need our permission to experiment, would need permission to add it to the spec even though the consensus of the group is not that the feature is at a point that is OK to ship without a flag

<fantasai> koji: Issue was browsers hard-coded differences in line height calculations triggering different steps, we're trying to solve that, so Chrome doing it doesn't help

<fantasai> astearns: you didn't convince Florian, but myles seems to agree it might help

<fantasai> myles_:

<fantasai> s/myles_: please ignore me//

<fantasai> dbaron: I agree with Florian's concern that it seems to mostly be moving the threshold and not actually fixing the bug

<fantasai> Florian: I didn't mean that in the long run Chrome should have it and others shouldn't add it, I'm suggesting that the only implementation we have experiment

<fantasai> myles_: 100% of implementations will experiment

<fantasai> Florian: Add squishiness, come back and tell us if it improves the situation

<fantasai> fantasai: Koji's pointing out that we want to find out if there's a problem with interop. Chrome can't find a problem with interop by itself

<fantasai> TabAtkins: To simulate differences in how normal gets interpreted, swap around the font list.

<fantasai> fremy: Or switch from Mac to Windows

<fantasai> astearns: OK, think we're done with rhythm

<fantasai> Meeting closed.

<gsnedders> RRSAgent: stop logging

<gsnedders> RRSAgent: stop

This is scribe.perl Revision: 1.152  of Date: 2017/02/06 11:04:15  
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/(link)/https://tabatkins.github.io/specs/css-shadow-parts/
Succeeded: s/:theme/::theme/
Succeeded: s/TabAtkins: and then/astearns: and then/
Succeeded: s/route/root/
Succeeded: s/nigel_/myles/
Succeeded: s/?/requirement/
Succeeded: s/syntax map, and semantics/semantics map, and syntax/
Succeeded: s/CSS/browser/
Succeeded: s/line box/line height box of the inline that's used for layout/
Succeeded: s/kochi/koji/
Succeeded: s/not./not?/
Succeeded: s/investigate it/investigate it, I want to make this work/
Succeeded: s/CSS3/fantasai: CSS3/
Succeeded: s/end edge/end side of resolved bidi direction/
Succeeded: s/there will be a big space/there will not be a big space, they'll be collapsed visually/
Succeeded: s/writing modes/variables/
Succeeded: s/contstant/constant/
Succeeded: s/would be color/would be cool/
Succeeded: s/as a user, I'd/as an author, I'd/
Succeeded: s/1969/1696/
Succeeded: s/whatever/pretty much whatever/
Succeeded: s/them to/them to do at this point/
Succeeded: s/due/do/
Succeeded: s/Resolved/RESOLVED/
Succeeded: s/difficult/annoying/
Succeeded: s/authors/authors during the transition/
Succeeded: s/microsoft can do this/microsoft can do this by not shipping grid-*-gap/
Succeeded: s/we'll ship very soon/when we ship/
Succeeded: s/this/this kind of integration/
Succeeded: s/CLJK/CJKlreq/
Succeeded: s/accent marks/accent marks not hanging out of the background/
Succeeded: s/script-specific issues/that might be more important for Vietnamese than for English/
Succeeded: s/[?]/double-spacing/
Succeeded: s/dbaron: Same/koji: Same/
Succeeded: s/ ? / result /
Succeeded: s/dauwhe: ?/dauwhe: are you concerned about just the inline step sizing, or all of css rhythm?/
Succeeded: s/don't want/can't stand occasional/
Succeeded: s/his/jet's/
Succeeded: s/center/jitter/
Succeeded: s/Which/Which use case/
Succeeded: s/aren't necessary/can't solve it/
Succeeded: s/objecting/experimenting/
Succeeded: s/please ignore me//
FAILED: s/myles_: please ignore me//
Present: tantek melanierichards bdc nainar myles
Found ScribeNick: tantek
Found ScribeNick: fantasai
Found ScribeNick: TabAtkins
Found ScribeNick: dauwhe
Found ScribeNick: fantasai
Found ScribeNick: TabAtkins
Inferring Scribes: tantek, fantasai, TabAtkins, dauwhe
Scribes: tantek, fantasai, TabAtkins, dauwhe
ScribeNicks: tantek, fantasai, TabAtkins, dauwhe

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

Found Date: 04 Aug 2017
People with action items: fantasai florian