- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Fri, 04 Aug 2017 15:53:24 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `CSS Rhythm`. <details><summary>The full IRC log of that discussion</summary> <jet> Topic: CSS Rhythm<br> <astearns> https://groups.google.com/forum/#!msg/mozilla.dev.platform/cnEN_sccXJY/1ddo5XifAwAJ<br> <fantasai> ScribeNick: fantasai<br> <fantasai> koji: I'd like dbaron to explain his opinion<br> <fantasai> dbaron: Current approaches are going to lead to things that are fragile wrt behavior between browsers, or even same browser on different platforms<br> <fantasai> dbaron: where you get double-spacing of line sin unpredictable situations<br> <fantasai> dbaron: There are alternative approaches which would not lead to this problem<br> <fantasai> dbaron: But I'm not interested in focusing on this right now<br> <fantasai> dauwhe: ?<br> <fantasai> dbaron: Right now not looking at anything<br> <fantasai> dbaron: I'm discouraging ppl from implementing this feature because I don't think it's something that should be implemented<br> <fantasai> dbaron: Same issue as [?]<br> <astearns> s/[?]/double-spacing/<br> <fantasai> 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<br> <astearns> s/dbaron: Same/koji: Same/<br> <fantasai> koji: Your concern is different font metrics causing different ? is the problem?<br> <fantasai> s/ ? / result /<br> <dauwhe> s/dauwhe: ?/dauwhe: are you concerned about just the inline step sizing, or all of css rhythm?<br> <fantasai> koji: Original issue was line-height normal causing problems<br> <fantasai> Florian: There's a general problem and a specific case of that problem<br> <fantasai> Florian: 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<br> <fantasai> Florian: and to be entirely double-spaced or randomly double-spaced in another browser<br> <fantasai> Florian: That's the general worry<br> <dbaron> or different font availability<br> <fantasai> Florian: within that space, this github issue identifies one case where this happens<br> <fantasai> Florian: if this is the only case where this happens, maybe dbaron's worry goes away<br> <fantasai> Florian: If there are more instances of similar worries, we'll need lots of patches<br> <fantasai> dbaron: Another major case is font availability, where you have a font available on one platform and not on others<br> <fantasai> koji: I heard one example<br> <fantasai> koji: but dbaron's concern seems to be a different case<br> <fantasai> Florian: it's the same<br> <fantasai> Florian: if line-height-step is a user-defined specific value<br> <fantasai> Florian: and line-height is a different user-defined value<br> <fantasai> Florian: then this is generally predictable<br> <myles_> q+<br> <fantasai> Florian: if line-height is smaller than line-height-step generally okay<br> <fantasai> Florian: If there's one line that has a superscript and double spaced that line it's kindof okay<br> <fantasai> Florian: but double-spacing entire the page is a problem<br> <fantasai> Florian: If you set [various combinations, varous results]<br> <fantasai> Florian: Different fonts, different ways to read metrics from the font, different implementations of what 'line-height: normal'<br> <fantasai> Florian: cause differences<br> <myles_> q-<br> <fantasai> dbaron: I'm not sure that even line-height: <number> is predictable, requires testing mix of elements<br> <dbaron> ... where some have font fallback<br> <dbaron> fantasai: another case that could cause problems is different line wrapping,e.g., if superscript and subscript end up on the same line<br> <fantasai> Florian: Point of feature is normalization of line heights so a few lines double-spaced probably okay, but all lines not good<br> <fantasai> Florian: primary font doesn't have CJK and other font does, then many lines with mix of fonts<br> <fantasai> Florian: line-height to specific number, it's okay<br> <fantasai> Florian: but if you have spans in the middle of that, you might trigger problem often<br> <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<br> <dbaron> fantasai: you won't have a case that's extremely painful for the user<br> <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<br> <fantasai> astearns: author shouldn't use this if they don't want double spacing<br> <fantasai> jet: on dev.platform, was a question of whether authors really want this feature<br> <fantasai> q+<br> <astearns> s/don't want/can't stand occasional/<br> <fantasai> jet: Haven't heard demand from authors outside Koji here in this room<br> <fantasai> jet: Do people want that<br> <fantasai> Florian: People do want vertical rhythm, absolutely<br> <myles_> jet++<br> <fantasai> 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<br> <astearns> ack fantasai<br> <jet> fantasai: people want vertical rhythm, but is this the feature that will solve it?<br> <jet> fantasai: we want this spec to be robust and integrate with the rest of CSS elegantly<br> <jet> fantasai: I don't think this feature fits that description<br> <myles_> fantasai++<br> <tantek> fantasai++<br> <dauwhe> fantasai+^+^+<br> <fantasai> fantasai: Our goal for features we design here in the CSSWG is to be flexible, robust, poweful, easy-to-use, and understandable<br> <fantasai> fantasai: We intend for them to fit within, integrate with, and enhance the CSS system<br> <fantasai> fantasai: Not be a hacky workaround to some particular issue<br> <fantasai> fantasai: I don't believe this feature fits that design requirement.<br> <fantasai> fantasai: Additionally, I don't think it does a good job of addressing the use cases<br> <fantasai> fantasai: Absolutely, people want control over vertical rhythm<br> <fantasai> fantasai: But their problems aren't largely about lines within a long wrapped paragaph of text being slightly off-kilter<br> <fantasai> fantasai: The breaks in rhythm are largely introduced by block-level interjections in the flow of text<br> <fantasai> fantasai: Things like headings, figures, tables, and block-quotes<br> <fantasai> fantasai: This feature does not address these use cases<br> <dauwhe> q+<br> <fantasai> fantasai: It at best allows a hack of turning these block-level elements into inline-blocks in order to use this feature to control rhythm.<br> <fantasai> fantasai: I don't believe this feature is well-designed.<br> <Florian> q+<br> <fantasai> 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<br> <dbaron> fantasai: much of the jitter in line boxes is due to...<br> <tantek> q?<br> <astearns> ack dauwhe<br> <fantasai> koji: I thought kobayashi-sensei explanation in Tokyo was more understood<br> <fantasai> koji: discussion wasn't<br> <fantasai> koji: what he said was what Alan said<br> <fantasai> koji: not sure about Latin, but for Japan<br> <Rossen> q+<br> <fantasai> koji: what he said was when block-level interjection is big enough he wants other factors wins over getting back to original rhythm<br> <fantasai> astearns: my impression was that his opinion was that it was acceptable but still not enough<br> <fantasai> koji: I talked with ppl who attended, ppl agreed with me<br> <fantasai> koji: maybe translation problem<br> <fantasai> koji: What he explained was vertical wrhythm when objects intervene<br> <fantasai> koji: Should be done like justification, so that each text block and image and blockquote are like characters in the "line box" of the page<br> <fantasai> koji: each space to have equal lenght is more important than returning to the rhythm<br> <fantasai> koji: line grid can do it, or maybe other features, but then have to adjust grid after intervening objects<br> <Rossen> q-<br> <fantasai> koji: but line-height-step or block-height-step doesn't have this problem<br> <fantasai> koji: What sensei didn't say, is making block height to step<br> <fantasai> 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<br> <fantasai> dauwhe: examples have been in Latin, so hard for us to see the goal of this feature as designed<br> <fantasai> dauwhe: Also want to say that wrt Latin typesetting in general, I agree with fantasai<br> <fantasai> dauwhe: 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<br> <astearns> ack Florian<br> <fantasai> dauwhe: So I would like to see more targeted use cases for the case of East Asian, since in Latin this is not as appropriate<br> <fantasai> Florian: In Latin text, you have ascenders and descenders so the visual edges of the line is irregular<br> <fantasai> Florian: Whereas in CJK if the spacing is irregular, it is very obvious<br> <Rossen> q?<br> <fantasai> Florian: So a small superscript that sticks out and slightly shifts the line is really bad<br> <fantasai> dauwhe: it's pretty bad in Latin, too<br> <Rossen> q+<br> <fantasai> Florian: So that is one part<br> <fantasai> Florian: Another response is to fantasai<br> <fantasai> Florian: wrt her design goals of CSS<br> <fantasai> Florian: Early incarnations of this feature were very much not robust<br> <fantasai> Florian: We have made changes to decrease its powerfulness to increase its robustness<br> <fantasai> Florian: I don't think it's robust enough yet<br> <fantasai> Florian: When I'm done with fixing interop on line height, then will look at robustness of this feature<br> <fantasai> Florian: 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<br> <fantasai> koji: We seem to be discussing two topics, one is fundamental design and the other is this problem of oduble spacing<br> <fantasai> 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<br> <fantasai> koji: Fundamental to vetical rhythm that some authors want to take as much step as font metrics says<br> <fantasai> koji: if font is taller, want to take more steps, as much as needed to fit font<br> <fantasai> koji: whereas in some cases we consider accidental<br> <fantasai> koji: and that happens in line grid, too<br> <Rossen> q?<br> <fantasai> astearns: Same concern about accidental double spacing of everything is a problem both for rhythm and for line grid<br> <fantasai> astearns: and we can't take either of the proposals if accidental double spacing of everything is prevalent enough to be a problem<br> <fantasai> astearns: Accidental double spacing is prime example of the design flaw<br> <fantasai> astearns: still talking about double spacing<br> <fantasai> koji: what if double spacing happens in line grid, too?<br> <fantasai> myles_: I don't think anyone has made the argument that line grid should ship instead of this<br> <fantasai> myles_: people are simply objecting to this feature on its own merits<br> <astearns> ack Rossen<br> <fantasai> (or lack thereof)<br> <fantasai> Rossen: First comment about jet's comments<br> <fantasai> Rossen: What jet mentioned earlier about lack of examples / requests, we've had a lot of requests internally<br> <fantasai> Rossen: mostly ppl building multicol based layouts<br> <fantasai> Rossen: fairly impossible to make things align in terms of line breaks<br> <fantasai> Rossen: To that point, what fantasai said earlier whas right on the money<br> <fantasai> Rossen: 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<br> <astearns> headings are not lines?<br> <fantasai> astearns, no, but I can't explain and minute...<br> <fantasai> :/<br> <astearns> (I know they're blocks)<br> <dbaron> Florian: his comment was looking for evidence that this particular solution addresses the use case, not evidence that the use case was important<br> <dbaron> s/his/jet's/<br> <fantasai> Rossen: I was hoping to know, it's been already 1.5-2yrs that we've been working on this<br> <tantek> q<br> <tantek> q?<br> <fantasai> 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<br> <fantasai> Rossen: in those coases perhaps line grid makes sense, maybe that's the best thing to do there<br> <fantasai> Rossen: at the same time, most of the objections I hear constantly against it<br> <tantek> q+ 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?<br> <fantasai> Rossen: are based on the other sets of requirements<br> <fantasai> Rossen: which are for multicol block-level stuff we were talking about<br> <fantasai> fantasai: No, there's two sets of objections one is the block-level concerns the other is the robustness concerns<br> <TabAtkins> ScribeNick: TabAtkins<br> <TabAtkins> fantasai: part of the robustness concerns is all this non-interop stuff for line-height in general is part of it<br> <TabAtkins> fantasai: Other thing is that the way we do line-height calcs in general creates jitter.<br> <TabAtkins> fantasai: So even if we have line boxes with same height, that doesn't the jitter case that CJK needs us to solve.<br> <TabAtkins> fantasai: 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.<br> <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]<br> <TabAtkins> fantasai: So if your concern is within a paragraph keeping a rhythm, we need to fix interop *and* maintain the baseline-to-baseline height.<br> <Florian> q+<br> <TabAtkins> fantasai: 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 center.<br> <fantasai> s/center/jitter/<br> <TabAtkins> koji: If you solve that, even when you do, if the font-size is differnet, you'll still need line-height step.<br> <TabAtkins> koji: So it doesn't seem to be a reason not to do line-height-step.<br> <TabAtkins> 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.<br> <fantasai> q+<br> <astearns> ack tantek<br> <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?<br> <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.<br> <TabAtkins> tantek: How long has Chrome been shipping this behidn a flag?<br> <TabAtkins> koji: a year or so<br> <TabAtkins> 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.<br> <TabAtkins> tantek: We haven't seen that, or if we have, please provide the urls.<br> <TabAtkins> tantek: Second is, I'm increasingly concerned with shipping features that *almost* work, but are fragile and easily break.<br> <TabAtkins> tantek: Having witnessed all the float/columns confusion, having it break easily, that makes people distrust CSS as a whole.<br> <TabAtkins> tantek: Would be unfortunate to have the whole concept damaged as a result.<br> <TabAtkins> tantek: So that's why providing the block-level solutions might make it *just* dependenable enough to make it usable in production.<br> <TabAtkins> tantek: It won't be perfect, but can it be *reliable enough*.<br> <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.<br> <fantasai> astearns, because for headings you don't want to have large line heights or gaps between the lines<br> <astearns> fantasai: let's talk about this after<br> <TabAtkins> 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.<br> <fantasai> astearns, you usually want them quite tightly spaced, in fact, because they are a larger font size<br> <TabAtkins> koji: So they generally say "we'll try when it ships, but can't spend much time before that".<br> <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<br> <TabAtkins> koji: For robustness, as far as I understand, your "robustness" is different from fantasai's concept.<br> <TabAtkins> tantek: Could be.<br> <TabAtkins> koji: I think you're more about accidental jumping.<br> <TabAtkins> koji: I think earlier we were talkinga bout, when we get the future stack thing - if it gets off the grid, it accumulates.<br> <TabAtkins> koji: That part is design - Japanese vertical rhythm is different from Latin's.<br> <astearns> ack Florian<br> <TabAtkins> 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.<br> <TabAtkins> Florian: Earlier feature did address that, but made it more fragile.<br> <TabAtkins> astearns: It solved that using the baseline ratio.<br> <TabAtkins> Florian: So that's a bit of the difficulty with this feature.<br> <TabAtkins> Florian: I haven't given up hope, but I don't know if at the end of the process it'll still be useful.<br> <TabAtkins> Florian: Currently kinda useful and kinda fragile; was earlier more usefula nd more fragile; will it be useful at all?<br> <TabAtkins> Florian: So we have a feature that's either too fragil eand not useful enough, or one that's too difficult to figure out.<br> <TabAtkins> Florian: Otoh, there's a simple and useful feature that solves the block side of the problem, which we most agree isn't quite enough.<br> <TabAtkins> Florian: But I don't think anybody thinks the block feature is insufficiently robust, or not useful.<br> <TabAtkins> Florian: So I recommend people start on that, rather than being stuck.<br> <TabAtkins> Florian: As to whether this is still useful when it's robust, dunno.<br> <TabAtkins> Florian: IN parallel, I think it would be nice to try and make line-grid simpler in terms of impl.<br> <TabAtkins> Florian: Nobody's been willing to bite the bullet yet.<br> <TabAtkins> Florian: If someone can find a magic solution, prizes!<br> <TabAtkins> fantasai: I don't think that finding the third solution is as impossible as you think.<br> <dbaron> q+<br> <TabAtkins> fantasai: First, we need to solve the jitter problem.<br> <TabAtkins> fantasai: We're wasting our time if we don't solve that.<br> <TabAtkins> fantasai: Requirement for any solution, and it's not specific to l-h-s or line-grid<br> <TabAtkins> fantasai: We just need to fix line layout.<br> <TabAtkins> fantasai: We need to continue and prioritize the work that florian has been doing, to fix line layout.<br> <TabAtkins> fantasai: Second, we need examples of where this specific feature is a solution to a problem.<br> <astearns> ack fantasai<br> <TabAtkins> fantasai: 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.<br> <astearns> ack dbaron<br> <TabAtkins> 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.<br> <TabAtkins> dbaron: To some degree line-grid is such a mode switch.<br> <TabAtkins> dbaron: 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...<br> <TabAtkins> dbaron: That tried to add all the detail for how to consider what should affect the linebox.<br> <TabAtkins> dbaron: But to a good extent there's only three values that are important.<br> <TabAtkins> dbaron: One is what we do in quirks mode, one is what the specs say, one is what devs actually want.<br> <TabAtkins> dbaron: it's a little complicated, but it's in the spec, hard to find.<br> <TabAtkins> astearns: So in addition to box-sizing, we should have line-sizing?<br> <TabAtkins> dbaron: Not where I was going.<br> <TabAtkins> dbaron: 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.<br> <TabAtkins> dbaron: 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.<br> <TabAtkins> dbaron: WE stop stupid things, like honoring line-height on inlines.<br> <fantasai> dbaron+++++++++++++++++++++++++++++++++++++<br> <TabAtkins> myles_: +++++<br> <dauwhe> tell it, brother!<br> <TabAtkins> 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.<br> <TabAtkins> dbaron: But if you're at line-height:1.25, you don't get the 1.25 buffer on them.<br> <TabAtkins> dbaron: And from there we can figure out baseline alignment to the grid.<br> <TabAtkins> dbaron: 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.<br> <TabAtkins> dbaron: While it has some mode-switching purposes, mode-switches aren't that great. Doesn't cascade well.<br> <gsnedders> dbaron++++++++<br> <TabAtkins> dbaron: Has some of the effects of a mode switch, but not all of them.<br> <TabAtkins> iank_: A new inline layout...<br> <TabAtkins> dbaron: Not that different. Still doing inline layout.<br> <TabAtkins> dbaron: line-box-contain had a bunch of values that were like "block", "inline", "replaced", "text", "ruby", "glyphs"...<br> <TabAtkins> dbaron: When you did your linebox height calc, you looked at the list and only considered those.<br> <TabAtkins> dbaron: The standard behavior is "block inline repalced" i think<br> <Bert> https://www.w3.org/Style/Group/css3-src/css3-linebox/#LineStacking<br> <TabAtkins> dbaron: Quirks mode is more like "text replaced" or something<br> <TabAtkins> dbaron: But people don't really want inlines considered at all, you just don't want glyphs to overlap by default.<br> <TabAtkins> dbaron: The principle isn't complicated, it's just a new step in line layout that controls what you consider.<br> <TabAtkins> dbaron: The mode switch would be about changing what you consider in that step.<br> <TabAtkins> myles_: I think it's still in WK prefixed...<br> <TabAtkins> iank_: It's removed from Blink.<br> <TabAtkins> astearns: See if it helps enough for this use-case?<br> <TabAtkins> myles_: Which? ^_^<br> <Florian> q+<br> <fantasai> s/Which/Which use case/<br> <TabAtkins> 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.<br> <TabAtkins> Florian: I think it's clear that koji and fantasai disagree on whether robustness is important/etc.<br> <TabAtkins> Florian: 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".<br> <TabAtkins> fantasai: No, you want sites using the feature that show why this is good, and the other alternatives aren't necessary.<br> <TabAtkins> astearns: We want to evaluate the shipping solution, to see if it addresses the use-case.<br> <TabAtkins> astearns: We have a shipping solution, we should have evidence that it's enough for some set of people.<br> <TabAtkins> Florian: And specifically, I want to see these examples hit the conrer cases, without authors getting bad results.<br> <TabAtkins> astearns: Whether the extant examples hit the corners or not, we can use them to push them into the corners.<br> <fantasai> s/aren't necessary/can't solve it/<br> <TabAtkins> 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...<br> <TabAtkins> koji: I'm saying tha trobustness is different between Latin and CJK.<br> <TabAtkins> Florian: Sure, I'm not trying to rephrase; it's just that rehashing the same discussion without new info isn't useful.<br> <TabAtkins> Florian: In the meantime there are concrete things we can work on, like improving lineboxes. Maybe dbaron's stuff<br> <TabAtkins> Florian: In the meantime just rehashing is harmful, it blocks us from doing similar things.<br> <TabAtkins> tantek: I think this conversation has brought up some new stuff.<br> <TabAtkins> fantasai: My and dbaron's points were brought up in Tokyo.<br> <Bert> (A public link: https://www.w3.org/TR/2001/WD-css3-box-20010726/#the-line-box-contain )<br> <gregwhitworth> Decent amount of vertical rhythm libs in CSS & JS: http://kyleshevlin.github.io/shevy/<br> <TabAtkins> tantek: I think some new stuff, like eamples that use it<br> <TabAtkins> astearns: And I think line-box-contain is new.<br> <TabAtkins> tantek: So I think it's not fair to say it's a complete rehash.<br> <TabAtkins> astearns: But I agree we need examples, "this community won't turn on a flag" isn't a good enough response.<br> <TabAtkins> koji: Why doesn't printed material show this?<br> <TabAtkins> astearns: We need examples of *this particular solution* trying to solve things.<br> <TabAtkins> 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.<br> <TabAtkins> koji: Word isn't print - if you look at a word doc with different installed fonts, you get a similar problem.<br> <TabAtkins> Florian: Usually that happens because of switching between Word and OpenOffice, and people hate it.<br> <TabAtkins> Florian: I'm saying that showing examples of *other* things doesn't help us see if *your* solution solves stuff.<br> <TabAtkins> koji: If you require that of every i18n feature, we'll never get it done...<br> <TabAtkins> Florian: We're not asking for everything, just for controversial things.<br> <TabAtkins> myles_: And there's another possible solution - dbaron's l-b-c.<br> <TabAtkins> astearns: Even without another, this particular solution has enough controversy that we want to see successful use of it in the wild.<br> <myles_> I meant line-grid in addition do dbaron's idea<br> <TabAtkins> astearns: Anything else to go into?<br> <gregwhitworth> worth noting -webkit-line-grid is on chromestatus<br> <gregwhitworth> none of the rhythmic sizing props are<br> <TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/938<br> <gregwhitworth> ^not sure if chromestatus shows experimental flag items or not<br> <TabAtkins> koji: Yeah. There are mutliple issues in here.<br> <TabAtkins> koji: ONe issue has a proposed solution, shane and tab came up with.<br> <TabAtkins> koji: It's about avoiding accidental jumps.<br> <TabAtkins> koji: I undersatand it doesn't solve all, but I want people to udnerstand the proposal and see if it solves part of the problem.<br> <fantasai> TabAtkins: So the ultimate problem is that when line-height is normal, it's unpredictable<br> <fantasai> TabAtkins: So if you set a line-height-step anywhere near the normal value, might look good on your screen not on others'<br> <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<br> <fantasai> TabAtkins: based on some UA threshold of fuzziness<br> <fantasai> TabAtkins: Instead of doubling spacing, reduce to line-height-step<br> <fantasai> TabAtkins: It should hopefully correct any accidental slight overlap that you run into<br> <fantasai> astearns: why UA-defined squishiness<br> <fantasai> TabAtkins: figure out the right value later<br> <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<br> <fantasai> Florian: I believe I understand the proposal but don't understand why it helps<br> <fantasai> Florian: If one browser normal is slightly smaller than step, and in toher browser slightly larger, then it helps<br> <fantasai> Florian: But if in your browser it's slightly larger than normal, but in other browser it's even more larger than normal<br> <fantasai> Florian: then you get single spacing in yours and double sizing in the other<br> <fantasai> Florian: So it changes the numbers that trigger the problem, but it doesn't make the problem go away<br> <fantasai> TabAtkins: Think set of cases that get fixed are goingto be more common than set of things that get broken<br> <fantasai> TabAtkins: In order tog et broken as you say, you need to set line-height-step smaller than your line-height<br> <fantasai> fantasai: Line height normal is unpredictable though<br> <fantasai> Florian: Line height: normal isnt' between 1-1.2, it comes form the font. It might be 2.7<br> <myles_> q+<br> <fantasai> Florian: within i18n contexts it varies a lot, even though you don't see it that much in Latin (aside from fantasy fonts)<br> <koji> q+<br> <fantasai> TabAtkins: Ignoring fantasy fonts and Zapfino<br> <astearns> ack Florian<br> <fantasai> fantasai: i18n<br> <fantasai> TabAtkins: You said there's larger variation in the consequences of the line box size due to non-Latin character set default fonts<br> <fantasai> Florian: I believe so, and I think Koji claimed that before I did<br> <astearns> ack myles_<br> <fantasai> fantasai: I suspect you're more likely ot get that variation in Tibetan and Thai and other fonts that have lots of diacritics<br> <fantasai> myles_: I agree that fuzzy matching is a good way to solve language problem<br> <fantasai> myles_: Implementation knows exactly where all the lines go, so implementation has all the information it needs<br> <fantasai> myles_: rather more than the author even, cuz author doesn't have font metrics<br> <fantasai> myles_: so reasonable to have implementation make lines fit well<br> <fantasai> myles_: previous conversation needs to be resolved before we take this though<br> <astearns> ack koji<br> <fantasai> TabAtkins: might want to evaluate solution with this in mind tho<br> <fantasai> koji: I agree with myles that the accidental jump issue has needs to deal with some heuristics<br> <fantasai> koji: because in some cases we want to squash really tall fonts<br> <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<br> <fantasai> astearns: your experimental implementation, if you can get people to use you can get data on utility of squishiness<br> <fantasai> koji: Does that solve previous concerns?<br> <fantasai> astearns: Would anyone object to objecting with this?<br> <fantasai> astearns: 2nd, would squishiness as described make anyone more interested in this feature?<br> <fantasai> myles_: not for us<br> <astearns> s/objecting/experimenting/<br> <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<br> <fantasai> Florian: No objection to experimentation, less certain about adding it to the spec<br> <fantasai> koji: If not in the spec, we can't ship it<br> <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<br> <fantasai> Florian: changes to the spec discussed so far don't make me convinced<br> <fantasai> koji: Why can't you at least suspect it helps?<br> <fantasai> Florian: I suspect it does not<br> <fantasai> Florian: I expect it breaks some fixes some and it's a wash<br> <fantasai> Florian: If it fixes lots and breaks few, pls demonstrate<br> <fantasai> myles_: Do we need a resolution for Chrome to experiment behind a flag?<br> <fantasai> Florian: No, they want it in the spec so they can ship it without a flag<br> <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<br> <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<br> <fantasai> astearns: you didn't convince Florian, but myles seems to agree it might help<br> <fantasai> myles_: please ignore me<br> <myles_> s/please ignore me//<br> <fantasai> s/myles_: please ignore me//<br> <fantasai> dbaron: I agree with Florian's concern that it seems to mostly be moving the threshold and not actually fixing the bug<br> <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<br> <fantasai> myles_: 100% of implementations will experiment<br> <fantasai> Florian: Add squishiness, come back and tell us if it improves the situation<br> <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<br> <fantasai> TabAtkins: To simulate differences in how normal gets interpreted, swap around the font list.<br> <fantasai> fremy: Or switch from Mac to Windows<br> <fantasai> astearns: OK, think we're done with rhythm<br> <fantasai> Meeting closed.<br> <gsnedders> RRSAgent: stop logging<br> <RRSAgent> I'm logging. I don't understand 'stop logging', gsnedders. Try /msg RRSAgent help<br> <gsnedders> RRSAgent: stop<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/938#issuecomment-320284782 using your GitHub account
Received on Friday, 4 August 2017 15:53:26 UTC