w3 :: #css

20 Apr 2017
00:06astearnsjack: Hiroshi says 6:30
00:07mylesHello, everyone!
00:07astearnstrackbot, start meeting
00:07* trackbot is preparing a teleconference.
00:07RRSAgentlogging to http://www.w3.org/2017/04/20-css-irc
00:07trackbotRRSAgent, make logs public
00:07RRSAgentI have made the request, trackbot
00:07trackbotZakim, this will be Style_CSS FP
00:07Zakimok, trackbot
00:07trackbotMeeting: Cascading Style Sheets (CSS) Working Group Teleconference
00:07trackbotDate: 20 April 2017
00:10iank_Topic: Repeated headers and Footers
00:10iank_Florian: Tables are special, table headers and footers repeat across headers.
00:10iank_Florian: Sometimes you want these on other things apart from tables
00:10iank_scribenick: iank_
00:11iank_Florian: So Based on a need in a vivliostyle project, we'd like to generalize this, and can be applied to things other than tables.
00:11iank_Florian: So the stand-in name is repeat-on-break
00:11iank_Florian: Only applies to one element, ignores other elements which have this property.
00:12* dbaron AmeliaBR, the transforms discussion is happening in #fx
00:12iank_Florian: First repeatable footer will move to the bottom, first repeatable header will move to the top.
00:12iank_Florian: This follows tables, that the basic idea.
00:13iank_Florian: So we've implemented this, its early, but its possible, we find this useful, I'd be interested in having an editors draft.
00:13iank_Florian: Most useful if you do a lot of fragmentation.
00:13iank_Florian: Parts of the tables spec could be offloaded to this.
00:14iank_plinss: If we can explain the current magic of tables with a UA stylesheet instead of auto?
00:14iank_Florian: I remember thinking about this, i can't remember why we went for auto.
00:14iank_Florian: I'll need to think slowly through it, but if it can be done, why not?
00:15iank_Florian: One advantage of the auto keyword it allows you do to a lvl 0 implementation.
00:15iank_plinss: I don't know what your syntax looks like, but would be nice.
00:15astearnsq+ tantek
00:15* Zakim sees tantek on the speaker queue
00:15iank_Florian: <explains syntax>
00:16astearnsack tantek
00:16* Zakim sees no one on the speaker queue
00:16iank_Tantek: Repeating headers and footers were dropped from HTML, nobody implemented this, and it got dropped....
00:17iank_Florian: Prince, vivliostyle, and anntenahouse all implement the repeating headers and footers.
00:17iank_tantek: do any of those members participate in that WG?
00:17iank_Florian: I&#39;m confused as to why HTML WG talks about layout
00:18iank_fantasai: The HTML spec right now shouldn&#39;t be specifying that.
00:18iank_fantasai: CSS spec should specify how that renders.
00:18iank_Florian: I&#39;ll check that, it is implemented.
00:18iank_tantek: But not in any browser.
00:18iank_Florian: I disagree with interactive, vivliostyle is interactive.
00:18fremy@plinss @Florian: The conversation diverged but I wanted to mention that I don&#39;t think you can get rid of auto and define this in a UA stylesheet. Because one can set display of table-header-row on any kind of element, and the author doesn&#39;t set the new property yet still get the repeated behavior right now. So there must be some magic to tie the two together somehow.
00:19iank_Florian: Either most/all don&#39;t have this.
00:19* astearns thanks, fremy
00:19iank_tantek: If I was looking at this from an outside perspective, this is incubation.
00:19iank_fantasai: I don&#39;t think we generally do this.
00:20iank_Florian: The incubation approach sounds resonable, but don&#39;t want to do this in WICG.
00:20iank_tantek: Not saying this should be in WICG, I think we should do this (incubation) in CSSWG.
00:21iank_Florian: ED is relevant topic, globally sane approach, FPWD is without any time commitment this is something most folks would be able to implement.
00:21iank_astearns: I suggest b/c of timeconstraints, we don&#39;t discuss incubantion.
00:21iank_Florian: Realising that this isn&#39;t a group committment to do this - would folks like an ED.
00:22dauwhePrince will repeat thead/tfoot/caption on every page, but otherwise requires using page margin boxes for repeating elements
00:22iank_astearns: I would like gregwhitworth & fremy to look at this, as they are revamping tables spec, would like to get their opinion if we&#39;d have this as an ED.
00:22* dauwhe Lots of people ask Prince for such functionality, though
00:22iank_fantasai: I think we need the whole groups opinion.
00:23iank_astearns: I&#39;m very interested in how this works with grid layout.
00:23iank_Florian: Yes, but with caveat we don&#39;t know how grid fragmentation works.
00:23iank_fantasai: Would this apply to a grid-item?
00:24iank_Florian: <discussing how this may work with grid>
00:25iank_fantasai: We do placement before we do layout in grid, b/c you need to know how wide the columns are, i.e. know which column something is in.
00:25iank_Florian: Will that work when pages have different sizes?
00:25iank_fantasai: Gets trickier, but you still need to know content of whole grid
00:25iank_fantasai: Instrinic constraints, carry through accross all pages.
00:26iank_Florian: It seems there are cases with grid where you would want this to work.
00:26fremy@astearns: No problem, I&#39;ll send feedback on github
00:26iank_Florian: I&#39;m not entirely convinced we want to fragment the grid.
00:26iank_fantasai: ok, thats a different thing (discussion)
00:26iank_Florian: Not sure if we want to do this, may need to figure out grid fragmentation first.
00:27iank_Florian: But we are time-boxed, doesn&#39;t sound like we can resolve on ED yet,
00:27mylespresent+ myles_
00:27iank_ACTION: Florian to talk with gregwhitworth & fremy about how this interacts with table spec.
00:27* RRSAgent records action 1
00:27* trackbot is creating a new ACTION.
00:27trackbotCreated ACTION-848 - Talk with gregwhitworth & fremy about how this interacts with table spec. [on Florian Rivoal - due 2017-04-27].
00:27tantekFYI: in general I&#39;m in favor of a fairly low political bar for starting an ED, but we should consider, per incubation, if it is something that we wouldn&#39;t mind seeing it prototyped
00:27iank_Florian: For the record had a 10s conversation, TabAtkins said looks ok.
00:28iank_iank_: We&#39;ll look at this from a blink perspective at some stage.
00:28rachelandrewscribenick: rachelandrew
00:28tanteki.e. ED = start incubating, and IMO FPWD should mean we have sufficient evidence of incubation (e.g. prototypes that seem to at least somewhat work as expected)
00:29rachelandrewtopic: css-text-3
00:29rachelandrewfantasai: the first issue we were waiting to hear back from Microsoft on word-break: break-word
00:30rachelandrewthere isn&#39;t a github issue currently for this
00:30rachelandrewflorian: Google is finding it impossible to remove
00:31rachelandrewfantasai: no-one understands any of this, I don&#39;t know how to make it better / easier to understand, but I can&#39;t come up with anything
00:31rachelandrewflorian: if we add it it would be for webcompat reasons which makes it doubtful we can rename it
00:32rachelandrewiank_: our use counter for this is that we are at 20% of every page load
00:32Florians/this/this property/
00:33rachelandrewfantasai: we are over the threshold, this feature needs to be added somehow so Firefox and Microsoft can have that ability, whether authors would be willing ot switch over to a better name
00:33rachelandrewflorian: we did a bit of whiteboarding on a better name yesterday
00:33rachelandrewaction Microsoft and mozilla again
00:33* trackbot is creating a new ACTION.
00:33trackbotError finding &#39;Microsoft&#39;. You can review and register nicknames at <http://www.w3.org/Style/CSS/Tracker/users>.
00:34rachelandrewiank_: I&#39;m just looking to see if it is feasible to add a use counter
00:34rachelandrewtantek: we had an open bug on implementing at Mozilla, it has caused compat issues in the past but there are old complaints but no new ones
00:35rachelandrewfantasai: if mozilla isn&#39;t under pressure to add it, and Edge isn&#39;t then we can at least try to come up with something better and phase that in. All of the line breaking properties are very confusing
00:35rachelandrewtantek: it needs to be a lot better or we may as well stick with compat
00:35tantekour bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1296042 to implement &quot;word-break: break-word&quot;
00:35rachelandrewfantasai: the problem is we have the same property on 2 different keywords meaning different things
00:36rachelandrewastearns: I don&#39;t think we can resolve need to hear back from Microsoft
00:36rachelandrewfantasai: use data is high enough that it&#39;s scary
00:37rachelandrewtantek; is this something authors are actually using, or is Word just sticking it in or something
00:37astearnstopic: word-break: break-all doesn&#39;t break before sentence-ending punctuation if UAX #14 is used
00:37astearnsgithub topic: https://github.com/w3c/csswg-drafts/issues/1171
00:37* github-bot OK, I&#39;ll post this discussion to https://github.com/w3c/csswg-drafts/issues/1171
00:38rachelandrewflorian: there are many variations on how to wrap text, one thing is wrap everywhere, get to the end of the line break and do a new one
00:38rachelandrewflorian: the main difference between this and word-break: break-all is that it allows wrapping points between letters but not punctuation
00:39rachelandrewbreak between letters just like CJK
00:39rachelandrewfantasai: this one is for Japanese
00:39rachelandrewflorian: this doesn&#39;t do what you want if you want the terminal wrapping
00:39* astearns break-all-I-really-mean-it
00:39* astearns oh! or break!-!all
00:40rachelandrewfantasai: right now the word-wrap property acts on letters and symbols not punctuation
00:40rachelandrewthe line-break property deals with punctuation rules
00:40* plinss anybody-want-a-peanut?
00:40rachelandrewso we have logical separation of the two properties
00:40rachelandrewadding a new value to word-break is weird as that isn&#39;t what it does
00:40rachelandrewso we might want to add a value somewhere, maybe line-break: break-all
00:41rachelandrewflorian: the alt way to approach that is the overflow-wrap property, if things do overflow and you do overflow-wrap: break-word it allows the overflow to be anywhere
00:41rachelandrewfantasai: overflow-wrap says pick some arbitrary place near the end of the word to wrap
00:42rachelandrewflorian: writes on the whiteboard
00:42rachelandrewfantasai: so make overflow-wrap word regardless of the white-space value
00:43rachelandrewit does make sense that overflow-wrap is allowed to apply as this is basically emergency breaking
00:43rachelandrewwe might also want to add a break-all value
00:44rachelandrewwe should add line-break: break-all and also make overflow wrap apply regardless of the white-space value
00:44rachelandrewfantasai: I think that both behaviours are useful
00:45rachelandrewkoji: why do we need two things to do the same thing?
00:45myles__rachelandrew: he is &quot;koji&quot;
00:45myles__Ah ok you got it :)
00:45rachelandrewfantasai: currently overflow-wrap can allow breaking or non-breaking of a word
00:45rachelandrewthis doesn&#39;t change your intrinsic sizing
00:46rachelandrewthe other properties actually change the line-breaking rules
00:46rachelandrewI think the behaviour you would get for adding line-break is different to the behaviour you will get from overflow-wrap
00:47rachelandrewwe need a value that says break all, everthing. But we might also want to set the intrinsic size according to normal line breaking rules
00:47rachelandrewkoji; I think people want to change the intrinsic size, but not to change overflow behaviour
00:47rachelandrewiank_ what about properties that override intrinsic sizes
00:48rachelandrewfantasai: this is about how we calculate the size of overflow text
00:48rachelandrewflorian: we want t least one of the two
00:48rachelandrewfantasai: we definitely need line-break: break-all
00:49rachelandrewastearns: I have concerns about overflow
00:50rachelandrewfantasai: I think we can resolve on the one, we should keep in mind the other question whether overflow should wrap regardless of white space
00:50rachelandrewastearns: resolve to put an issue in the spec for overflow: wrap to apply regardless of whitespace
00:50astearnsRESOLVE: put an issue in the spec for overflow: wrap to apply regardless of whitespace
00:51astearnsRESOLVED: put an issue in the spec for overflow: wrap to apply regardless of whitespace
00:51rachelandrewto add a value to line break that will say break anywhere with regards to punctuation
00:52rachelandrewfantasai: then maybe add a shorthand to make this easier
00:52rachelandrewfantasai: break-all is one possibility, anywhere is another possibility
00:52rachelandrewkoji: it&#39;s strange because line-break is a CJK property
00:54rachelandrewfantasai: line-break is a property for different levels of punctuation strictness in different languages
00:54rachelandrewflorian: they forbid line breaking in various places
00:54rachelandrewfantasai: word-break does letters and symbols, line-break does punctuation
00:54rachelandrewastearns: so to get the terminal effect you would set line-break and word-break to break-all
00:55rachelandrewkoji: if we were to respond to original request it is easy, it is just to change one thing
00:56rachelandrewbreak-anywhere is easy, break anywhere at punctuation is a new thing
00:56rachelandrewmyles_: we would implement it at the system level
00:56rachelandrewwebkit doesn&#39;t want to be in the business of understanding all this stuff
00:56myles__fantasai: https://github.com/w3c/csswg-drafts/issues/1252
00:57rachelandrewkoji: in Android we define the priority of which to support and cut some of them
00:57rachelandrewthis new mechanism is more complex
00:58rachelandrewfantasai: I think it would be worth finding out if the combination is needed in Chinese (don&#39;t break a Latin word but break punctuation anywhere)
00:58rachelandrewflorian: I think the Japanese style of document, do English words get broken
00:58rachelandrewkoji: it does get broken
01:00rachelandrewfantasai: if we find out if we need to add it then we just need to pick a syntax
01:00astearnsaction xidorn to see if the case where you break at punctuation but not through english words is used in Chinese
01:00* trackbot is creating a new ACTION.
01:00trackbotError finding &#39;xidorn&#39;. You can review and register nicknames at <http://www.w3.org/Style/CSS/Tracker/users>.
01:01astearnsbased on that result, solve this issue with break-line: break-all (that allows that) or with a solution that breaks everywhere including punctuation
01:01rachelandrewfantasai: I&#39;m leaning to the syntax being line-break: break-all
01:01rachelandrewwe have to pick a property, and line-break already effects some letters word-break does not deal with punctuation
01:03rachelandrewastearns: can we resolve to put line-break: break-all in the spec for the purpose of the terminal use case, if it does that use case only or if it does it with the other property depends on investigation
01:03rachelandrewRESOLVED: add line-break: break-all to the spec
01:04astearnstopic: css-rhythm
01:04* github-bot Successfully commented on https://github.com/w3c/csswg-drafts/issues/1171 and removed the &quot;Agenda+&quot; label
01:06rachelandrewtopic: Rhythm
01:06rachelandrewflorian: we have 2 issues to talk about
01:06astearnstopic: Avoiding accidental double spacing
01:07astearnsgithub issue: https://github.com/w3c/csswg-drafts/issues/938
01:07astearnsgithub topic: https://github.com/w3c/csswg-drafts/issues/938
01:07* github-bot OK, I&#39;ll post this discussion to https://github.com/w3c/csswg-drafts/issues/938
01:07* dbaron moved to this room
01:07rachelandrewflorian: this is about avoiding accidental double spacing, this might happen if an author sets line height step to 1.3 em, and the default font using line-height normal turns out bigger than 1.3 em
01:08rachelandrewin another font the line-height might be calculated at double height
01:08rachelandrewthe previous proposal was to make the height deterministic
01:08rachelandrewbut koji pointed out that line-height normal is useful as it avoids overlap with long ascenders and descenders
01:08rachelandrewflorian: has a proposal for this
01:09rachelandrewwhen you have something with a tall line-height you want it to be double, when it inherits this is a feature
01:09rachelandrewwhen you set it, you never want to accidentally make the line-height step smaller than the natural line-eheight
01:09rachelandrewsoemtimes you want to do it on purpose
01:10rachelandrewproposing to add a safe /unsafe keyword pair defaulting to safe
01:10rachelandrewcurrent behaviour is the unsafe one
01:10rachelandrewdbaron: I understand but think it is a problem
01:12rachelandrewthe check is whether the line-height step is smaller than th eline-height and if so make the step bigger
01:12rachelandrewthe 2 pieces I am concerned about, 1 is that normal is a computed value of line-height
01:12rachelandrewhaving that go back and influence line height step doesn&#39;t seem as if it will work
01:12rachelandrewwe do sometimes have font metrics influence computed values
01:13rachelandrewflorian: you need ot take th eline-height unit value as the lh unit depends on it
01:13rachelandrewdbaron: so maybe that is ok, the other thing is that if you use text for more than one font we claim you end up creating a box of the size of the. line-height around both sets
01:13rachelandrewcreating a height that is larger than the line-height
01:14rachelandrewfantasai: thats a general problem
01:14rachelandrewdbaron: to the whiteboard
01:14rachelandrewflorian: does this change what line-height normal means
01:15fantasai dbaron draws a Chinese character and a Latin letter
01:15rachelandrewdbaron: demonstrates lining up characters on the whiteboard
01:15fantasaidbaron: suppose these come from different fonts
01:15fantasaidbaron draws the ascent and descent on the chinese character
01:16fantasaidbaron then draws the ascent and descent on the Latin letter, which is a little bit lower
01:16rachelandrewflorian: which is the primary font and which is the fallback
01:16rachelandrewdbaron: it shouldn&#39;t matter as per the spec
01:16rachelandrewfantasai: I think there is a conflict in the spec
01:17rachelandrewdbaron: the number line-height is 1.26 font size 16px, so we want a 20 pixel box round each of these
01:17rachelandrewdbaron demonstrates where the line-height boxes are around the two characters
01:17fantasai(dbaron is using a numeric line height in place of normal, because normal could result in varying line heights; didn&#39;t want to deal with the complexity yet)
01:18rachelandrewdbaron: end up with a line box height bigger than the line-height
01:18fantasaidbaron notes that because the ascent plus descent plus half-leading of each adds up to 20px, but they are offset by 1px, the total line height is 21px
01:19fantasaifantasai says the CSS2.1 spec says two contradictory things, one of which is that
01:19rachelandrewflorian: in this case if you started with a line-height step of 30 pixels you wouldn&#39;t get double spacing
01:19rachelandrewdbaron: the designer might have fonts that have the same box and others have different boxes and get the double spacing
01:20rachelandrewflorian: for it to fail that way you need multiple fonts falling back to each other
01:20rachelandrewfantasai: I think this point is really important, it is a critical flaw in how it works
01:20rachelandrewwhen you have boxes of the same height, the CSS2.1 spec says 2 different thinks
01:20rachelandrewyou get that result and also get 20 pixels out of that
01:20rachelandrewso we need to fix that
01:21rachelandrewin order for line-height-step to be at all robust and not flaky we need to fix it
01:22rachelandrewmyles: Gecko and spec agree with dbaron&#39;s example, WebKit would calculate the height and add spacing to either side to make it equal
01:23fantasai(The spec says two contradictory things, and supports both Gecko and WebKit&#39;s interpretations depending on which sentence you read in the paragraph describing this)
01:23dbaronI don&#39;t think that&#39;s actually what Gecko does
01:23dbarondbaron: oh, yeah, that is what the spec says -- add the half-leading after unioning the character heights
01:23rachelandrewastearn: this is one crucial instance, but initially you were talking about making step sizing in the safe mode that would increase itself if it encountered a large line-height
01:24rachelandrewflorian: where you have set your step size accidentally smaller than the computed value of line-height
01:24rachelandrewfantasai: can we resolve on fixing this?
01:24* astearns fantasai there&#39;s a bug for css2 on this?
01:25rachelandrewkoji: how do you compute line-height normal to pixels
01:25* astearns then let&#39;s get that on the agenda and resolve this separately - I don&#39;t want to move off rhythm right not
01:25rachelandrew<general disagreement about the spec>
01:26rachelandrewdbaron: it&#39;s more like a number than any other kind of value but it does a thing based on the font
01:26rachelandrewmyles_: it is based on the default font
01:26dbaronHere&#39;s the thing I drew on the whiteboard: https://lists.w3.org/Archives/Public/www-archive/2017Apr/att-0006/IMG_20170420_102101.jpg
01:26dbaron(although as myles__ pointed out, I was wrong)
01:27astearnsthe point I wanted to make that you use step sizing to create vertical rhythm. Creating a &#39;safe&#39; version that avoids double spacing and breaks the rhythm is counterproductive
01:27rachelandrewflorian: is there a definition for the used value of line-height, if you have normal and know the font
01:27rachelandrewfantasai: at computed time the lh unit needs to map to an actual value
01:27dbarondbaron: I think you get it from the first available font
01:27rachelandrewflorian: the value of the line-height property does it change based on content on the line?
01:28rachelandrewdoes that property vary per line?
01:28rachelandrewmyles_: no properties do not vary per line
01:28rachelandrewflorian: you can&#39;t change the primary font per line
01:28rachelandrewdbaron: I think florian is talking about multiple lines splitting the same element
01:29rachelandrewthe computed value of line-height normal is normal
01:29rachelandrewso if you are asking what lh does, when you have line-height normal use the first available font in the font list
01:29rachelandrewflorian: not only is the value normal, but the value of line-height 1.2 is 1.2
01:30rachelandrewdbaron: let&#39;s file a spec issue
01:30rachelandrewflorian: what makes this impossible
01:31rachelandrewdbaron: spec needs to say how to compute to an abs length, probably using the primary font
01:31rachelandrewflorian: do you need to do layout to figure out the pixel value of line-height?
01:31rachelandrewdbaron: for the lh unit or for layout?
01:31rachelandrewflorian: not talking about the line box
01:32rachelandrewwhat does the UA pick the number based on?
01:32rachelandrewfantasai: I think you assume this gets computed by a number and used as that number for layout calcs, used as a length to figure out the leading
01:33rachelandrewthat conversion happens per font in the text
01:33rachelandrewmyles_: webkit does this
01:34rachelandrewfantasai: if you don&#39;t have a value for the entire run, how can you work out the line-height for a single value
01:34dbaronok, filed https://github.com/w3c/csswg-drafts/issues/1253 on css-values-4
01:34rachelandrewmyles_: (answering q) we do a bunch of stuff for the width then we calculate heights and place vertically
01:35rachelandrewfantasai: for each char you find ascent and descent, get a value, if it is not the line-height increase or decrease on both sides to get the line-height
01:35rachelandrewdbaron: do you then use the normal?
01:36rachelandrewdbaron: use line-height normal, a single element on the line, font fallback is happening in the line, fonts have different etrics for line-height normal and ascent and descent
01:36rachelandrew... you take the ascent and descent, where do you get the number for normal
01:37rachelandrewmyles_: we don&#39;t
01:37rachelandrewdbaron: Gecko includes the external leading
01:37rachelandrewflorian: how is this not a violation of 2.1?
01:37rachelandrewkoji: this sentence contradicts other parts of the spec
01:37rachelandrewdbaron: that sentence was written in the olden days
01:37fantasais/we don&#39;t/we don&#39;t; we take that value with no extra leading/
01:38rachelandrewdbaron: it assumes defaulting to what the font says
01:38rachelandrewkoji: describes content box height
01:39rachelandrewfantasai: the content box height has no effect on layout
01:39rachelandrewdbaron: it matters re leading around it
01:39rachelandrewfantasai: but this section is not related to line-height normal
01:40rachelandrewdbaron: it can change the size of things, because the leading changes the content height, the middle of where the content height is does matter to layout
01:40rachelandrewastearn: we&#39;re not really addressing the rhythm issue here, though we found bugs in other specs
01:41rachelandrewflorian: do we have an issue to define the line-height unit based on primary font
01:41rachelandrewdbaron: pasted such an issue earlier
01:41rachelandrewflorian: the issue I proposed is to define the same way
01:42rachelandrewkoji: this is based on font metrics of the primary font in safe mode
01:42rachelandrewflorian: when it inherits, is specified. It doesn&#39;t depend on the font
01:43rachelandrewastearns: you set your vertical rhythm for body text but the heading is bigger what happens
01:43rachelandrewflorian: the line step height will double to keep the rhythm
01:43rachelandrewgets the unsafe value from the pixel
01:44rachelandrewnot magic, doing this based on a keyword, unsafe is current behaviour. safe will cause the bigger line-height behaviour
01:44rachelandrewkoji: does this change based on inheriting?
01:45rachelandrewflorian: no magic with inheriting
01:45dbaronok, filed https://github.com/w3c/csswg-drafts/issues/1254 on line-height:normal definition in CSS 2.1
01:45rachelandrewflorian: how well this works depends on how we fix 2.1, it doesn&#39;t make things worse
01:45rachelandrewkoji: I don&#39;t see it saves much, maybe some cases people think it is better
01:46rachelandrewfantasai: keyword on line height setp to us line-height
01:46rachelandrewastearns: that would make double spacing more likely
01:46rachelandrewflorian: you don&#39;t want to be exactly the line-height, needs to be just a bit more
01:47rachelandrewastearns: step sizing could be a percentage of line-height
01:47rachelandrewflorian: either line-height is a number and works, or it isn&#39;t
01:48rachelandrewif you want to set your step smaller than the line-height, set it explicitly with unsafe then it will not get adjusted up
01:48dbaronKoji: on web, due to small screen real estate, people set grid to fraction (half) of the desired line height
01:48dbaronastearns: that happens in print as well
01:48rachelandrewkoji: I understand some cases it helps, given complexity vs benefit
01:49rachelandrewflorian: it is very frustrating when people won&#39;t use a browser if it breaks, the outcome of not dealing with this could cause problems with different sized fonts, in one browser double heights might happen based on default sizing
01:50rachelandrewfantasai: having a layout system that breaks badly when fonts get substtuted is bad
01:50rachelandrewdouble spacing is bad
01:51rachelandrewdbaron: authors should not have to write a number in their CSS that has to be right based on the font the user has
01:51rachelandrewflorian: the feature currently requires users pick a value
01:52* dauwhe I had an example where double spacing could be triggered purely by switching font family from serif to fantasy
01:52rachelandrewdbaron: the dev currently has to write line-height 3 or 20 pixels, Chrome might switch to double spacing based on one value, Firefox might pick another value, a subtle difference means you get double spacing in one browser and not another
01:52* astearns you get what you deserve when you use the fantasy keyword
01:53* dauwhe astearns: don&#39;t ruin the fantasy :)
01:53rachelandrewdbaron: Gecko has had to reduce line-height they compute for webcompat issues
01:53rachelandrewfantasai: we don&#39;t want more of these situations
01:54rachelandrewastearns: should we come up with a way of making step sizing safer, we haven&#39;t come up with a resolution on that
01:55astearnstopic: css2 fixing
01:55* github-bot Successfully commented on https://github.com/w3c/csswg-drafts/issues/938
01:57rachelandrewsuggested resolution is to fix the erroneous conclusion in section 10.8
01:58fantasaigithub topic: https://github.com/w3c/csswg-drafts/issues/391
01:58* github-bot OK, I&#39;ll post this discussion to https://github.com/w3c/csswg-drafts/issues/391
01:58rachelandrewRESOLVED: fix the erroneous conclusion in section 10.8
02:05dbaronTopic: break
02:05* github-bot Successfully commented on https://github.com/w3c/csswg-drafts/issues/391
02:33fantasaiTopic: 2 Different Colors for a Double Style Outline
02:33Floriangithub topic: https://github.com/w3c/csswg-drafts/issues/1172
02:33* github-bot OK, I&#39;ll post this discussion to https://github.com/w3c/csswg-drafts/issues/1172
02:33surmapresent+ Surma, Google
02:33mylespresent+ myles
02:33dbaronGithub topic: none
02:33* github-bot OK, I won&#39;t post this discussion to GitHub
02:34dbaronTopic: 2 Different Colors for a Double Style Outline
02:35dbarongithub topic: https://github.com/w3c/csswg-drafts/issues/1172
02:35* github-bot OK, I&#39;ll post this discussion to https://github.com/w3c/csswg-drafts/issues/1172
02:35fantasaiChrisL: There was an ask form one of the a11y groups, they noted on iOS or maybe OS? that focus highlight is two colors: black and white, so that whatever the background is, you can see it
02:35fantasaiChrisL: Black and white is always visible; invert e.g. doesn&#39;t work on gray
02:35fantasaiChrisL: They asked for this
02:35fantasaiChrisL: And I pointed out that outline uses the same keywords as border does.
02:35fantasaiChrisL: If we add multiple colored borders, which ppl have asked for, we would automatically get this on outline
02:36fantasaiChrisL: And that would be a nice extensible thing
02:36fantasaiChrisL: It would also give Web devs something they want, not just helping a11y, so more likely to be implemented and adopted
02:36fantasaiChrisL: Question is how do we add multiple color borders to things
02:36fantasaiFlorian: One of the other options, which isprobably not such a good option, is to have double borders take two different colors
02:37dbaronDo we want &#39;outline-image&#39; that&#39;s a parallel to &#39;border-image&#39;... or does that get messy with non-rectagular outlines?
02:37fantasaiChrisL: I think that&#39;s less general and less useful, and would prefer to shoot for the bigger one
02:37fremy@ChrisL: can&#39;t we just add an option to have two outlines with two outlines offset? one black, one white?
02:37fantasaiFlorian: Comma-separated
02:37fantasaileaverou: Authors do it all the time with border+outline, or multiple box shadows
02:37fantasaileaverou: Back when we were listifying the properties, idea was ppl would use borde-rimage for it
02:37fantasaileaverou: But people don&#39;t want to use border-image bc don&#39;t want to link to images
02:37fantasaileaverou: So best way forward is to make border and outline a list
02:38* Zakim sees smfr on the speaker queue
02:38fantasaileaverou: It solves all these issues
02:38* Zakim sees smfr, dbaron on the speaker queue
02:38fantasaiChrisL: Also observed that people do all kinds of creative things with list-valued properties
02:38fantasaiChrisL: So theyr&#39;e a good thing
02:38fantasaishane: spacing between borders?
02:38fantasaifantasai: transparent
02:38fantasaiChrisL: We wouldn&#39;t assume the same width, could have thick and thin borders, one can be transparent
02:39* Zakim sees smfr, dbaron on the speaker queue
02:39* Zakim sees smfr, dbaron on the speaker queue
02:39fantasaileaverou: In the case of outline, offset exists
02:39* Zakim sees smfr, dbaron, SimonSapin on the speaker queue
02:39fantasaismfr: How does this interact with border radius
02:39fantasaismfr: Is there a single border radius or each one have its own?
02:39* dbaron ack smfr
02:39* Zakim sees dbaron, SimonSapin on the speaker queue
02:39fantasaiChrisL: It should stack out nicely
02:39fantasaiFlorian: It&#39;s corner-radius, not border-radius
02:40fantasaismfr: One thing that&#39;s hard with border-radius is getting a smooth edge between two different colors without anit-aliasing artifacts
02:40* Zakim sees dbaron, SimonSapin on the speaker queue
02:40fantasaismfr: Can solve in single border and background case, but it&#39;s expensive
02:40* Zakim sees dbaron, SimonSapin on the speaker queue
02:40fantasaiChrisL describes the problem
02:40fantasaiChrisL: I suggest we say that the borders are all composited together off-screen, and then added on top of background
02:40fantasaismfr: That seems reasonable
02:41* Zakim sees dbaron, SimonSapin on the speaker queue
02:41fantasaiChrisL: Effectively that means that we should communicate this is a single multi-coolored border, rather than multiple borders
02:41fantasaidbaron: I think we&#39;ve just agreed to turn 25 properties into lists
02:41fantasaidbaron: There are some interesting questions as to how they all interact
02:41fantasaidbaron: IN particular we have [lists all the border properties]
02:42fantasaiSee https://www.w3.org/TR/css3-background/#property-index
02:42* astearns now list the states in alphabetical order
02:42fantasaiRossen: Don&#39;t forget the logical ones!
02:42fantasaialso outlines
02:42fantasaidbaron: So, 39 properties
02:42ChrisLq+ to worry about multiple border images
02:42* Zakim sees dbaron, SimonSapin, ChrisL on the speaker queue
02:42fantasaidbaron: Most of it is uninteresting except 2 things
02:42fantasaidbaron: One is, what is length of the list is different for style / width /color? Which controls?
02:42fantasaidbaron: We typically pick one authoritative
02:43fantasaidbaron: My intuition is style should be authoritative
02:43fantasaigeneral agreement
02:43fantasaidbaron: Question is then whether you allow &#39;none&#39; in the middle of the list
02:43fantasaidbaron: which would kill corresponding things in the list
02:43fantasaiFlorian: none | <list>
02:44fantasaidbaron: We originally said that for animations, but then ppl wanted placeholders
02:44* ChrisL yes they did and it was rubbish
02:45fantasaiChrisL: People might want to animate from none
02:45fantasaifantasai: They shouldn&#39;t use one, should animate from zero-width border
02:45* Zakim sees dbaron, SimonSapin, ChrisL, myles on the speaker queue
02:45fantasaileaverou agrees
02:45dbaronTabAtkins: or maybe *-color should be controlling the list length
02:45fantasaidbaron: So making color controlling is interesting, that might b the most common thing to vary
02:46fantasaiTabAtkins: Would need to repeat the other things
02:46fantasaiChrisL: Want to repeat the list, not just pad it?
02:46dbaronfantasai: I think we should have front-padded backgrounds instead of repeating.
02:47fantasais/should have/shoudl have had/
02:47* Zakim sees dbaron, SimonSapin, ChrisL, myles on the speaker queue
02:47fantasaifantasai: But for border, repeating might make more sense
02:47ChrisLack dbaron
02:47* Zakim sees SimonSapin, ChrisL, myles on the speaker queue
02:47* Zakim sees SimonSapin, ChrisL on the speaker queue
02:47fantasaidbaron: Other point: corner joins! Corner joins are pretty hard already, now have to figure out 2 borders joining for three
02:48tantekfantasai what was the thing that I said we needed?
02:48fantasaidbaron: We already have a complicated spec for corner joins to make them look nice
02:48* astearns bring some Japanese woodworkers in to show us their joining techniques
02:48fantasai[discussion of corner join niceties]
02:48dbarondbaron: I think people are going to ask for it to be nicer.
02:49fantasaiSimonSapin draws
02:49tantekI&#39;m looking forward to hacking arbitrary polygons with multi-borders: http://tantek.com/CSS/Examples/polygons.html
02:49fantasaiSimonSapin: with just one border, if htey are different widths, we have this line whose angle varies depending on the widht
02:49fantasaiSimonSapin: If we have more borders, but not the same count, then assume we can connect them like this? transition is weird
02:49fantasaidbaron: Do you want a straight line or a zigzagline?
02:49fantasaifantasai: You want a straight line
02:50dbaronmyles and smfr also seem to want a straight line
02:50fantasaisurma: I would expect basically to have the same diagnonal as one border, and you add up all the border widths
02:50fantasaisurma: And separate the big border into individual ones
02:50fantasaigeneral agreement
02:50fantasaiChrisL: Which allows you to composit as a single thing
02:50fantasaismfr: There&#39;s an amazing amount of code for border joins
02:51* Zakim sees SimonSapin, ChrisL on the speaker queue
02:51fantasaidbaron: A bunch of these cases throw you into really slow graphics paths
02:51fantasaidbaron: At one point 30% of gmail render time was borders
02:51fantasaidbaron: Don&#39;t thin kthis stuff is easy
02:51dbarons/render time/load time/
02:51fantasaiSimonSapin: Someone said multiple borders are all the same width, but then said border widht is a list
02:51fantasaifantasai: It&#39;s a list, that repeats
02:51SimonSapinack SimonSapin
02:51* Zakim sees ChrisL on the speaker queue
02:52fantasaiSimonSapin: OK
02:52fantasaiChrisL: So, border-image. Will we allow multiple images?
02:52dbaron(BTW, I hate implementing list-valued properties!)