/irc-logs / w3c / #css / 2015-05-19 / end

Options:

# Session Start: Tue May 19 00:00:01 2015
# Session Ident: #css
# [00:00] * Quits: smfr (~smfr@public.cloak) (smfr)
# [00:00] <gregwhitworth> RESOLUTION: Bring back elements for snap points. Once it is specificed, it will be the box that traps all snap points
# [00:01] * Joins: smfr (~smfr@public.cloak)
# [00:01] <fantasai> Meeting adjourned.
# [00:01] * Quits: glazou (~glazou@public.cloak) (glazou)
# [00:01] <Bert_> s/if I set them on the outer element with repeat,/if I set them on the outer element with repeat, and use 'break-before: <something>' on a child,/
# [00:01] * Quits: gregwhitworth (~gregwhitworth@public.cloak) ("Page closed")
# [00:01] * fantasai kicks leaverou for not speaking up her points
# [00:02] * Quits: smfr (~smfr@public.cloak) (smfr)
# [00:02] * leaverou fantasai sorry! I had a sudden surge of self-consciousness :P
# [00:09] * Quits: SteveZ (~SteveZ@public.cloak) (Ping timeout: 180 seconds)
# [00:09] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
# [00:09] * liam_ has been there often, leaverou :)
# [00:09] * Joins: Florian (~Florian@public.cloak)
# [00:10] * Quits: ChrisL (clilley@public.cloak) (Ping timeout: 180 seconds)
# [00:11] * Quits: dael (~dael@public.cloak) ("Page closed")
# [00:14] * Quits: antonp1 (~Thunderbird@public.cloak) (antonp1)
# [00:14] * Joins: adenilson (~anonymous@public.cloak)
# [00:16] * Quits: johanneswilm (~johannes@public.cloak) (Ping timeout: 180 seconds)
# [00:16] * Quits: bcampbell (~chatzilla@public.cloak) (Ping timeout: 180 seconds)
# [00:16] * Quits: Florian (~Florian@public.cloak) (Ping timeout: 180 seconds)
# [00:18] * Rossen is now known as Rossen_away
# [00:19] * Quits: andreyr (~andreyr@public.cloak) (Ping timeout: 180 seconds)
# [00:21] * Quits: dbaron (~dbaron@public.cloak) (Ping timeout: 180 seconds)
# [00:21] * leaverou is now known as leaverou_away
# [00:29] * heycam|away is now known as heycam
# [00:54] * Quits: adenilson (~anonymous@public.cloak) (Client closed connection)
# [00:55] * Joins: adenilson (~anonymous@public.cloak)
# [01:19] * heycam is now known as heycam|away
# [01:21] * heycam|away is now known as heycam
# [01:33] * Joins: adenilson_ (~anonymous@public.cloak)
# [01:35] * Quits: adenilson (~anonymous@public.cloak) (Ping timeout: 180 seconds)
# [01:35] * adenilson_ is now known as adenilson
# [01:38] * Quits: adenilson (~anonymous@public.cloak) (Client closed connection)
# [01:38] * Joins: adenilson (~anonymous@public.cloak)
# [01:50] * Quits: Nik (~c7aca957@public.cloak) ("http://www.mibbit.com ajax IRC Client")
# [01:54] * Quits: adenilson (~anonymous@public.cloak) (Client closed connection)
# [01:55] * Joins: adenilson (~anonymous@public.cloak)
# [01:55] * heycam is now known as heycam|away
# [02:08] * Quits: adenilson (~anonymous@public.cloak) (Client closed connection)
# [02:08] * Joins: adenilson (~anonymous@public.cloak)
# [02:15] * Quits: adenilson (~anonymous@public.cloak) (Client closed connection)
# [02:15] * Joins: adenilson (~anonymous@public.cloak)
# [02:22] * Parts: quadcore (~user@public.cloak)
# [02:27] * Joins: jdaggett (~jdaggett@public.cloak)
# [02:30] * Quits: bl4de (~45bff13b@public.cloak) ("http://www.mibbit.com ajax IRC Client")
# [02:40] * heycam|away is now known as heycam
# [02:46] * Quits: Hixie (~ianh@public.cloak) (Ping timeout: 180 seconds)
# [03:03] * Quits: adenilson (~anonymous@public.cloak) (adenilson)
# [03:05] * Joins: Hixie (~ianh@public.cloak)
# [03:18] * Joins: adenilson (~anonymous@public.cloak)
# [03:21] * Quits: adenilson (~anonymous@public.cloak) (adenilson)
# [03:27] * Joins: adenilson (~anonymous@public.cloak)
# [03:29] * Joins: kwkbtr (~kwkbtr@public.cloak)
# [03:53] * Joins: smfr (~smfr@public.cloak)
# [03:53] * Quits: adenilson (~anonymous@public.cloak) (adenilson)
# [03:54] * Joins: adenilson (~anonymous@public.cloak)
# [04:04] * Joins: johanneswilm (~johannes@public.cloak)
# [04:05] * Joins: shepazu (schepers@public.cloak)
# [04:08] * Quits: adenilson (~anonymous@public.cloak) (adenilson)
# [04:17] * Joins: adenilson (~anonymous@public.cloak)
# [04:24] * Joins: adenilson_ (~anonymous@public.cloak)
# [04:24] * Quits: adenilson (~anonymous@public.cloak) (Ping timeout: 180 seconds)
# [04:24] * adenilson_ is now known as adenilson
# [04:25] * Joins: Florian (~Florian@public.cloak)
# [04:28] * leaverou_away is now known as leaverou
# [04:34] * Joins: ChrisL (clilley@public.cloak)
# [04:49] * Quits: ChrisL (clilley@public.cloak) (Client closed connection)
# [04:51] * Quits: smfr (~smfr@public.cloak) (smfr)
# [04:52] * Quits: johanneswilm (~johannes@public.cloak) (Ping timeout: 180 seconds)
# [04:57] * leaverou is now known as leaverou_away
# [05:05] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
# [05:06] * Joins: Florian (~Florian@public.cloak)
# [05:22] * Quits: adenilson (~anonymous@public.cloak) (adenilson)
# [05:25] * leaverou_away is now known as leaverou
# [05:29] * heycam is now known as heycam|away
# [05:55] * SimonSapin_ is now known as SimonSapin
# [05:57] * heycam|away is now known as heycam
# [06:10] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
# [06:16] * Joins: Florian_ (~Florian@public.cloak)
# [06:24] * Quits: Florian_ (~Florian@public.cloak) (Client closed connection)
# [06:33] * Joins: adenilson (~anonymous@public.cloak)
# [07:31] * Quits: adenilson (~anonymous@public.cloak) (adenilson)
# [07:33] * leaverou is now known as leaverou_away
# [08:39] * Joins: Ms2ger (~Ms2ger@public.cloak)
# [09:28] * Joins: johanneswilm (~johannes@public.cloak)
# [09:43] * Joins: anssik (~uid10742@public.cloak)
# [09:43] * Joins: antonp (~Thunderbird@public.cloak)
# [09:47] * heycam is now known as heycam|away
# [10:12] * Quits: jdaggett (~jdaggett@public.cloak) (Ping timeout: 180 seconds)
# [10:39] * Joins: lajava (~javi@public.cloak)
# [11:34] * Joins: adenilson (~anonymous@public.cloak)
# [11:37] * Quits: johanneswilm (~johannes@public.cloak) (Ping timeout: 180 seconds)
# [12:25] * Quits: kwkbtr (~kwkbtr@public.cloak) (Client closed connection)
# [12:46] * Quits: adenilson (~anonymous@public.cloak) (adenilson)
# [13:04] * Joins: Florian (~Florian@public.cloak)
# [13:05] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
# [13:05] * Joins: Florian (~Florian@public.cloak)
# [13:12] * Quits: Florian (~Florian@public.cloak) (Ping timeout: 180 seconds)
# [13:14] * Joins: johanneswilm (~johannes@public.cloak)
# [13:29] * Joins: plh (plehegar@public.cloak)
# [13:40] * Quits: lajava (~javi@public.cloak) (Ping timeout: 180 seconds)
# [13:42] * Joins: Florian (~Florian@public.cloak)
# [14:00] * leaverou_away is now known as leaverou
# [14:05] * Quits: johanneswilm (~johannes@public.cloak) (Ping timeout: 180 seconds)
# [14:12] * leaverou is now known as leaverou_away
# [14:20] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
# [14:20] * Joins: Florian (~Florian@public.cloak)
# [14:27] * Quits: Florian (~Florian@public.cloak) (Ping timeout: 180 seconds)
# [14:34] * Joins: SteveZ (~SteveZ@public.cloak)
# [15:03] * Quits: shepazu (schepers@public.cloak) ("My Mac has gone to sleep. ZZZzzz…")
# [15:04] * Joins: bcampbell (~chatzilla@public.cloak)
# [15:07] * Joins: dauwhe (~dauwhe@public.cloak)
# [15:12] * Joins: presentation-pc (~presentation-pc@public.cloak)
# [15:15] * Joins: andrey-bloomberg (~andrey-bloomberg@public.cloak)
# [15:16] <andrey-bloomberg> **** Dial in info: ****
# [15:16] <andrey-bloomberg> please dial +1-212-617-1960 for New York, +44-20-7330-7700 for London, +81-3-3201-7040 for Tokyo. * Participants should enter PIN 295109.
# [15:18] * Joins: renoirb (renoirb@public.cloak)
# [15:18] * Joins: johanneswilm (~johannes@public.cloak)
# [15:24] * Joins: glazou (~glazou@public.cloak)
# [15:26] * Joins: Florian (~Florian@public.cloak)
# [15:31] <glazou> koji: yt?
# [15:31] * leaverou_away is now known as leaverou
# [15:31] * koji yeah, trying to call in
# [15:31] <glazou> we’re not ready yet
# [15:31] * Joins: antenna (~antenna@public.cloak)
# [15:31] <glazou> last people just arrived
# [15:34] * Joins: Zakim (zakim@public.cloak)
# [15:36] <SimonSapin> ScribeNick: SimonSapin
# [15:36] <SimonSapin> Topic: Writing Modes
# [15:36] * Quits: antenna (~antenna@public.cloak) ("Leaving")
# [15:38] * Quits: plh (plehegar@public.cloak) ("Leaving")
# [15:38] * presentation-pc is now known as presenter
# [15:38] <presenter> https://lists.w3.org/Archives/Public/www-style/2015Apr/0387.html
# [15:38] <SimonSapin> koji: First issue is proposal to defer orthogonal table cells
# [15:39] * Joins: gregwhitworth (~gregwhitworth@public.cloak)
# [15:39] <SimonSapin> fantasai: idea is we don’t have interop impls for writing modes applied to a table cell (you can apply to contents of a table cell)
# [15:39] <SimonSapin> fantasai: proposal to defer to level 3
# [15:39] <SimonSapin> fantasai: don’t think this makes sense, but problem is that we don’t have impls eg for vertical table headers
# [15:40] <SimonSapin> Rossen_away: did you test IE?
# [15:40] <SimonSapin> fantasai: yes, found bugs
# [15:40] <SimonSapin> fantasai: I don,t think it makes sense to defer to next level
# [15:40] <SimonSapin> jet: single cells?
# [15:40] <SimonSapin> fantasai: yes
# [15:40] <SimonSapin> fantasai: my position is we should keep it
# [15:40] <SimonSapin> Rossen_away: I agree
# [15:41] <SimonSapin> fantasai: defer means if you apply a WM to a table cell, some impls will apply some will ignore
# [15:41] <SimonSapin> glazou: what does it mean in terms of spec? Behavior undefined?
# [15:42] <SimonSapin> fantasai: we can do 3 things: 1 leave the spec alone, 2 say it’s undefined, 3 is say that WM to a table cell: either you do X or pretend it doesn’t apply
# [15:42] <SimonSapin> dbaron: WM inherits, right?
# [15:42] <SimonSapin> fantasai: yes
# [15:43] <SimonSapin> fantasai: we need to look at why it’s not implemented
# [15:43] <SimonSapin> SteveZ: ignore the property?
# [15:43] <SimonSapin> fantasai: that’s 3
# [15:43] <SimonSapin> fantasai: undefined means weird things can happen
# [15:43] <SimonSapin> dbaron: it’s kinda weird to ignore an inherited prop on just some elements
# [15:43] <gregwhitworth> This works in IE/MS Edge: http://jsbin.com/videdumeme/2/edit
# [15:43] <SimonSapin> dbaron: on inner table elements like rows is use the WM of the table
# [15:44] <SimonSapin> koji: you already apply WM to the table’s contents
# [15:44] <SimonSapin> dbaron: ignoring it means you do the same for a cell, which acts like it has the WM of the table
# [15:44] <koji> Spec currently says "All elements except table row groups, table column groups, table rows, and table columns"
# [15:44] <SimonSapin> dbaron: but the anonymous block inside the cell uses the WM of the cell
# [15:45] <SimonSapin> fantasai: if correctly, that’s same results
# [15:45] <SimonSapin> dbaron: execpt for logical properties
# [15:46] <SimonSapin> fantasai: we don’t have those yet, so from the POV of the spec it doesn’t make a difference
# [15:46] * Joins: kwkbtr (~kwkbtr@public.cloak)
# [15:46] <SimonSapin> dbaron: I don’t see how it would be extra work to make it apply at least on the anonymous block inside the table cell
# [15:48] <glazou> Present: plinss, Rossen, TabAtkins, gregwhitworth, Bert, bcampbell, SimonSapin, glazou, fantasai, jet, iank, shane, dbaron, leaverou, SteveZ, johanneswilm, ChrisL, smfr, andrey-bloomberg
# [15:48] * Joins: dbaron (~dbaron@public.cloak)
# [15:49] * Joins: smfr (~smfr@public.cloak)
# [15:51] <SimonSapin> koji: some differences in table cells when applying borders
# [15:51] * fantasai koji, I think you have to type
# [15:51] * fantasai we cannot understad you
# [15:51] <koji> I think table cell has some differences in borders, colspan, etc.
# [15:52] <koji> IE fails most of these tests as of today
# [15:52] <fantasai> colspan!?
# [15:52] <koji> Since WebKit and Blink does not apply to td/th
# [15:52] <koji> authors already work around by putting a div/span inside table cells
# [15:52] <SimonSapin> dbaron: colsan and rowspan are still relative to the table’s WM I hope?
# [15:52] <SimonSapin> TabAtkins: Yes
# [15:53] <SimonSapin> TabAtkins: a colspan spans columns
# [15:53] <SimonSapin> dbaron: who is pushing to change the spec?
# [15:53] <SimonSapin> TabAtkins: Koji is
# [15:53] <koji> me
# [15:53] <SimonSapin> fantasai: my preferred solution would be file bugs against impls
# [15:53] <SimonSapin> gregwhitworth: Rossen_away: agree
# [15:54] <SimonSapin> fantasai: anyone have a different opinion?
# [15:54] <SimonSapin> Chris: so your opinion is that the spec is clear?
# [15:54] <SimonSapin> fantasai: on that topic yes
# [15:54] <SimonSapin> glazou: what does this mean to go to REC?
# [15:54] * Rossen_away is now known as Rossen
# [15:54] <SimonSapin> fantasai: bugs need to be fixed before
# [15:54] <SimonSapin> glazou: are browsers interested in fixing this?
# [15:55] <SimonSapin> jet: We’re implementing now
# [15:55] <SimonSapin> glazou: sshould it be at-risk?
# [15:55] <SimonSapin> Chris: there is no downside to mark at-risk
# [15:55] <SimonSapin> Florian: also can mark at-risk + say "we can drop from must to should"
# [15:56] <SimonSapin> SteveZ: In that case fantasai wants a fallback which in my mind means to ignore the property
# [15:57] <SimonSapin> fantasai: so `td, th { writing-mode: inherit !important}` in the UA stylesheet?
# [15:57] <SimonSapin> fantasai: effectively
# [15:57] <SimonSapin> Chirs: with a comment: do it properly or not at all
# [15:57] <koji> If not supported, it should be the same as when applied to <tr>, no?
# [15:58] <SimonSapin> jet: sounds like implementers want to leave it in
# [15:58] <SimonSapin> fantasai: you (IE) want the spec to stay and you’ll fix your bugs
# [15:58] <SimonSapin> Rossen: can you be more specific?
# [15:58] <SimonSapin> fantasai: so if we write test cases where you fail, you’ll fix it
# [15:58] <SimonSapin> Rossen: that’s how it works
# [15:58] <SimonSapin> fantasai: I think it should stay, but it’s up to the WG
# [15:59] <SimonSapin> glazou: straw poll
# [15:59] <SimonSapin> glazou: Two options: should stay in the spec, or not
# [15:59] <SimonSapin> Florian: or marked at risk
# [15:59] <Florian> s/or/and/
# [16:00] <fantasai> 1. No change to spec
# [16:00] <fantasai> 2. Say it is undefined
# [16:00] <Florian> Stay in the spec, mark at risk, with clarification that at risk means may drop from must to shoud
# [16:00] <fantasai> it = what happens whe writing-mode is applied to a table cell
# [16:01] <glazou> Present+ shepazu
# [16:01] <fantasai> 3. Mark as at-risk and specify what happens if it's not implemented
# [16:01] <SimonSapin> 1: 8 hands raised
# [16:01] <SimonSapin> 2: none
# [16:02] <SimonSapin> 3: 5 hands
# [16:02] * Zakim sees 3:, 5 on the speaker queue
# [16:02] * koji raising for 3
# [16:02] <koji> 3
# [16:02] <SimonSapin> 3: 6 hands
# [16:02] * Zakim sees 3:, 5, 6 on the speaker queue
# [16:03] <SimonSapin> Florian: what’s the downside of 3? Same as 1 plus insurance
# [16:03] <SimonSapin> dbaron: plus extra work
# [16:03] <SimonSapin> fantasai: you need to specify both "should" and the alternative
# [16:03] <koji> I can try to define the alternative
# [16:04] <SimonSapin> glazou: 1 wins. Anyone objects?
# [16:04] <koji> ok
# [16:04] * fantasai notes that Microsoft, Blink, and Mozilla reps were all for 1
# [16:04] <SimonSapin> RESOVED: No spec change for WM on table cells
# [16:04] <SimonSapin> RESOVED: No spec change for writing-mode on table cells
# [16:05] <SimonSapin> Topic: propagation of the direction property from <body>
# [16:05] <SimonSapin> fantasai: not really getting information on why would anybody would do that
# [16:05] <SimonSapin> gregwhitworth: faster to make the switch and see how much stuff breaks
# [16:06] <SimonSapin> fantasai: proposal: propagate the dir attr value from body to html
# [16:06] <SimonSapin> fantasai: rather than the direction property
# [16:06] <koji> does the proposal include writing-mode?
# [16:07] <SimonSapin> fantasai: advantage is that the direction property has lots of side effects on the root: scrolling direction, scrolling origin, alignment of things in the root, cascading…
# [16:07] <SimonSapin> fantasai: lots easier and less buggy if none of these things had to be special-cased for body
# [16:07] <SimonSapin> fantasai: only pay attention to direction on the root
# [16:07] <SimonSapin> fantasai: less buggy impls, main question is can we pull that off in web content
# [16:08] <SimonSapin> fantasai: some data, but hard to tell what’s going on
# [16:08] <SimonSapin> fantasai: one survey says the direction property is used in like 88% of web pages, which is ridiculous
# [16:08] <SimonSapin> fantasai: maybe it’s in some library
# [16:08] <SimonSapin> fantasai: one fo the browsers should release a nightly build and see if that works
# [16:08] <SimonSapin> fantasai: lots of simplification in layout engines, consistency, less bugs
# [16:09] <SimonSapin> fantasai: worried about logical properties
# [16:09] * Joins: ChrisL (clilley@public.cloak)
# [16:09] <SimonSapin> dbaron: proposal is that dir attr on body sets the direction property on html?
# [16:09] <SimonSapin> fantasai: yes
# [16:09] * ChrisL less future bugs? Invest today in bug futures!
# [16:09] <SimonSapin> fantasai: it’s only line with a child selector
# [16:10] <SimonSapin> SimonSapin: you mean :has()
# [16:10] <SimonSapin> fantasai: yeah
# [16:10] <SimonSapin> dbaron: you also have to handle dir=auto
# [16:10] <SimonSapin> dbaron: difference on dir=auto on html and body?
# [16:10] <SimonSapin> fantasai: yes, look at the title
# [16:10] <SimonSapin> dbaron: and maybe style and script elements?
# [16:11] <SimonSapin> fantasai: yeah, probably you don’t want to set it on the html elements
# [16:11] <SimonSapin> dbaron: don’t know interop. Gecko’s behavior is a bit random, 5 things that should be propagated but only some do. No good sense of compat risk or how reliable other impls are
# [16:11] <SimonSapin> fantasai: testing showed lots of bugs
# [16:12] <SimonSapin> fantasai: do we want someone implementing this, or more data, or not do this?
# [16:12] <SimonSapin> SimonSapin: in favor of the proposal
# [16:13] <SimonSapin> Bert_: would like to get rid of propagation from body as much as possible, e.g. background
# [16:13] <SimonSapin> fantasai: probably this is the best we can do
# [16:14] * ChrisL html6 to deprecate html, require head inside body
# [16:14] <SimonSapin> fantasai: 2 variations up to HTML WG: 1. propagate the resolved direction (accounts for auto on body, not particularly necessary)
# [16:14] <SimonSapin> 2. just propagate dir=rtl
# [16:14] * Bert_ :-) at ChrisL
# [16:14] <SimonSapin> dbaron: Don’t think the current HTML WG is suited to make this decision
# [16:14] <SimonSapin> fantasai: I mean the people who work on things
# [16:14] <SimonSapin> dbaron: that’s us
# [16:14] <fantasai> html:has(>body[dir=rtl]) { direction: rtl }
# [16:15] <fantasai> html:has(>body:dir(rtl)) { direction: rtl; }
# [16:15] <fantasai> (insert a :not([dir]) after the html there)
# [16:15] <fantasai> I don't think it matters which one we take, both are fine for web-compat, and using dir=auto on <body> is stupid
# [16:16] <SimonSapin> dbaron: probably more sensible to handle dir=auto on body
# [16:16] <SimonSapin> dbaron: makes more sense than on html
# [16:16] <SimonSapin> fantasai: other opinions?
# [16:16] <Bert_> s/e.g. background/background was an anomaly/
# [16:16] <koji> writing-mode?
# [16:16] <SimonSapin> fantasai: works for me
# [16:16] <SimonSapin> glazou: we need to resolve or move on. Good to go?
# [16:17] <SimonSapin> TabAtkins: yeah
# [16:17] <fantasai> koji, I think we have to handle that as a separate issue
# [16:17] <koji> ok, good then
# [16:17] <SimonSapin> gregwhitworth: good to go but we need other impls to follow
# [16:17] <SimonSapin> dbaron: someone just wrote patch, waiting for review. Don’t know if it does what this says
# [16:18] <SimonSapin> gregwhitworth: can we resolve on doing this unless web compat is terrible?
# [16:18] <SimonSapin> fantasai: yes
# [16:18] * Joins: plh (plehegar@public.cloak)
# [16:18] * Joins: quadcore (~user@public.cloak)
# [16:18] <SimonSapin> fantasai: proposed resolution: no propagation of 'direction' from body to html, propagate dir attr with that rule above, back out if web compat problems
# [16:18] <SimonSapin> fantasai: sounds good?
# [16:18] <SimonSapin> glazou: no objection?
# [16:19] <koji> yes, good
# [16:19] <koji> can we also resolve for writing-mode?
# [16:19] <koji> ...or at least discus?
# [16:19] <SimonSapin> RESOLVED: no propagation of 'direction' from body to html, propagate dir attr with `html:not([dir]):has(>body:dir(rtl)) { direction: rtl; }, back out if web compat problems
# [16:20] <SimonSapin> dbaron: if this works, it makes sense not to propagate writing-mode
# [16:20] <SimonSapin> dbaron: if not, keep them together
# [16:20] <SimonSapin> fantasai: seems ok
# [16:20] <koji> but propagating dir attribute implies propagating direciton property, no?
# [16:20] <fantasai> no, it's different
# [16:20] <koji> I prefer propagating writing-mode
# [16:21] <koji> as that's what IE/WebKit/Blink does today AFAIU
# [16:21] <SimonSapin> dbaron: if we want WM to propagate at the CSS level we should undo that resolution and propagate direction at the CSS level as well
# [16:22] <koji> If those two are linked, I'm not ok with the proposal for dir
# [16:22] <SimonSapin> dbaron: though maybe in terms of effect, not necessarily in terms of computed values
# [16:22] <dbaron> dbaron: ... on the root
# [16:23] <SimonSapin> fantasai: we have to figure out what to do for writing-mode. If it has to propagate, direction does too
# [16:23] <SimonSapin> fantasai: IE WebKit Blink all propagate
# [16:23] <SimonSapin> fantasai: issue would be, can we turn it off?
# [16:23] <koji> Quite possible to break lots of EPUB
# [16:24] <SimonSapin> Rossen: In our case, vertical/rtl doesn’t make a difference
# [16:24] <SimonSapin> Rossen: I’m gonna be opposed to different handling
# [16:24] <SimonSapin> fantasai: agreed
# [16:24] <SimonSapin> fantasai: you currently propagate w-m from body to html, wolud you be able to turn that off?
# [16:24] <SimonSapin> Rossen: we can, if everybody else does it at the same time
# [16:25] <SimonSapin> fantasai: other impls are WebKit and Blink
# [16:25] <SimonSapin> TabAtkins: I have no idea
# [16:25] <SimonSapin> gregwhitworth: maybe a good starting point is understand the compat issue
# [16:25] <SimonSapin> fantasai: is is more […], we have more options with direction with the dir attr, but this is only CSS
# [16:26] <SimonSapin> fantasai: sounds like Microsoft is willing is Blink and WebKit also ship without propagation. What is the state of the content you need to deal with?
# [16:27] <SimonSapin> fantasai: concern that there are pages out there that set w-m on body and expect the whole thing to be vertical text
# [16:27] <koji> I don't have data, but estimates it breaks several EPUB content
# [16:27] <SimonSapin> gregwhitworth: do we wanna unresolve?
# [16:27] <SimonSapin> fantasai: we can resolve that direction and w-m need to have the same propagation behavior
# [16:27] <SimonSapin> gregwhitworth: I can give sites that are using w-m on body, be would be good if webkit/blink can also investigate
# [16:28] <SimonSapin> RESOLVED: writing-mode and direction need to have the same propagation behavior, so writing-mode compat affects the previous resolution
# [16:28] <koji> and do we unresolve the previous until we investigate?
# [16:29] <koji> great, thank you
# [16:30] <SimonSapin> fantasai: action item for that?
# [16:30] <SimonSapin> gregwhitworth: I’ll take it, but good if everybody else looks into it
# [16:31] <SimonSapin> gregwhitworth: ebooks and stuff
# [16:31] <SimonSapin> ACTION gregwhitworth Investigate web compat of not propagating writing-mode from body to html
# [16:31] * trackbot is creating a new ACTION.
# [16:31] <trackbot> Created ACTION-687 - Investigate web compat of not propagating writing-mode from body to html [on Greg Whitworth - due 2015-05-26].
# [16:31] <koji> I'll try to look into too
# [16:31] * fantasai notes that result of ebooks layout might not be affected if 7.3.2 is implemented fully ^_^
# [16:32] <SimonSapin> ACTION smfr Investigate web compat of not propagating writing-mode from body to html
# [16:32] * trackbot is creating a new ACTION.
# [16:32] <trackbot> Created ACTION-688 - Investigate web compat of not propagating writing-mode from body to html [on Simon Fraser - due 2015-05-26].
# [16:32] * glazou notes that fantasai types emoji on IRC faster than I can read them
# [16:33] <SimonSapin> fantasai: 7.3.2 is automatic use of multicol. Since ebooks don’t scroll, the default column size is the full size of the viewport. Long horizontal document with vertical columns … ends up with the same result
# [16:33] <SimonSapin> fantasai: only problem with scrollable web page, scrolling origin is in the wrong place
# [16:33] <SimonSapin> fantasai: if you set w-m on body and it doesn’t propagate, you only notice it in scrolling
# [16:34] <SimonSapin> fantasai: you don’t implement auto multicol, it does make a difference
# [16:34] <SimonSapin> fantasai: if you have one long thing and only print the first chunk of it
# [16:35] <SimonSapin> fantasai: might be that we can not popagate if we handle auto multicol in orthogonal flows
# [16:35] <SimonSapin> Topic: SVG
# [16:36] <SimonSapin> fantasai: issue is that writing-mode property will inherit into embedded SVG
# [16:36] <SimonSapin> fantasai: in some cases you want that, if decorating text
# [16:36] <SimonSapin> fantasai: in most cases, that’ll break your coordinate space
# [16:36] <SimonSapin> fantasai: do we block inferitance of writing-mode in SVG?
# [16:36] <SimonSapin> ChrisL: there are lots of cases when inheritance is unwanted
# [16:37] <SimonSapin> ChrisL: MathML doesn’t do vertical text, SVG tries
# [16:37] <SimonSapin> fantasai: you render MathML sideways, it ignores writing-mode
# [16:37] <koji> yeah, but the problem of writing-mode is coordinate system is always physical
# [16:38] <SimonSapin> Rossen: if you have foreign objects with HTML inside, you might want to popagate
# [16:38] <SimonSapin> dbaron: seems like if pasting SVG into HTML, there’s a ton of things that inherit. Fonts, … If you want your SVG to be isolated, not be part of the contxt, you should be using object or img or iframe
# [16:39] <SimonSapin> fantasai: we can block with `all: initial`
# [16:39] <SimonSapin> TabAtkins: except direction, because it shouldn’t have been a CSS property
# [16:39] <SimonSapin> TabAtkins: and unicode-bidi
# [16:39] <SimonSapin> fantasai: we want that to happen at the HTML layer
# [16:40] <SimonSapin> fantasai: direction is not the problem here. If you’re pasting graphics with text, chances are it’s in the same language
# [16:41] <SimonSapin> Doug: confusing either way. Some people will expect either behavior. As long as there is a way to achieve both. Have a way to block all these things at the SVG layer
# [16:41] <SimonSapin> Doug: it’s gonna be confusing for somebody no matter which way we go
# [16:41] <SimonSapin> ChrisL: mention it in the SVG integration spec?
# [16:41] <SimonSapin> fantasai: way to do is set `all: initial` and maybe `direction: intial`. Is that the default? Or does the defalut inherit through?
# [16:42] <SimonSapin> fantasai: 2 things is that `all: initial` would block inheritance, `all: unset` would get it back
# [16:42] <SimonSapin> Doug: Once you see a graphics you don’t expect it to change based on context. So want the default to not propagate.
# [16:43] <SimonSapin> TabAtkins: you’re dropping literal markup
# [16:43] <SimonSapin> Doug: still think it’s more intuitive to opt into propagation
# [16:43] <SimonSapin> fantasai: also run into bugs when the author didn’t look at that particular graphics when translated… or change some font property
# [16:44] <SimonSapin> fantasai: more obvious if the text is off
# [16:44] <SimonSapin> Doug: we don’t know how they’re bringing that markup. Are they using D3?
# [16:45] <SimonSapin> Doug: they could do it in a blog. Blocking is more intuitive, and make it clear how to unblock
# [16:46] <SimonSapin> fantasai: proposed resolution: CSSWG recommends to SVGWG to block inheritance of CSS properties using `all: initial` at the SVG/HTML boundary
# [16:46] <SimonSapin> dbaron: compat risk, this is used.
# [16:46] <SimonSapin> glazou: yes
# [16:46] <SimonSapin> Florian: fine 10 years ago, but SVG is used now with inheritance, we’re changing behavior
# [16:47] <SimonSapin> glazou: SVG editor in Bluegriffon. You can select the whole document and make it bold. It just works.
# [16:47] * Quits: gregwhitworth (~gregwhitworth@public.cloak) (Ping timeout: 180 seconds)
# [16:47] <SimonSapin> glazou: change behavior in a way that may not be understandable
# [16:47] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
# [16:47] * Joins: Florian (~Florian@public.cloak)
# [16:47] <SimonSapin> ChrisL: problem is two situations where people expect opposite things. Not clear which should be the default.
# [16:48] <SimonSapin> Doug: we’re mostly talking about text.
# [16:48] <SimonSapin> TabAtkins: color matters. `fill: currentColor`
# [16:48] <SimonSapin> TabAtkins: it can be done now, we’d be breaking graphics if we change it to black
# [16:48] <SimonSapin> jet: should SVG WG be doing this?
# [16:49] <SimonSapin> fantasai: spec should explain how to do the other behavior
# [16:49] <SimonSapin> Rossen: I’m with dbaron. Web compat is gonna be a chanllenge. If you want to do this, it should be opt-in
# [16:49] <SimonSapin> Florian: should be on the svg element
# [16:49] <SimonSapin> Rossen: too big of a knob
# [16:50] <SimonSapin> ChrisL: the all property is already a big knob
# [16:50] <SimonSapin> Florian: SVG is just an image, or it’s part of the document. Having that switch, that can still be overridden
# [16:51] <SimonSapin> plinss: other problem when people want isolation of style. Why special mechanism just for SVG?
# [16:51] <SimonSapin> ChrisL: SVG seamless
# [16:51] <SimonSapin> leaverou: I though that was a joke
# [16:51] <SimonSapin> ChrisL: when you want to inherit into <object>
# [16:51] <SimonSapin> fantasai: so inherit, and use `all: initial` if your image is screwed up
# [16:52] <SimonSapin> fantasai: need notes on both specs, especially for `writing-mode: unset`
# [16:52] <leaverou> s/ChrisL: SVG seamless/ChrisL: Lea suggested the seamless attribute to do the opposite/
# [16:52] <SimonSapin> fantasai: SVG spec in embedding should talk about this
# [16:52] <SimonSapin> Doug: somebody’s gonna be surprised either way
# [16:52] <SimonSapin> fantasai: if we have exsting content…
# [16:52] * Joins: Florian_ (~Florian@public.cloak)
# [16:53] <leaverou> s/leaverou: I though that was a joke/leaverou: that was more of a joke/
# [16:53] <SimonSapin> RESOLVED: Writing Modes spec adds an example of blocking inheritance into SVG
# [16:53] <SimonSapin> <break duration=15m>
# [16:54] * Quits: Florian (~Florian@public.cloak) (Ping timeout: 180 seconds)
# [16:59] * Joins: shepazu (schepers@public.cloak)
# [17:01] * Quits: Florian_ (~Florian@public.cloak) (Client closed connection)
# [17:02] * Joins: Florian (~Florian@public.cloak)
# [17:08] * Joins: Florian_ (~Florian@public.cloak)
# [17:09] * Quits: Florian (~Florian@public.cloak) (Ping timeout: 180 seconds)
# [17:12] * leaverou is now known as leaverou_away
# [17:15] * Rossen is now known as Rossen_away
# [17:18] * Joins: myakura (~myakura@public.cloak)
# [17:18] * Joins: gregwhitworth (~gregwhitworth@public.cloak)
# [17:19] <gregwhitworth> koji: you there?
# [17:19] <koji> greg: yes
# [17:20] <gregwhitworth> ok, awesome
# [17:20] <gregwhitworth> we're going to get moving again
# [17:20] <koji> thanks
# [17:20] <gregwhitworth> scribenick: gregwhitworth
# [17:21] <gregwhitworth> koji: let us know when you're dialed in
# [17:23] * leaverou_away is now known as leaverou
# [17:23] <koji> I'm already in ;)
# [17:23] <gregwhitworth> thanks
# [17:26] <SimonSapin> Topic: sideways-left
# [17:26] <gregwhitworth> fantasai: we have three keywords
# [17:27] <gregwhitworth> fantasai: depending on the block direction sideways will get you the direction of the non-cjk language
# [17:27] <gregwhitworth> fantasai: as though the block was rotated
# [17:27] <gregwhitworth> fantasai: [shows diagram of sideways props]
# [17:28] <dbaron> fantasai: sideways-right is the same as sideways in vertical-rl (Chinese, Japanese, etc.), but backwards for vertical-lr (Mongolian)
# [17:28] <dbaron> fantasai: reverse for sideways-left
# [17:28] <gregwhitworth> fantasai: you just want to set writing-mode on the root element and have it work
# [17:29] <gregwhitworth> fantasia: this issue we have is implementors have not implemented sideways-left
# [17:29] <leaverou> s/fantasia/fantasai/
# [17:30] * Rossen_away is now known as Rossen
# [17:30] <gregwhitworth> fantasai: because of this if you set vertical-lr together with sideways webkit will give you the sideways-right behavior
# [17:31] <gregwhitworth> florian: isn't the bottom right to embed arabic in english?
# [17:31] <gregwhitworth> fantasai: yes, you're right, there are use cases for this
# [17:31] <gregwhitworth> fantasai: also there is an obscure script for this as well
# [17:32] <ChrisL> https://en.wikipedia.org/wiki/Ogham
# [17:32] <gregwhitworth> fantasai: we have implementors saying sideways-right is good, and sideways, but not sideways-left
# [17:32] <gregwhitworth> fantasai: this is not right, this is a conflict, you can't implement sideways and not implement sideways-left
# [17:33] <gregwhitworth> florian: given what you want for mongolian, do we need sideways?
# [17:33] <gregwhitworth> fantasai: it's trivial, it helps with table captions and doing it automatically
# [17:33] <gregwhitworth> florian: fare enough
# [17:33] * Joins: tantek (~tantek@public.cloak)
# [17:33] <plinss> s/fare/fair/
# [17:34] <gregwhitworth> fantasai: either implement both sideways-left, or drop vertical-lr support, or update the spec
# [17:34] <gregwhitworth> fantasai: we could mark vertical-lr at risk
# [17:34] <gregwhitworth> fantasai: change the meaning of sideways
# [17:35] <gregwhitworth> fantasai: those are the things that we can do for the spec
# [17:35] <gregwhitworth> florian: the naming we have now favors english
# [17:35] <gregwhitworth> florian: maybe we should focus the short keyword on doing the right thing for Asain languages since writing-modes is for fixing these issues
# [17:36] <gregwhitworth> simon: what is the difficulty with sideways-left? And don't you have the same issues with sideways-right and RTL?
# [17:37] <gregwhitworth> fantasai: no the issue is with the coordinate system being different
# [17:37] <gregwhitworth> fantasai: in sideways-left and you may have both of them in a line, you will have a coordinate system for your linebox and then inside of this you may have to flip this for a range of text
# [17:38] <gregwhitworth> dbaron: Gecko implements sideways-right, but not sideways or sideways-left
# [17:38] <gregwhitworth> dbaron: another complication that sideways-left introduces is how floats will work, technically float: left and float: right can be swapped
# [17:39] <gregwhitworth> dbaron: the spec needs to be switched to floats that are on the right/left of the bfc, etc
# [17:39] <gregwhitworth> dbaron: once you introduce sideways-left you may have a bfc where they swap
# [17:39] <dbaron> (that's issue 5 in the spec)
# [17:40] <gregwhitworth> Bert_: why is this different than Japanese?
# [17:40] <gregwhitworth> fantasai: because it works differently and the float will go where it should go like normal, just in vertical
# [17:41] <gregwhitworth> florian: that way float: left would be float: top
# [17:41] <Florian_> ?
# [17:42] <gregwhitworth> ratan: that is how our implementation currently works, it's generic to the bfc
# [17:42] <gregwhitworth> fantasai: we have this issue where webkit is not per spec
# [17:42] <gregwhitworth> fantasai: three options
# [17:42] <gregwhitworth> fantasai: 1) Change meaning of sideways to sideways-right
# [17:42] <dbaron> http://dev.w3.org/csswg/css-writing-modes/#logical-to-physical is a useful table
# [17:43] <gregwhitworth> fantasai: 2) Webkit drops support for sideways keyword
# [17:43] <gregwhitworth> fantasai: 3) webkit drops support for vertical-lr
# [17:43] <gregwhitworth> fantasai: 4)Webkit implements sideways correctly
# [17:43] <gregwhitworth> fantasai: I believe this is the same for Blink as well
# [17:44] <gregwhitworth> florian: Do we actually have a choice or are there compat concerns
# [17:44] <gregwhitworth> fantasai: Not really, there won't be a lot of compat risk
# [17:45] <gregwhitworth> fantasai: The issue when you would hit this, is foregin text in a Mongolian document where this would break compat
# [17:45] <ChrisL> Mongolia: Population, total = 2.84 million (2013)
# [17:45] <gregwhitworth> fantasai: I want to know what WK/Blink think about the options
# [17:45] <gregwhitworth> tabatkins: ¯\_(ツ)_/¯
# [17:46] <koji> As a personal I prefer 1
# [17:47] <gregwhitworth> florian: Number 1 makes the most sense to me
# [17:47] <gregwhitworth> Bert_: Are these values to be used in CJK texts
# [17:47] <gregwhitworth> fantasai: yes
# [17:49] <gregwhitworth> fantasai: if you're embedding a word "O'connor", in CJK languages you would put it in mixed mode and it would look wrong
# [17:49] * Joins: lajava (~javi@public.cloak)
# [17:49] <gregwhitworth> fantasai: you would set [lang-en] {sidways-x} so that they display correctly
# [17:49] <Rossen> http://www.memes.com/m/rEyc
# [17:50] <gregwhitworth> florian: for CJK sideways left and sideways right are actually the same
# [17:50] <gregwhitworth> smfr: I'm looking at some webkit test cases and sideways and sideways-right differ in glyphs used
# [17:50] <gregwhitworth> fantasai: well then that's wrong, the spec is clear that sideways equates to sideways-right
# [17:51] <gregwhitworth> florian: so your sideways, is a kind of mixed not a kind of sideways, so drop it
# [17:51] <gregwhitworth> smfr: but we did this for Japanese books
# [17:53] <gregwhitworth> fantasai: from the testing it looks like we landed on two
# [17:53] * koji ?
# [17:54] <fantasai> koji, do you have a testcase for webkit 'sideways'?
# [17:54] <gregwhitworth> tantek: has webkit ever dropped the support for a keyword
# [17:54] <koji> it used to work as an alias to sideways-right AFAIK
# [17:54] <fantasai> It doesn't seem to atm
# [17:54] <gregwhitworth> tantek: I don't think that we should resolve on it if it's never happened
# [17:54] <fantasai> smfr's testcase works same as mixed
# [17:55] <fantasai> smfr: webkit also says they can change names when dropping prefix
# [17:55] <fantasai> smfr: So, is there still an issue?
# [17:55] <fantasai> s/smfr/koji/
# [17:55] <fantasai> s/smfr/koji/
# [17:55] <fantasai> s/:/,/
# [17:55] <fantasai> s/:/,/
# [17:56] <koji> I'm not really following...so which option WG prefers?
# [17:56] <fantasai> koji, WG testing shows 'text-orientation: sideways' is not supported by WebKit
# [17:56] <fantasai> So, it seems option 2 is ok
# [17:56] <koji> It used to, at least for a few years, and Bllnk does today
# [17:57] <gregwhitworth> fantasai: I need a testcase
# [17:58] <Bert_> Neither writing-mode nor text-orientation is in Safari's documentation.
# [17:58] <fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cdiv%20style%3D%22-webkit-writing-mode%3A%20vertical-lr%3B%20text-orientation%3A%20sideways%22%3ETEXT
# [17:58] * Bert_ is now known as Bert
# [17:59] <fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cdiv%20style%3D%22-webkit-writing-mode%3A%20vertical-lr%3B%20text-orientation%3A%20sideways%22%3ETEXT%E3%81%AE%E3%83%9A%E3%83%BC%E3%82%B8%E3%80%81%E3%82%B9%E3%82%AF%E3%83%AD%E3%83%BC%E3%83%AB%E3%81%8C
# [17:59] <fantasai> Koji< looks like no support
# [17:59] <fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cdiv%20style%3D%22-webkit-writing-mode%3A%20vertical-lr%3B%20-webkit-text-orientation%3A%20sideways%22%3ETEXT%E3%81%AE%E3%83%9A%E3%83%BC%E3%82%B8%E3%80%81%E3%82%B9%E3%82%AF%E3%83%AD%E3%83%BC%E3%83%AB%E3%81%8C
# [17:59] <fantasai> OK, last one is the real thing :)
# [18:00] * Quits: kwkbtr (~kwkbtr@public.cloak) ("")
# [18:00] <fantasai> Note that all properties are prefixed
# [18:00] <fantasai> -webkit-
# [18:00] <koji> I see, because you use vertical-lr
# [18:00] <koji> WebKit supports sideways correctly if vertical-rl
# [18:00] <koji> looks like
# [18:01] <koji> vertical-rl + sideways = mixed in WebKit, but
# [18:01] <koji> s/rl/lr/
# [18:01] <koji> vertical-lr + sideways = sideways-right
# [18:01] <koji> so WebKit does have problems for CJK, not a problem for Mongolian
# [18:02] <gregwhitworth> fantasai: we have two different behaviors for the sideways keyword
# [18:02] <gregwhitworth> fantasai: Blink implements it as sideways-right
# [18:02] <gregwhitworth> fantasai: Webkit implements it as mixed
# [18:03] <gregwhitworth> fantasai: both in vertical-lr mode
# [18:03] <gregwhitworth> florian: since they're prefixed the same there should be no compat hit
# [18:03] <gregwhitworth> fantasai: yeah
# [18:03] * Zakim excuses himself; his presence no longer seems to be needed
# [18:03] * Parts: Zakim (zakim@public.cloak)
# [18:04] <gregwhitworth> dbaron: we're not currently shipping our pref for text-orientation
# [18:04] <koji> Mongolian needs sideways-right anyway, so I guess option 1 works better than option 1?
# [18:04] <gregwhitworth> smfr: we did this for Japanese, so that's probably just a bug
# [18:04] <gregwhitworth> fantasai: I feel like we're leaning towards option 1 or 4
# [18:05] <gregwhitworth> fantasai: there seems like a decent likelyhood that we won't have sideways-left for a while, so I think it's at risk of being dropped, what happens to sideways in that case as we may have web compat
# [18:05] <fantasai> koji, does content depend on unprefixed 'text-orientation: sideways'?
# [18:05] <gregwhitworth> florian: again, it's only in prefixed props for compat
# [18:06] <gregwhitworth> florian: also, it's mainly in books, etc so less likely hood of pre-parsers
# [18:06] <koji> fantasai: don't have data
# [18:06] <gregwhitworth> florian: maybe we should drop them now
# [18:06] <gregwhitworth> dbaron: another option is to keep sideways-left/right and put vertical-lr at risk
# [18:06] <gregwhitworth> fantasai: seems less likely to drop vertical-lr
# [18:07] <gregwhitworth> smfr: I don't think I'd prefer that
# [18:07] <gregwhitworth> tantek: what is the usecase for 2 vs 3 keywords
# [18:07] <gregwhitworth> fantasai: shows the different examples again
# [18:08] <gregwhitworth> fantasia: it's captions on tables or image, and you want to put the block ordering in english
# [18:08] <gregwhitworth> fantasai: the other options are for CJK languages, it doesn't make sense for english
# [18:09] <gregwhitworth> tantek: So for horizontal text written vertically that's the main use case for sideways
# [18:09] <gregwhitworth> florian: yes
# [18:09] <gregwhitworth> SteveZ: It's not easy as you say, what if you want it different on the left than on the right of the document
# [18:09] <gregwhitworth> fantasai: you would change the writing-mode only
# [18:09] <koji> tantek: sideways-left is for English, but sideways-right is used in CJK and Mongolian too
# [18:10] <gregwhitworth> fantasai: the use cases for sideways-left are not that strong
# [18:10] <gregwhitworth> fantasai: but to have sideways, you have to have both sideways-right and sideways-left
# [18:10] <gregwhitworth> tantek: they're not strong, but there are use cases
# [18:10] <koji> and most of the use cases can be achieved by transform:rotate(180deg)
# [18:11] <gregwhitworth> fantasai: yes in books, with tabs in the corner that are rotated, etc
# [18:11] <koji> So I'm not positive to bring in the complexity sideways-left has
# [18:11] <gregwhitworth> tantek: are there any use cases for non-90 degree angles?
# [18:12] <gregwhitworth> fantasai: not currently
# [18:12] * Quits: bcampbell (~chatzilla@public.cloak) (Ping timeout: 180 seconds)
# [18:12] <gregwhitworth> fantasai: we may want to change the keywords to sideways-rl and sideways-lr
# [18:12] <gregwhitworth> florian: I don't think that is better
# [18:13] <gregwhitworth> florian: Typically when embedding a foreign language in Japanese you normally do sideways-right
# [18:13] <gregwhitworth> fantasai: but there are examples of both
# [18:13] <gregwhitworth> tantek: what is the easiest one for authors to remember, if it doesn't actually map to vertical-lr then we probably should change it
# [18:14] <gregwhitworth> dbaron: let's pick an option before moving onto the naming
# [18:14] <gregwhitworth> fantasai: [crosses off number 3]
# [18:15] <gregwhitworth> smfr: when we unprefix, we could change the behavior
# [18:15] <gregwhitworth> fantasai: I think you could change it now, because people aren't really depending on sideways-right in vertical-lr mode
# [18:16] <gregwhitworth> fantasai: [explains options again]
# [18:16] <gregwhitworth> smfr: just spec what people want and we'll change our implementation
# [18:17] <gregwhitworth> WG says to keep 4: Implement sideways correctly (DON'T HAVE BUGS)
# [18:17] <gregwhitworth> smfr: file those bugs and we'll go fix them
# [18:18] <gregwhitworth> RESOLUTION: Clarify the spec to correctly explain how to implement sideways
# [18:19] <gregwhitworth> RESOLUTION: and how to not implement sideways
# [18:19] * Quits: Florian_ (~Florian@public.cloak) (Client closed connection)
# [18:19] * liam_ is now known as liam
# [18:19] * Joins: Florian (~Florian@public.cloak)
# [18:19] <gregwhitworth> RESOLUTION: Don't mark vertical-lr at risk
# [18:20] <gregwhitworth> koji: anymore issues?
# [18:20] <koji> Are there time for issue 10?
# [18:21] <gregwhitworth> fantasai: issue 10
# [18:21] <gregwhitworth> fantasai: let's say you have a vertical block and start writing, and the block gets longer and longer, then you print it chops off the overflow
# [18:22] <gregwhitworth> fantasai: when printing, if you support multicol, when you print the overflow gets put into a multicol that is the size of the viewport height
# [18:22] <gregwhitworth> fantasai: this is good because you have no data loss and this will allow ebooks to still work as well
# [18:22] <gregwhitworth> ChrisL: You said this as though it was magic, but does the stylesheet have this, or does the UA do this
# [18:23] <gregwhitworth> fantasai: the spec currently says that this needs to happen if you overflow, so you would need to put it into multicolumn
# [18:23] <gregwhitworth> ratan: we had this behavior in IE6/7 when you have vertical inside of horizontal, our printing would do what you are saying
# [18:24] <gregwhitworth> ratan: We didn't emulate this in later versions, it wasn't technically too dificult to do but in my opinion if we need to have this it would be easier to do the magic behavior that ChrisL stated
# [18:25] <gregwhitworth> ratan: where when we're paginating that would allow us to keep the layout
# [18:25] <gregwhitworth> fantasai: I'm not recommending this for just printing
# [18:25] <gregwhitworth> SteveZ: isn't this where you would want to do overflow: fragment
# [18:26] <gregwhitworth> tabatkins: sure, multicol was just the way to get the behavior
# [18:26] * Rossen is now known as Rossen_away
# [18:26] <gregwhitworth> fantasai: you don't want copies of the container with it's decorations
# [18:27] <gregwhitworth> fantasai: this is just for autosizing
# [18:27] <gregwhitworth> SteveZ: I would still need to set a height
# [18:27] * Rossen_away is now known as Rossen
# [18:27] <Rossen> s/ratan/Rossen/
# [18:27] <gregwhitworth> dbaron: this seems way too magical
# [18:28] <gregwhitworth> dbaron: I would prefer to do it in simple ways that they can know how to set it up
# [18:28] <gregwhitworth> florian: on the other hand if you're testing on your screen and don't hit this, that causes problems
# [18:29] <gregwhitworth> smfr: there are other ways to cause these issues
# [18:29] <gregwhitworth> plinss: I would like to see a general solution to clipping content to overflow
# [18:29] <gregwhitworth> Bert_: It's not overflowing, the height is auto - you have infinite space in the block direction
# [18:30] <gregwhitworth> fantasai: you don't want to set the height to vh, because you'll cause overflow in the block direction as well
# [18:30] <gregwhitworth> SteveZ: then I agree this is way too magical
# [18:30] <gregwhitworth> Rossen: Also this is really rare
# [18:30] <gregwhitworth> fantasai: The author doesn't print their website ever, it's the user
# [18:31] <gregwhitworth> fantasai: that's why we set to shrink wrap to the viewport height
# [18:31] <gregwhitworth> fantasai: and that causes things to wrap and end up overflowing
# [18:31] <gregwhitworth> SteveZ: I agree that multicol is good solution, but I would prefer to use overflow: fragment
# [18:33] <gregwhitworth> plinss: I like the effect, and what you're trying to do with it, but I don't like the magic and trying to explain pagination using multicol
# [18:33] <gregwhitworth> fantasai: we normally just tile it, but here you don't want to tile it as you'll cut stuff in half
# [18:34] <gregwhitworth> plinss: I just wish we had a better way of explaining pagination
# [18:34] <gregwhitworth> plinss: it feels like overflow: fragmentation is the right way to take this, but we need to mature that space
# [18:36] <gregwhitworth> fantasai: Multicol and fragment are very similiar, but multicol will provide you with the backgrounds and borders you want
# [18:36] * dauwhe +1 to plinss
# [18:36] <gregwhitworth> plinss: I want a better general explanation of this
# [18:36] <gregwhitworth> florian: we've been using multicol as a type of exotic layout, but in this case it is very fundamental in common layouts
# [18:37] <gregwhitworth> florian: the type of behavior it gets you is quite fundamental
# [18:38] <gregwhitworth> plinss: againt the behavior is the correct one, but I don't want it just using multicol under the hood. I want a general set of primitives that explains pagination that people can trigger
# [18:38] <gregwhitworth> fantasai: This is only triggered in an orthogonal flow
# [18:39] <gregwhitworth> Rossen: The spec encourages to set height
# [18:39] <gregwhitworth> SteveZ: I would like to have it work on all heights
# [18:39] <gregwhitworth> fantasai: [draws diagrams showing calculations of heights of cols in an orthogonal flow]
# [18:40] <gregwhitworth> SteveZ: If I print that and I've set the orthogonal flow to 1vh
# [18:40] <gregwhitworth> fantasai: you can't because you can't split the line box
# [18:41] <gregwhitworth> fantasai: we don't have the capability of having variable width columns
# [18:42] <gregwhitworth> ChrisL: This is the type of thing that authors can't control
# [18:43] <gregwhitworth> fantasai: they can set the props themselves and control this, this is only for situations where everything is auto
# [18:44] <gregwhitworth> dbaron: this is making me think things are getting more and more complex, for example I'm considering not investing on grid as it keeps evolving
# [18:44] <gregwhitworth> dbaron: I'm starting to regret working on writing-modes, as I want to be able to ship stuff that are valuable
# [18:45] <gregwhitworth> tabatkins: this is not getting more complex, we're just starting to actually document everything instead of just saying "magic"
# [18:45] <gregwhitworth> tabatkins: this is a common thing that people hit
# [18:45] <gregwhitworth> florian: yes mixed modes are very common in Japenes
# [18:46] <gregwhitworth> tabatkins: I understand your frustration
# [18:46] <gregwhitworth> fantasai: The spec even says what to do if you don't have support for multicol
# [18:47] <gregwhitworth> rossen: in the current Japanese printed world, where you're saying most of them have mixed writing modes, I've never seen them in a magazine
# [18:48] <gregwhitworth> SteveZ: the most likely place you'll see this is in english text quoting Japanese text
# [18:48] * Quits: johanneswilm (~johannes@public.cloak) (Ping timeout: 180 seconds)
# [18:48] <gregwhitworth> SteveZ: The real problem I think is between the switch of captions
# [18:48] <gregwhitworth> Rossen: again these are small chunks, not long long flows of text
# [18:49] * Joins: johanneswilm (~johannes@public.cloak)
# [18:49] <gregwhitworth> smfr: I we trying to do this in L3, or can we defer this until later
# [18:49] <gregwhitworth> fantasai: I think that's ok, but we may run into a few edge cases with this
# [18:49] <gregwhitworth> rossen: I've discussed this case so many times and yet I've never seen it, it's always something small
# [18:50] <gregwhitworth> fantasai: [shows magazine example]
# [18:50] <Bert> (Image from a ftf in 2012: http://www.w3.org/Talks/2012/0509-CSS-ftf/all.htm#challenge5 )
# [18:50] <gregwhitworth> fantasai: talks about how the publishers adjust the layout to make it work just right
# [18:51] <gregwhitworth> fantasai: we don't see what happens when you mess with the layout or change the screen size
# [18:51] <gregwhitworth> fantasai: we should decide on what to do
# [18:52] <tantek> fantasai: we should make it so that it doesn't clip the content
# [18:52] <gregwhitworth> rossen: is anyone asking for this? if this was a very big painful point the entire Japanese publishing would let us know.
# [18:52] <gregwhitworth> fantasai: sure we can defer this, but we should solvet his problem
# [18:53] <gregwhitworth> rossen: I'm not saying that, we're about to add a bunch of magic, that won't be trivial to implement and cause interop issues on something that we aren't commonly told is an actual issue
# [18:53] <gregwhitworth> fantasai: [shows another use case]
# [18:54] <gregwhitworth> SteveZ: I think vh is the wrong thing to use for the line length, I think it would be better to use Xchars in the default font
# [18:55] <gregwhitworth> rossen: I'll add to this, when I implemented orthogonal flows in IE8, when you have a mixed flow and let's say the body has a margin of 100vh you will automatically have a scrollbar even if you don't overflow
# [18:56] <gregwhitworth> rossen: again, I've never heard from people about this problem though
# [18:57] <gregwhitworth> fantasai: I think that ultimately the author would select the correct column height
# [18:57] <gregwhitworth> SteveZ: No one can read that though
# [18:58] <gregwhitworth> SteveZ: My memory, and I can't remember where from, is between 14-16 ems for Japanese
# [18:58] <gregwhitworth> fantasai: As a spec author I'm not going to pick an arbituary set of numbers for font sizes
# [18:58] * Bert 150px if vertical, 300px if horizontal? :-)
# [18:59] <gregwhitworth> tabatkins: She's trying to just provide the same capability for vertical text as horizontal text
# [19:00] <gregwhitworth> plinss: the more I think about this, the more I think this is the right solution for orthogonal flows especailly when you have n levels deep. All my other reservations stand on their own, but on this one I think this is the best solution for this
# [19:00] <gregwhitworth> rossen: what happens if its a scroller, would you still do multicol
# [19:01] * Quits: smfr (~smfr@public.cloak) (smfr)
# [19:01] <gregwhitworth> rossen: I have a a div from overflow: visible to overflow: scroll
# [19:01] <gregwhitworth> florian: it would make sense to remove the multicol
# [19:01] <gregwhitworth> rossen: well that's more fairy dust and magic
# [19:03] <gregwhitworth> fantasai: this will only trigger if you have auto and thus can grow in the infinite direction, a scroller will have a set height
# [19:03] <gregwhitworth> plinss: what is stopping the line from being one long line, something has to be causing it to wrap
# [19:03] <gregwhitworth> fantasai: you don't want to have any line of text that is longer than your viewport
# [19:04] <gregwhitworth> tabatkins: that's the behavior if you don't support multicol or you have line breaks (pointing at css3 multicol example)
# [19:04] <gregwhitworth> SteveZ: I still think there are enough unanswered questions that it should be defered
# [19:05] <gregwhitworth> florian: There is value in shipping this, if not shipping anything at all
# [19:05] <gregwhitworth> SteveZ: But you're not providing anything valuable
# [19:06] <gregwhitworth> fantasai: in the case of fixed height, we're trying to avoid overflowing, which is the whole point of this
# [19:06] <gregwhitworth> SteveZ: All you're doing is coming up with a height for the first block if no height is set
# [19:07] <gregwhitworth> Bert_: You can turn it into a fixed height and multicol
# [19:07] <gregwhitworth> Daniel: This discussion is going no where, let's wrap up
# [19:07] <gregwhitworth> fantasai: I think everyone can agree to add this to the at risk list in the spec, we can agree with that
# [19:07] <gregwhitworth> rossen: yep
# [19:08] <gregwhitworth> fantasai: we'll see where we are
# [19:08] <gregwhitworth> fantasai: if stuff ships and we don't have this, then we'll defer it
# [19:09] <koji> Thank you all and sorry for making lunch late
# [19:14] * Rossen is now known as Rossen_away
# [19:15] * Quits: gregwhitworth (~gregwhitworth@public.cloak) (Ping timeout: 180 seconds)
# [19:20] * Quits: johanneswilm (~johannes@public.cloak) (Ping timeout: 180 seconds)
# [19:25] * Quits: lajava (~javi@public.cloak) (Ping timeout: 180 seconds)
# [19:28] * Quits: renoirb (renoirb@public.cloak) ("Textual IRC Client: www.textualapp.com")
# [19:28] * leaverou is now known as leaverou_away
# [19:32] * Joins: renoirb (renoirb@public.cloak)
# [19:35] * Joins: smfr (~smfr@public.cloak)
# [19:36] * Joins: gregwhitworth (~gregwhitworth@public.cloak)
# [19:36] <gregwhitworth> koji: no problem, thank you for staying up late!!!
# [19:37] * Joins: myles (~Adium@public.cloak)
# [19:38] * Joins: lajava (~javi@public.cloak)
# [19:40] * Joins: johanneswilm (~johannes@public.cloak)
# [19:41] * Quits: gregwhitworth (~gregwhitworth@public.cloak) ("Page closed")
# [19:50] * Quits: smfr (~smfr@public.cloak) (smfr)
# [20:00] * Joins: smfr (~smfr@public.cloak)
# [20:06] * Quits: smfr (~smfr@public.cloak) (smfr)
# [20:06] * Quits: quadcore (~user@public.cloak) ("")
# [20:07] * Joins: c0rt3x (~cortex@public.cloak)
# [20:10] * Joins: smfr (~smfr@public.cloak)
# [20:23] * Joins: gregwhitworth (~gregwhitworth@public.cloak)
# [20:24] * Quits: glazou (~glazou@public.cloak) (glazou)
# [20:26] * Quits: anssik (~uid10742@public.cloak) ("Connection closed for inactivity")
# [20:27] * Quits: andrey-bloomberg (~andrey-bloomberg@public.cloak) (Ping timeout: 180 seconds)
# [20:30] <fantasai> ScribeNick: fantasai
# [20:30] <fantasai> Topic: text-decoration-skip
# [20:30] <fantasai> Florian: A while ago we resolved to add trailing-space value to text-decoration-skip in L4
# [20:31] <fantasai> Florian: When using in combination with pre-wrap, you might have preserved spaces at the end of the line. Do these get underlined or not?
# [20:31] <fantasai> Florian: In MS Word they do not
# [20:31] <fantasai> Florian: We added a new value to be able to control this
# [20:31] <fantasai> Florian: Default currently is underlining everything
# [20:32] <fantasai> tantek: Why add a value for the common case? Why not just make that the default
# [20:32] * Joins: bcampbell (~chatzilla@public.cloak)
# [20:32] <fantasai> tantek: Barring compat problems, the default should be the desired
# [20:32] <fantasai> Florian: One option is underline by default, switch off
# [20:32] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [20:32] <fantasai> Florian: Another option is don't underline by default, switch on
# [20:33] <fantasai> Florian: Third option is auto value by default, which can depend on the type of pre-wrapping
# [20:33] * Joins: dauwhe (~dauwhe@public.cloak)
# [20:33] <fantasai> Florian: Wanted to bring up what the default should be, so that L3 has whatever we think the default shoudl be
# [20:33] <fantasai> Florian: So summary is initial value
# [20:33] <fantasai> 1. objects
# [20:33] <fantasai> 2. objects trailing-spaces
# [20:34] <fantasai> 3. auto (depends on white-space value)
# [20:34] <fantasai> Florian: Related issue is whether to skip leading spaces
# [20:34] * Rossen_away is now known as Rossen
# [20:34] <fantasai> Florian: Judging by word processors, they don't switch behavior based on text-alignment
# [20:34] * Quits: antonp (~Thunderbird@public.cloak) (antonp)
# [20:34] <fantasai> Florian: MS word underlines leading spaces but not trailing spaces
# [20:35] <fantasai> Florian: Not entirely sure if intentional to be assymmetric
# [20:35] * Quits: c0rt3x (~cortex@public.cloak) ("")
# [20:35] <fantasai> tantek: Leading spaces are visible, so kindof make sense. Trailing spaces are invisible
# [20:35] <fantasai> Florian: That's true for left-alignment. Not true for right-alignment
# [20:35] <fantasai> tantek: Would be good to know if there's even a single web page with right-aligned pre-wrap text
# [20:35] <fantasai> fantasai: Probably not
# [20:36] <fantasai> fantasai: I would prefer to keep the behavior symmetric
# [20:36] <fantasai> fantasai: Another consideration is that underlining indicates links, and those spaces are clickable
# [20:37] * Quits: myakura (~myakura@public.cloak) (Client closed connection)
# [20:37] <fantasai> gregwhitworth: What is % use cases for links vs decoration?
# [20:37] <fantasai> Florian: pre/pre-wrap used a lot for code
# [20:37] * Joins: myakura (~myakura@public.cloak)
# [20:37] <fantasai> Florian: trailing spaces affect layout in pre-wrap
# [20:38] <fantasai> fantasai: If we're doing for pre-wrap, should do it for pre
# [20:38] <fantasai> fantasai: I think if we didn't use underlining for links, then I would say don't underline leading or trailing spaces. Looks better.
# [20:39] * Joins: ctcptest (~ctcptest@public.cloak)
# [20:39] <fantasai> fantasai: But since we do, I think we should default to underlining
# [20:39] <fantasai> fantasai: Since that indicates the clickable area
# [20:39] <fantasai> Bo: We looked into use of underlining, and it's almost always used for links.
# [20:39] <fantasai> Bo: were considering, for a11y, to restrict underlining to just links, and it didn't seem like it would be a problem.
# [20:41] <fantasai> Florian describes case of link breaking across lines, with leading/trailing spaces
# [20:42] <fantasai> tantek: I don't buy the argument that we should underline the spaces because they're clickable.
# [20:42] <fantasai> tantek: Blocks have plenty of space that are clickable, not underlined
# [20:43] <fantasai> ...
# [20:43] <fantasai> Florian: ...
# [20:44] <fantasai> fantasai: I don't have a strong preference on underlining vs not-underlining
# [20:44] <fantasai> fantasai: But want leading/trailing to be symmetric
# [20:44] <fantasai> tantek: Don't buy that argument
# [20:44] <fantasai> Florian: People use spaces for indentation, want them underlined
# [20:44] * Quits: myakura (~myakura@public.cloak) (Ping timeout: 180 seconds)
# [20:44] <fantasai> fantasai: Really? That looks terrible. Why is that wanted?
# [20:44] <fantasai> [discussion of what is ugly]
# [20:45] <fantasai> gregwhitworth: I think we should put all three options on the board, point at the ugly one, and say, don't do that.
# [20:45] <fantasai> plinss: For diff tracking, want to show underlining on spaces as well, to show what exactly is added/removed
# [20:46] <fantasai> tantek: Can't imagine you want to see underlines, unless you're trying to show where the spaces are for some reason.
# [20:47] * Joins: glazou (~glazou@public.cloak)
# [20:47] <fantasai> plinss: Might make sense to have the default be one way, but have the UA default style sheet for <ins>, <del>, , <s> not skip anything
# [20:48] <fantasai> fantasai: I don't think we can change default behavior for and images.
# [20:48] * leaverou_away is now known as leaverou
# [20:48] <fantasai> Florian: So, proposal is to skip leading/trailing by default.
# [20:49] <fantasai> Florian: And UA stylesheet for <ins>/<del> underlines spaces
# [20:49] <fantasai> Unsure on /<s>
# [20:49] <fantasai> Florian: Implies we add leading-spaces
# [20:49] <fantasai> fantasai: Or edge-spaces
# [20:50] <fantasai> Florian: Good point. Do we need them separately-controllable?
# [20:51] <fantasai> tantek: MS Word does that. Probably not an accident
# [20:51] <fantasai> fantasai: I'm not so sure about that....
# [20:51] <fantasai> Florian: So anyway, proposal is that initial value skips objects, leading and trailing spaces
# [20:52] * Yves sets mode: +b *!*ctcptest@*
# [20:52] <fantasai> Florian: Suggest that UA stylesheet skips nothing for <ins> and <del>, skips objects (as currently) for and <s>
# [20:52] * Quits: ctcptest (~ctcptest@public.cloak) (KILLed by Yves: (requested))
# [20:53] <fantasai> ...
# [20:53] <fantasai> dbaron: Seems weird to change default behavior and change that in the UA sheet for a couple elements.
# [20:53] <fantasai> plinss: ...
# [20:54] <fantasai> dbaron: I suspect most of the text decoration on the web is not and <s>; treating those as especially legacy seems odd
# [20:54] <fantasai> Florian: Proposal makes sense to me, but breaks compat
# [20:56] <fantasai> dbaron: I think I'm fine to change the default for the property. Can see use case for having different behavior on <ins>/<del>. Think it's weird to treat and <s> differently from the default.
# [20:56] <fantasai> dbaron: One more quirk I'd rather not add, unless there's a good argument for it.
# [20:57] <fantasai> Revised proposal: skip leading/trailing spaces, <ins>/<del> don't skip anything
# [20:57] <fantasai> proposal: add leading-spaces / trailing-spaces values to text-decoration-skip
# [20:57] <fantasai> fantasai: I'm OK with the new defaults, a little unsure about the two keywords
# [20:58] <fantasai> tantek: Worth putting in draft, then see if anyone screams
# [20:59] <fantasai> Florian: L3 or L4?
# [20:59] <fantasai> fantasai: I think we should put into L4 draft, get some feedback, add a note in L3 that we might switch default behavior as in [this draft over here]
# [20:59] <fantasai> fantasai: in a future CR update
# [21:02] <fantasai> tantek: Make a stronger statement -- it's resolved, not might happen
# [21:02] <fantasai> tantek: Capture the fact that there's a consensus on the changing
# [21:02] <fantasai> Bert asserts that WDs can change
# [21:02] <fantasai> plinss suggests we move on
# [21:02] <fantasai> fantasai^: We can change the default easily in L3, but wouldn't be able to add UA stylesheet rules without the new values from L4.
# [21:03] <fantasai> RESOLVED: Add leading-spaces/trailing-spaces to text-decoration-skip in L4. Change default behavior to skip leading/trailing spaces. Add UA rule that <ins>/<del> don't skip anything. Add note from L3 to L4 indicating impending changes.
# [21:04] <fantasai> Florian: Can't change behavior without new keywords
# [21:04] <fantasai> fantasai: sure we can
# [21:05] <fantasai> fantasai: another issue is, this is getting unweildy. To skip one new thing, need to re-specify the whole initial value, which is now three long values
# [21:06] * Joins: andrey-bloomberg (~andrey-bloomberg@public.cloak)
# [21:06] <fantasai> plinss: Let's refine it in L4. L3 is in CR, stable for 2 years
# [21:06] <fantasai> plinss: Moving on.
# [21:06] <fantasai> Topic: Box % sizing
# [21:08] <Bert> (So that implies the initial value in L4 will change to 'objects trailing leading'? Seems fine, but just verifying...)
# [21:08] <Florian> Bert: yes
# [21:09] <Bert> s/Bert:/Bert,/
# [21:09] <fantasai> Rossen: This was a discussion brought up a couple months ago. Brought up by blink team, wrt implementing flex
# [21:10] <fantasai> Rossen: They came back and said that resolving top and bottom pecentages for padding and margin out of height instead of width kindof doesn't make sense to us and harder to implement for us
# [21:10] <fantasai> Rossen: Bunch of discussion of what is expected behavior, why does it make sense to have top/bottom % to resolve against width rather than height
# [21:11] <fantasai> Rossen: In summary there was some exchange back and forth
# [21:11] <fantasai> Rossen: Having symmetric layout makes a lot of sense for app-centric layout
# [21:11] <fantasai> Rossen: Other behavior makes more sense for auto-height document flows
# [21:12] <Rossen> http://jsbin.com/pekiyuqalu/1/edit?output
# [21:12] * fantasai kindof leans towards Ojan's POV on this issue
# [21:12] <fantasai> Rossen: There's a fixed-size div with items with % padding and % width/height
# [21:12] <fantasai> Rossen: One thing we identified early on in flex development
# [21:12] <fantasai> Rossen: is that being able to stretch inside flex items is really useful
# [21:13] <fantasai> Rossen: Here when I have 100% to the inner item, in the case of documen tflow that will compute to auto because its parent has height auto
# [21:13] <fantasai> Rossen: That means that the height will be shrink-to-fit
# [21:13] <fantasai> Rossen: If this were a flex item, the height of the inner item would actually resolve to 100% of the available height
# [21:13] <fantasai> Rossen: That happens because the flex item is stretched by default
# [21:14] <fantasai> Rossen: The one pattern that we can start noticing here is that in traditional flow layout, usually people think of the document in some kind of continuous media.
# [21:14] <fantasai> Rossen: Things wrap, maybe have some tables, but the only thing you can take a hard dependency on is the available width
# [21:14] <fantasai> Rossen: This is what we resolve most percentages out of
# [21:14] <fantasai> Rossen: All horizontal % resolve against width, as well as padding and margin in the vertical dimension
# [21:14] <fantasai> Rossen: All of these values resolve from this available width
# [21:15] <fantasai> Rossen: If you have % height, that's a hard problem, we'll just default to autl
# [21:15] <fantasai> Rossen: And we have this kind of assymmetric behavior
# [21:15] <fantasai> Rossen: Flexbox, as well as Grid, started taking a different direction
# [21:16] <fantasai> Rossen: How about we figure out a way to fix both the widht and the height, so that when resolving percent ...
# [21:16] <fantasai> Rossen: If I have an item which has % width, resolves against width.
# [21:16] <fantasai> Rossen: If I have an item with % height, should resolve against height
# [21:16] <fantasai> Rossen: This is how we specced flexbox
# [21:16] <fantasai> Rossen: And grid
# [21:17] <fantasai> Rossen: In this example, we have percentage height, width, padding
# [21:17] <fantasai> Rossen: Both horizontal and vertical ...
# [21:18] <fantasai> Rossen: If I specify margin or padding with just one number, want the same size all around -- resolve it from just one of these dimensions
# [21:18] <fantasai> Rossen: That is a valid use case
# [21:18] <fantasai> Rossen: You can use grid or flexbox to have layout that simulates flow layout
# [21:18] <fantasai> Rossen: I think the one use case that was brough up was an image gallery, e.g. 4 columns, want to have equal margins around photo in both dimensions
# [21:19] <fantasai> Rossen: This is Chrome's implementation. Here's it's a block. If I switch and make it a flex item...
# [21:20] <Rossen> http://jsbin.com/rivisiyifa/1/edit?output
# [21:20] <fantasai> Rossen: Point I'm trying to make is that the flex implementation in Chrome will look basically like so...
# [21:21] <fantasai> Rossen: This is our current implementation in Edge
# [21:21] <fantasai> Rossen: We resolve padding and margins against the available width
# [21:21] <fantasai> Rossen: The height is still 100%
# [21:21] * fantasai is getting very confused
# [21:21] <fantasai> Rossen: All heights are hard, now we're like theyr'e kinda sort of hard. Saying paddings and margins are hard.
# [21:21] <fantasai> Rossen: This isn't really quirky behavior
# [21:22] <fantasai> Rossen: One proposed solution that we came up with was to have a switch basically that allows both of these
# [21:22] <fantasai> Rossen: If you want to have block-layout % resolution, should be able to express that
# [21:22] <fantasai> Rossen: And if you want it symmetric, should be able to express that
# [21:22] <fantasai> Rossen: And this example does exactly that.
# [21:22] <fantasai> Rossen: On :hover, I'm triggering box-percent-sizing: symmetric
# [21:22] * ChrisL 50 shades of quirkiness
# [21:23] <fantasai> Rossen: (This is just a demo on my box, not going anywhere besides this room.)
# [21:23] <fantasai> Rossen: To me, it still seems strange that we are going to the extent of resolving the heights, but not resolving top and bottom paddings
# [21:24] <fantasai> TabAtkins: If flexbox is auto-sized, but flex item is % height, it will resolve
# [21:24] <fantasai> Rossen shows through example
# [21:25] <fantasai> Rossen: We're going to a greater effort to define available width and available height that you can depend on.
# [21:25] <fantasai> Rossen: We measure the content, then go back to define the available height
# [21:25] <fantasai> Rossen: Allows % to resolve
# [21:25] <fantasai> Rossen: So we're doing a lot of work to keep this symmetric between available widths and heights.
# [21:26] <fantasai> TabAtkins: I agreed with you at first. That's why we specified the way it is today.
# [21:26] <fantasai> TabAtkins: Our implementers view is that, yes, while it is slightly more difficult for us to implement, that's besides the point.
# [21:27] <fantasai> TabAtkins: However, our reason for not wanting to implement this is largely
# [21:27] <fantasai> TabAtkins: nobody cares. They're not used much for anything, except one thing: hack to do aspect ratios
# [21:27] <fantasai> TabAtkins: A lot of people using this hack to do aspect ratios
# [21:27] <fantasai> TabAtkins: This padding hack no longer works in flexbox
# [21:27] <fantasai> TabAtkins: And Mozilla gets bug reports about this
# [21:28] <fantasai> TabAtkins: We're not opposed to having a switch, but want block behavior to be the default
# [21:28] <fantasai> tantek: You're seriously using aspect ratio hack for this?
# [21:28] <fantasai> TabAtkins: Yeah
# [21:28] <fantasai> dbaron: What is this hack?
# [21:29] <fantasai> TabAtkins: Say you want a variable-size element to always maintain a 2:1 aspect ratio
# [21:29] <leaverou> Sorry for pointing out the obvious but if we all know that aspect ratio is needed a lot, why aren't we discussing how to add an aspect-ratio property instead?
# [21:29] <fantasai> TabAtkins: You give the parent padding: 50%, relpos, and make the child abspos to fill that
# [21:29] <tantek> leaverou++
# [21:30] <fantasai> TabAtkins: No opposition to that. I put up a bad proposal for it.
# [21:30] <fantasai> TabAtkins: My proposal was bad. It has problems. Should feel bad.
# [21:30] <fantasai> TabAtkins: At some point, will do it properly. But in the meantime, this hack is where we're at.
# [21:31] <fantasai> TabAtkins: Anyway, that's our argument for wanting to revert the change.
# [21:32] <fantasai> fantasai: I disagree with having a switch. Mode switches for interpreting existing rules are problematic, when they combine with declarations that weren't expecting it.
# [21:32] <fantasai> gregwhitworth: Like box-sizing
# [21:32] <fantasai> fantasai: Right
# [21:32] <fantasai> gregwhitworth: Would have been better to be symmetric from get-go
# [21:32] <fantasai> tantek: yes
# [21:32] <TabAtkins> <wrapper style="position: relative; padding-top:50%"><real-stuff style="position: absolute; t/r/b/l: 0">...</real-stuff></wrapper>
# [21:33] <fantasai> Rossen shows example of using eprcentages
# [21:33] <tantek> except with box-sizing, we made it a switch because that was the default behavior that web authors/designers actually *wanted* instead of the CSS1 spec'd default
# [21:33] <fantasai> TabAtkins: In this example you could have used 3px
# [21:33] <tantek> also - units wouldn't have solved box-sizing :P
# [21:33] <fantasai> gregwhitworth: On a bigger screen, e.g. 75in TV, want it to be bigger.
# [21:33] <fantasai> gregwhitworth: percentages are much more responsive than just using pixels
# [21:34] <fantasai> TabAtkins: Case like this, the difference is pretty minimal
# [21:34] <fantasai> TabAtkins: You could continue using the same thing, and it would work fine resolving against the width
# [21:35] <fantasai> gregwhitworth: It makes more sense to resolve in your own dimension
# [21:35] <fantasai> TabAtkins: We agree it makes more sense. But nobody cares.
# [21:35] <fantasai> TabAtkins: Percentage margins/paddings are extremely rare. Main use is just the aspect-ratio hack
# [21:35] * Quits: SteveZ (~SteveZ@public.cloak) (Ping timeout: 180 seconds)
# [21:36] <fantasai> gregwhitworth: You went into this idealistically, changed your mind when implementability came up.
# [21:36] * Quits: smfr (~smfr@public.cloak) (smfr)
# [21:36] <fantasai> TabAtkins: They presented me with convincing data that nobody cared.
# [21:37] <fantasai> fantasai: To be fair, Tab and I were pretty ambivalent about which way to go.
# [21:37] <fantasai> Issue was Grid spec and Flexbox disagreed, and we wanted them to match. Ended up picking Grid since it seemed reasonable at the time.
# [21:37] * trackbot doesn't understand that ISSUE command.
# [21:37] <shane> an example of the bugs filed on firefox that Tab was talking about: https://bugzilla.mozilla.org/show_bug.cgi?id=958714
# [21:38] * ChrisL trackbot, go home you are drunk
# [21:38] <trackbot> Sorry, ChrisL, I don't understand 'trackbot, go home you are drunk'. Please refer to <http://www.w3.org/2005/06/tracker/irc> for help.
# [21:40] <fantasai> fantasai: My opinion is that, having read Ojan's argument, I agree with keeping things consistent across our layout systems
# [21:40] <fantasai> fantasai: However, concerend wrt compat in changing Grid to match that. [Flexbox is incompatibility]
# [21:40] <fantasai> fantasai: But not super strong opinion.
# [21:40] <fantasai> dbaron: Also don't have a super strong opinion...
# [21:41] <fantasai> dbaron: But block layout has a much stronger widths as input, height as output
# [21:41] <fantasai> dbaron: Grid/Flexbox take input in both dimensions, differnet model, percentages this way makes more sense.
# [21:41] * fantasai unsure if that was correct
# [21:41] <fantasai> dbaron: Don't think aspect-ratio hack is a reason to keep this.
# [21:41] <fantasai> tantek: Agree with that. If they want hacks, we can give them hacks.
# [21:42] <fantasai> gregwhitworth: Resolving percent margins/padding against width doesn't make sense. App developers would be happier with percentages resolved against height.
# [21:43] * Joins: smfr (~smfr@public.cloak)
# [21:43] <fantasai> tantek: App developers don't speak up to browsers. We don't speak up for them, nobody does
# [21:43] * Quits: gregwhitworth (~gregwhitworth@public.cloak) (Ping timeout: 180 seconds)
# [21:43] <fantasai> Rossen: we do speak for them. Have a lot of app developers for Windows apps
# [21:43] <fantasai> Rossen: People who come from Java or C based application backgroundsis very different than conversations with ppl who started on the web
# [21:43] <tantek> which is why I'm agreeing with you Rossen
# [21:43] <fantasai> Rossen: Most of these papers are used to driving their layout apps much closer than with HTML/CSS
# [21:44] <fantasai> Rossen: Our struggle has been, for the first year or two, was "how do we get them out of abspos?"
# [21:44] <fantasai> Rossen: Once started learing how grid & flex work, how easy it is, much more performant, was a big Aha moment.
# [21:44] <fantasai> Rossen: And now converted.
# [21:44] <fantasai> Rossen: To the point that XAML team is getting requests to be more like HTML/CSS
# [21:45] <fantasai> TabAtkins: We're down with a switch, as long as default behavior is the old behavior
# [21:45] <fantasai> fantasai: And I'm not ok with a switch
# [21:45] <fantasai> dbaron: I don't think I'm ok with a switch either, for two reasons
# [21:45] <fantasai> dbaron: One is that I don't like switches.
# [21:45] <fantasai> dbaron: Two is that I'm not sure how easy it is to do the new behavior for blocks.
# [21:45] <fantasai> TabAtkins: would just go down to zero in most cases
# [21:45] <fantasai> dbaron: The current behavior is % margins on flex items.
# [21:46] <fantasai> TabAtkins: And grid items
# [21:46] <fantasai> shane: In the case of Android, you just can't specify percentage margins or padding
# [21:46] <fantasai> ?: Or iOS
# [21:46] <fantasai> shane: App dev platforms don't have percentages
# [21:46] <fantasai> tantek: What? Interface Builder totally had that in the 90s....
# [21:47] <fantasai> shane: Goes back to what Tab was saying. ppl don't use this, except in the case of this hack
# [21:47] <fantasai> TabAtkins: It's extremely rare
# [21:47] * Quits: smfr (~smfr@public.cloak) (smfr)
# [21:47] <fantasai> greg: I've used that a lot...
# [21:47] <fantasai> TabAtkins: Couldn't have, wouldn't work.
# [21:48] <fantasai> greg: I can guarantee % are not all aspect-ratio hack.
# [21:48] <fantasai> TabAtkins: Most cases where I've used them in the past, I would just use flexbox or grid for it, and it would work automatically.
# [21:48] <fantasai> TabAtkins: My only web-dev cases for using margins/paddings are more-or-less gone
# [21:48] <fantasai> Florian: Also box-sizing
# [21:49] <fantasai> fantasai: Yeah, a lot of cases are probably "I need to use percentages, because I have to do math that adds up to 100%"
# [21:49] <fantasai> TabAtkins: Almost always want borders to be consistent all the way around
# [21:50] <fantasai> Florian: Want things in percent so that horizontally things add up to 100%. Vertical is auto-sized, sizes are consistent
# [21:50] <fantasai> greg: What do you think, dbaron? Right now we're in a bad place. IE and Mozilla agree on this.
# [21:51] <fantasai> greg: But we don't have interop
# [21:51] <fantasai> dbaron: I wasn't convinced that anything needed to change.
# [21:51] <fantasai> dbaron: I guess Ojan is not happy about changing chrome
# [21:51] <fantasai> TabAtkins: worst case, we would change. Would highly prefer not to, not so much for implementation reasons, but because we don't believe this is the right thing to do
# [21:52] <fantasai> SteveZ: It seems to me whether or not there is usage today in percentage padding, people would have liekd to use it, you couldn't do it with unresolved height
# [21:52] <fantasai> SteveZ: Coming up with a definition that only really works for a hack, which we should do a better way eventually, seems like the wrong way to design a system.
# [21:52] <fantasai> TabAtkins: From a theoretical POV I agree.
# [21:53] <fantasai> fantasai: I don't think aspect-ratio hack would be a reason to keep this.
# [21:53] <fantasai> SteveZ: I came away with wanting to switch
# [21:53] <fantasai> SteveZ: Want a uniform size all the way around.
# [21:53] <fantasai> SteveZ: So I want that ability
# [21:54] <fantasai> SteveZ: but also want the ability to resolve margins/padding against the available height
# [21:54] <fantasai> TabAtkins: We don't see this being used
# [21:54] <fantasai> greg: You can't
# [21:54] <fantasai> TabAtkins: We don't see it in the width dimension either
# [21:54] <fantasai> dbaron: It does seem there is a use case for people who want something evenly around the entire size
# [21:55] <fantasai> ...
# [21:55] <fantasai> Florian: There' sno right way for box-sizing
# [21:55] <fantasai> Several: No, border-box is the right way
# [21:55] <fantasai> dbaron: The other thing we could have instead of switch is different set of units
# [21:56] <fantasai> dbaron: percents in either dimension
# [21:56] <fantasai> fantasai: pi and pb
# [21:56] <dbaron> or i% and b%
# [21:56] <fantasai> s/dimension/ inline percents and block percents/
# [21:56] * shane thinks they should be 'fizz' and 'buzz'
# [21:56] <fantasai> TabAtkins: We can't parse i%
# [21:57] <Bert> (ip and vp would parse)
# [21:57] <fantasai> Florian: Could also have the switch be a keyword rather than the property
# [21:57] <fantasai> Rossen: ...
# [21:57] <fantasai> Rossen: One model is you have content that dictates how it's going to behavio in a particular container
# [21:57] <fantasai> Rossen: Other one is container dictating how things are distributed on that level
# [21:58] * fantasai is ok with units, proposed that last time we discussed in fact
# [21:58] * fantasai doesn't want switch property
# [21:58] <Bert> ('padding-top: 5% independent')
# [21:58] <fantasai> Someone mentions calc(5ip + 7bp)
# [21:59] <fantasai> plinss: Lets you get into some really circular situations
# [21:59] <fantasai> plinss: You'd have to be really careful about where you can use them
# [21:59] <fantasai> dbaron: Percentages on some of these propertis are function of a size of the parent
# [21:59] <fantasai> dbaron: And if cyclic, treated as auto
# [21:59] <fantasai> dbaron: fall back to zero
# [21:59] <fantasai> dbaron: those rules would continue to hold
# [22:00] <fantasai> TabAtkins: Define it as part of <percentage>
# [22:00] <fantasai> fantasai: Don't think you want to do that. E.g. line-height, font-size, not really useful
# [22:00] <fantasai> dbaron: Only want them in certain functions that take <length> and <percentage> and percentage is relative to size of the parent
# [22:01] <fantasai> Florian: This is why I think a special keyword would make more sense...
# [22:01] <fantasai> ...
# [22:01] <fantasai> TabAtkins: SVG has some things that use length of diagonal, could finally calc() that
# [22:02] <fantasai> plinss: So, are we getting to a resolution?
# [22:03] <fantasai> Proposals
# [22:03] <fantasai> 1. global switch
# [22:03] <fantasai> box-percent-sizing
# [22:04] <fantasai> 2. switch as keyword
# [22:04] <fantasai> on some properties
# [22:04] * Joins: smfr (~smfr@public.cloak)
# [22:05] <fantasai> 3. ip + bp, usable in some places
# [22:05] <leaverou> fantasai: it could be useful for line-height, to fit a specific number of lines in a container with a fixed height.
# [22:06] <fantasai> 4. Nothing, settle on block
# [22:06] <fantasai> 5. Nothing, settle on symmetry
# [22:06] <fantasai> fantasai: I think 4-5 need to be combined
# [22:07] <fantasai> Florian: I just specced box-sizing, and having done that work, #1 looks like a terrible idea
# [22:07] <fantasai> Rossen: ...
# [22:07] <fantasai> tantek: No, I agree with Florian, this is much worse
# [22:08] <fantasai> greg: This is just margin/padding
# [22:08] <fantasai> fantasai: How do we know? It's called box-percent-sizing. Could also affect width/height
# [22:08] <fantasai> Rossen: Only discussing effect on margin/padding.
# [22:08] <fantasai> fantasai: 2 & 3 are strictly more powerful
# [22:09] <fantasai> fantasai: could have margins/padding be different
# [22:09] <fantasai> fantasai: Also doesn't have cascading problems
# [22:10] <fantasai> fantasai: The cascading problem is like this
# [22:10] <astearns> would ip and bp have too many restrictions on use (bp on height of floats, for example)?
# [22:11] <fantasai> fantasai: Somebody writes a declaration in percentages, expecting it to work a certain way
# [22:11] <fantasai> fantasai: Somebody else writes a box-percentage-sizing rule together with his percentage declration, expecting it to work together in that way
# [22:11] <fantasai> fantasai: The box-percentage-sizing rule ends up affecting the first declaration, changing the way it's interpreted in a way that's not expected
# [22:12] * Quits: lajava (~javi@public.cloak) (Ping timeout: 180 seconds)
# [22:13] <fantasai> Rossen: My choice is 1, but prefer 5.
# [22:14] <fantasai> Florian explains difference between 1 and 2
# [22:15] <fantasai> Florian: 2 puts keywords in margin/padding declarations, so you can have margins and paddings have different values.
# [22:15] <fantasai> Florian: Also doesn't have the cascading problem fantasai pointed out
# [22:15] <fantasai> shane: 3 is better for object model
# [22:15] <fantasai> TabAtkins: not sure about that, think it's fine
# [22:16] <fantasai> dbaron: 2 questions
# [22:16] <fantasai> dbaron: 1. Should we have a switch? 2. If so, which one? 3. What is the flexbox/grid default?
# [22:16] <leaverou> A benefit of using units is that we can in the future extend the cases they can be used in, whereas we can't change how a switch behaves.
# [22:17] <tantek> 1. no, 2. ø, 3. flexbox/grid % based on height, not block
# [22:17] <fantasai> we can't change how a global switch behaves, but can change 2 or 3
# [22:17] <fantasai> plinss: 4 vs 5
# [22:18] <dbaron> #4 - 5 votes (tab, bert, fantasai, shane, ian)
# [22:18] <dbaron> #5 - 5 votes (steve, greg, peter, rossen, tantek)
# [22:18] <dbaron> (others abstaining)
# [22:21] <fantasai> Rossen asks for feedback from lea and tantek
# [22:22] * astearns must be confused as to what 'block' and 'symmetry' mean in these choices
# [22:22] <fantasai> leaverou: I think #3 is my preference. We can't extend a global switch, but we can extend where units can be used.
# [22:22] <fantasai> leaverou: #2 is awkward, espeically if you use the keyword in places where you have multi-valued / complex values
# [22:22] <fantasai> leaverou: I think authors are already use dto percentages resolving against widths, even for vertical margins/paddings
# [22:22] <SimonSapin> astearns, "like display:block", and "percentages refer to the same direction"
# [22:22] <fantasai> leaverou: So I think there's a learnability benefit there
# [22:22] <fantasai> leaverou: Even though, if we were designing from scratch, would be better to resolve from height
# [22:22] * Rossen is now known as Rossen_away
# [22:22] * Quits: plh (plehegar@public.cloak) ("Leaving")
# [22:22] <fantasai> leaverou: but many years from against height
# [22:22] <fantasai> tantek: I actually disagree with that. This is a constant source of confusion. Would like it to stop being a source of confusion
# [22:22] <fantasai> tantek: This confuses *everybody* using CSS
# [22:22] <fantasai> tantek: We have this change to get Flex and Grid right, as layout modes
# [22:22] <fantasai> tantek: Customers that use that kind of layout on native platforms
# [22:23] <fantasai> tantek: Better to say "hey, use this new layout mode that does it right"
# [22:23] <fantasai> tantek: Lower barrier to entry, reduce number of things that make you go "huh?"
# [22:23] <astearns> agrees with tantek
# [22:23] <fantasai> leaverou: but old models still work the old way
# [22:24] <fantasai> tantek: What models? Goal of flex and grid is to not need to learn that stuff.
# [22:24] <fantasai> Florian: Nice speech. Add my vote to #5
# [22:24] * fantasai might switch too :)
# [22:25] <fantasai> greg and Tab argue over compat loads of Blink flexbox and Microsoft grid
# [22:25] * fantasai block means block-layout rules symmetry means resolve against your own axis
# [22:26] * Joins: myakura (~myakura@public.cloak)
# [22:26] <fantasai> SteveZ: You can get 3 on 2 by having 2 keywords, keywords being 'inline ' or 'block, and still use percentage value
# [22:26] <fantasai> TabAtkins: We only got two responses when we asked authors for feedback
# [22:27] <fantasai> TabAtkins: two non-sequiturs
# [22:27] * astearns was reading 'symmetry' as the margins are all symmetrical :)
# [22:27] <fantasai> fantasai: No, one was a valid answer
# [22:27] * fantasai sorry :)
# [22:27] <fantasai> smfr: Dave Hyatt is willing to change WebKit to #5
# [22:27] <fantasai> plinss: In light of discussion, let's redo the vote
# [22:28] <fantasai> #4 - 3 votes ( shane, TabAtkins , Bert)
# [22:28] <dbaron> + Ian
# [22:28] <fantasai> #5 - 12 (smfr, Florian, dbaron, steveZ, Andrey, Jet, Chris, Lea, Greg, rossen, plinss, tantek)
# [22:28] * Bert thinks a CSS-T without flexbox and a CSS-U with *only* flexbox would make sense, but attempts in the past failed and they seem stuck together forever.
# [22:29] <fantasai> #5 - 13 (smfr, Florian, dbaron, steveZ, Andrey, Jet, Chris, Lea, Greg, rossen, plinss, tantek, asteans)
# [22:29] <fantasai> #4 - 4 votes ( shane, TabAtkins , Bert, Ian)
# [22:29] <fantasai> RESOLVED: Flexbox top/bottom margins and padding resolve against height.
# [22:31] * Rossen_away is now known as Rossen
# [22:31] <fantasai> plinss: All in favor of having a switch for behavior
# [22:31] <fantasai> [half a vote]
# [22:31] <fantasai> plinss: All those opposed to a switch
# [22:31] <dbaron> (I'm abstaining)
# [22:31] <fantasai> 4 - TabAtkins, greg, fantasai, tantek
# [22:32] <fantasai> RESOLVED: No switch for now
# [22:32] * ChrisL CSS WG goes to an abstainance-only model
# [22:33] * Quits: myakura (~myakura@public.cloak) (Ping timeout: 180 seconds)
# [22:33] <astearns> late vote against switch - unit would be better
# [22:34] <fantasai> astearns, vote was for/against any of 1,2, or 2
# [22:35] <fantasai> if no way to switch behaviors is 0
# [22:35] <fantasai> vote was 0 vs. 1+2+#
# [22:35] <fantasai> vote was 0 vs. 1+2+3
# [22:35] <astearns> ah, ok
# [22:42] * glazou positive 0 or negative 0 ?-)
# [22:43] * Quits: johanneswilm (~johannes@public.cloak) (Ping timeout: 180 seconds)
# [22:46] * Joins: jdaggett (~jdaggett@public.cloak)
# [22:47] * Quits: Ms2ger (~Ms2ger@public.cloak) (Ping timeout: 180 seconds)
# [22:55] * Joins: johanneswilm (~johannes@public.cloak)
# [22:57] * Joins: gregwhitworth (~gregwhitworth@public.cloak)
# [22:57] * Quits: jdaggett (~jdaggett@public.cloak) (jdaggett)
# [22:57] * Joins: jdaggett (~jdaggett@public.cloak)
# [22:57] * Joins: lajava (~javi@public.cloak)
# [22:58] <plinss> jdaggett are you calling in?
# [22:58] <jdaggett> plinss: yes, when is good?
# [22:58] <plinss> now
# [22:59] <jdaggett> hang on just a sec, want to get heycam too
# [22:59] <dbaron> heycam|away, ^
# [22:59] <dbaron> (might be early for heycam)
# [23:00] <tantek> jdaggett do you have a Firefox Hello URL?
# [23:00] * heycam|away is now known as heycam
# [23:00] <plinss> jdaggett, heycam - +1-212-617-1960 for New York, +44-20-7330-7700 for London, +81-3-3201-7040 for Tokyo. PIN 295109
# [23:00] * heycam is here
# [23:00] * heycam thanks
# [23:00] <jdaggett> ok, thanks
# [23:02] <dbaron> We're the only participant
# [23:02] <dbaron> waiting for others to join
# [23:02] <dbaron> heycam's on the call
# [23:03] * leaverou is now known as leaverou_away
# [23:03] <fantasai> Topic: ????
# [23:03] <plinss> s/????/font-display-loading property/
# [23:03] <jdaggett> original proposal: http://tabatkins.github.io/specs/css-font-rendering/
# [23:03] <jdaggett> telcon discussion: https://lists.w3.org/Archives/Public/www-style/2015Apr/0143.html
# [23:03] <jdaggett> font-loading-display proposal: https://lists.w3.org/Archives/Public/www-style/2015Apr/0216.html
# [23:04] <fantasai> jdaggett: Back in march Tab had a proposal for what was called a 'font-rendering' control
# [23:04] <fantasai> jdaggett: Was to control appearance of text while font resources were loading
# [23:04] <fantasai> jdaggett: Discussed in April
# [23:04] <fantasai> jdaggett: General consensus, we want the functionality, but notion of timeouts we should drop
# [23:04] <fantasai> jdaggett: I went back and thought what we should do with it
# [23:04] <fantasai> jdaggett: Which I think is maybe a better way of going about this
# [23:05] <fantasai> jdaggett: Can we project the actual proposal?
# [23:05] <Bert> -> https://lists.w3.org/Archives/Public/www-style/2015Apr/0216.html proposal
# [23:05] * Florian Greg's doing it
# [23:05] * Florian not yet
# [23:05] * Florian ready
# [23:06] <fantasai> jdaggett: I'm proposing a new property, font-loading-display
# [23:06] <fantasai> jdaggett: 4 keywords
# [23:06] <fantasai> font-loading-display: auto | fallback | blank-fallback | blank
# [23:06] <fantasai> jdaggett: Essentially these are saying what should be displayed while font resource is downloaded
# [23:06] <fantasai> jdaggett: auto just means browser decides
# [23:06] <fantasai> jdaggett: fallback means fallback font is immediately displayed
# [23:06] <fantasai> jdaggett: blank-fallback is what FF and ? do
# [23:06] <Bert> q+ to ask if it is a property or a descriptor for @font-face.
# [23:06] <fantasai> jdaggett: Show invisible text, then show fallback font if timed out
# [23:07] <fantasai> jdaggett: blank is what safari does, show nothing until font loads
# [23:07] <fantasai> jdaggett: blank is currently not exactly Safari's behavior... Safari takes forever
# [23:07] <fantasai> jdaggett: At some point, you really need to show the user text. Can't just show a blank page
# [23:07] <fantasai> TabAtkins: As an alternate proposal, we had a discussion in blink
# [23:07] <fantasai> TabAtkins: We're fine with dropping timeouts
# [23:07] <fantasai> TabAtkins: and using the keywords from original proposal
# [23:07] * fantasai asks for link to Tab's proposal
# [23:08] <fantasai> jdaggett: blank isn't Safari's wait-forever, it's wait a long time
# [23:08] <fantasai> Florian: I agree that his blank is less bad than Safari's
# [23:08] <Bert> -> http://tabatkins.github.io/specs/css-font-rendering/ Tab's proposal
# [23:08] <fantasai> Florian: But agree with Tab that it's still pretty bad
# [23:09] * leaverou_away is now known as leaverou
# [23:09] <fantasai> Florian: There was a behavior that you display with the fallback font, start the load, and keep with the fallback font until page is reloaded, then use real font
# [23:10] <fantasai> (behavior above is optional keyword from Google's proposal)
# [23:10] <fantasai> jdaggett: The notion that during layout decide whether to display or not based on whether a font is available or not
# [23:10] <fantasai> jdaggett: If font is in the cache, finite amount of time to figure out if you have the font available
# [23:10] <fantasai> jdaggett: could be as much as 20ms
# [23:11] <fantasai> jdaggett: You're putting a big load into this keyword
# [23:11] * fantasai is confused
# [23:11] <fantasai> TabAtkins: No, we're not.
# [23:11] <fantasai> TabAtkins: It's about a very small UA-defined timeout. If you've loaded within that time, great. If not, cache is cold, then keep with the fallback font.
# [23:11] <fantasai> jdaggett: My point is, there will always be a flash.
# [23:12] <fantasai> Florian: The problem isn't with flash
# [23:12] <fantasai> Florian: The problem is with partway into reading the page
# [23:12] <fantasai> Florian: And then stuff shifts under you
# [23:12] <fantasai> TabAtkins: Our timeout for optional is, are we at the point where we're putting the text on the page?
# [23:12] <fantasai> TabAtkins: If not there yet and loaded font, then go use font
# [23:12] <fantasai> TabAtkins: Otherwise render with falback font
# [23:13] <fantasai> dbaron: I think definition that you gave means some implementations will never use the optional font, and that's what we don't want
# [23:13] <fantasai> fantasai: I don't understand what that means
# [23:14] <fantasai> dbaron: Some implementations would have never loaded the font by the time they do the paint
# [23:14] <fantasai> TabAtkins: They never see that font. From first paint onward, no change in font
# [23:14] <fantasai> heycam: I think expectation is that first time, very good chance it won't show, but next time load a page from that site, will see the font.
# [23:14] <fantasai> jdaggett: In a lot of situations, where you really want this is mobile devices
# [23:14] <fantasai> jdaggett: where the connection is slowery
# [23:14] * Rossen is now known as Rossen_away
# [23:15] <fantasai> jdaggett: But those mobile devices are severely resource-constrained
# [23:15] <fantasai> jdaggett: Whether something shows up in cache is a crapshoot
# [23:15] <fantasai> TabAtkins: That's one of the main cases
# [23:15] <fantasai> TabAtkins: They are the ones that are most likely to not render the optional font
# [23:15] <fantasai> plinss: Better for mobile perf
# [23:15] <fantasai> jdaggett: font loading API gives authors the most control
# [23:16] <plinss> s/perf/perf</sarcasm>/
# [23:16] <fantasai> jdaggett: I think it makes more sense for authors to script this, rather than having non-interop
# [23:16] * hober that joke is so 2014, plinss :)
# [23:16] <fantasai> TabAtkins: I'm ok with delaying on the optional keyword until we have something we agree on
# [23:16] <fantasai> fantasai: I think 'optional' makes sense. I would probably want that behavior.
# [23:17] * plinss hober, the old jokes will continue until mobile perf improves
# [23:17] <fantasai> dbaron: I would be OK with some definitions of optional, like Florian's definition
# [23:17] <fantasai> dbaron: Florian's definition was about some small amount of time. Not predicated on drawing text.
# [23:17] <fantasai> Florian: Things might flash very briefly, but won't shift under you once you've started reading.
# [23:17] <fantasai> jdaggett: I think in practice, you'll find that for a certain set of devices that happen to be at some level of cache storage
# [23:18] <fantasai> jdaggett: going to end up seeing on one view,not see the font, then next view see the font, then load a bunch of stuff, not see hte font, later then see the font
# [23:18] <fantasai> jdaggett: Don't think usability would be great on this
# [23:18] <fantasai> TabAtkins: I disagree. This is better for optional uses.
# [23:18] <fantasai> TabAtkins: Better to be stable on a given page than swap sometime while you're reading.
# [23:19] <fantasai> jdaggett: I think the criteria for optional, there are more parameters that you'll want to use
# [23:19] <fantasai> jdaggett: Think it's better to leave optional behavior to script.
# [23:20] <fantasai> fantasai: I don't want to require script for this. This is a reasonable behavior that I'd want, and I don't want to script it.
# [23:20] <fantasai> fantasai: Wouldn't want someone reading my article to have the text shift around 30 seconds after starting to read
# [23:21] <fantasai> fantasai: just to have a nicer font
# [23:21] <Bert> (What does "optional" mean? Aren't all fonts optional? As long as there is at least one.)
# [23:21] <fantasai> jdaggett: My concern is that flipping back and forth between pages, the font loads, and then the current layout isn't the same as the previous layout
# [23:21] <fantasai> jdaggett: We should leave it to authors to script this, and then if there's a pattern that evovlves, then we can put it into a CSS keyword
# [23:22] * Rossen_away is now known as Rossen
# [23:22] <fantasai> jdaggett: I'm unconvinced that this is something we should specify with just a timeout on the font resource. Also want to consider what's the state of the page? Are we rendering? etc. Will be parameters not captured by the proposal.
# [23:22] <fantasai> TabAtkins: Our argument is that there's a common enough case that we can handle now. Script can handle more complicated cases.
# [23:23] <fantasai> tantek: Page changing the second time you load it -- when you go back to it. Or the case where you navigate back to it from another page
# [23:23] <fantasai> tantek: That's a red herring.
# [23:23] <fantasai> tantek: Web pages change all the time over time
# [23:23] <fantasai> tantek: Images, ads load over time, new buttons, whatever
# [23:23] <fantasai> tantek: I don't think it's that disturbing t
# [23:24] <fantasai> jdaggett: But if I read halfway through an article, flip to my mail app, flip back and it rerenders
# [23:24] <fantasai> jdaggett: that's bad
# [23:24] <fantasai> fantasai: That's exactly the point we're making! [except it changes while you're reading and not even you flipped anything]
# [23:24] <tantek> that's not bad, that's how the web works today
# [23:25] <jdaggett> the problem is the rerender now renders with a different font which no longer lays out the same way
# [23:25] <jdaggett> and the position where i was reading has now been lost!!
# [23:25] <fantasai> dbaron: The google proposal for optional was basically was aiming for a zero-second timeout, or something very close to it
# [23:25] <fantasai> dbaron: What Tantek and Elika are saying is that they'd be happy with the 3 second time out
# [23:25] <fantasai> tantek: Yeah, I'm ok with both
# [23:25] <fantasai> dbaron: But then you fall back
# [23:26] <fantasai> dbaron: In some ways, that's very similar to what's there with the blank-fallback
# [23:26] <fantasai> dbaron: It's already wait for 3 seconds, if it's not loaded fall back
# [23:26] <fantasai> TabAtkins: No. It's don't show anything for 3 seconds, then show the fallback font, then load the real font and render with it onces it's loaded
# [23:26] <tantek> 3 seconds is too long
# [23:27] <Florian> tantek: +1
# [23:27] <fantasai> discussion of case where links were invisible for 3 seconds while res tof page was visible, 'cuz using different font for links. Was very confusing.
# [23:27] <fantasai> dbaron: I think there are 3 quesitons
# [23:27] <fantasai> dbaron: 1. What is the timeout after which your behavior changes
# [23:27] <fantasai> dbaron: 2. What do you do before you hit that time?
# [23:28] <fantasai> dbaron: 3. What do you if the font loads after that timeout?
# [23:28] <fantasai> Florian: There might be two timeouts.
# [23:28] <jdaggett> can't hear!!!
# [23:28] * heycam ok :)
# [23:28] <fantasai> Florian: There's potentially 2 thresholds
# [23:28] <fantasai> Florian: 1 where initially you might be blank or show fallback
# [23:29] <tantek> what's the timeout threshold for showing alt-text while waiting to load an image?
# [23:29] <fantasai> Florian: Then the font comes in
# [23:29] <ChrisL> similar issue with "You must NEVER do this" where NEVER uses a downloaded font and has not loaded.
# [23:29] * heycam cannot hear Tab at all
# [23:29] <fantasai> TabAtkins: My spec is exactly that model
# [23:29] <jdaggett> can't hear you now!!
# [23:29] <jdaggett> someone sitting on the mike?!?
# [23:29] <tantek> jdaggett: we're working on it
# [23:29] <jdaggett> kk
# [23:29] <tantek> how about now?
# [23:29] <dbaron> the mics all ran out of attery
# [23:29] <dbaron> battery
# [23:29] <jdaggett> good!
# [23:30] <jdaggett> ah
# [23:30] <dbaron> so we had to switch to hand mics
# [23:30] <dbaron> and pass them around
# [23:30] <jdaggett> charger?
# [23:30] <fantasai> TabAtkins: There are 3 periods: blank period, swap-if-it-comes-in-otherwise-show-fallback period, screw-it-just-stick-with-fallback
# [23:30] <fantasai> TabAtkins: Called the blank, swap, and fallback periods
# [23:30] <fantasai> TabAtkins: Keywords just set the boundaries between those three periods to different values
# [23:31] <fantasai> Florian: I would like to stick with that model.
# [23:31] <fantasai> Florian: I would like to make the periods user-defined.
# [23:31] <fantasai> s/I/Having removed timeouts, I/
# [23:32] <jdaggett> s/user-defined/user-agent defined/
# [23:32] <fantasai> Florian: There are two times that you'd need user-agent defined -- one is "almost instantaneously", and the other is "after a little while (e.g. 3sec, but not exactly that necessarily)"
# [23:32] <fantasai> Florian: I don't know how it's defined right now, ...
# [23:33] <fantasai> TabAtkins: Right now it says "Xs or whatever UA heuristics you want"
# [23:33] <fantasai> jdaggett: I think the keywords from that proposal are really awful
# [23:33] <fantasai> jdaggett: Would prefer to go along the lines of what we've got in font-loading-display property
# [23:33] <smfr> q+
# [23:33] * heycam can't hear smfr
# [23:33] * Quits: andrey-bloomberg (~andrey-bloomberg@public.cloak) (Ping timeout: 180 seconds)
# [23:34] <fantasai> plinss: Another difference is that one has a property only, and the other is descripter and property
# [23:34] <dbaron> we had good table microphones, and it seems their batteries all last until 5:15pm and then give out
# [23:34] <fantasai> smfr: In webkit, we don't want different font loading behavior per element.
# [23:34] <fantasai> smfr: We're happy with a rule in the font descriptor, but not in elements.
# [23:35] <fantasai> smfr: Don't want to have situation where font is loaded but can only be used in some elements.
# [23:35] <TabAtkins> q+ ChrisL
# [23:35] <plinss> ack smfr
# [23:35] <fantasai> Rossen: I have a more general question related to the topic
# [23:35] <fantasai> Rossen: Strikes me a little bit surprising , dealing with resource handling in CSS
# [23:35] <fantasai> Rossen: I get it that fonts are intrinsically very important for everything else that we do
# [23:35] <dbaron> also, we have a hard stop in about 15 minutes for dinner, if my memory serves
# [23:35] <fantasai> Rossen: But we're not doing anything like this for images or other media loading
# [23:35] <fantasai> Rossen: whyare we doing this for fonts?
# [23:35] <fantasai> fantasai: Because for fonts you can have a fallback
# [23:36] <fantasai> TabAtkins: And text is more improtant than images
# [23:36] <fantasai> smfr: We've had requests for pseudo-class for loading state of images (not-yet-loaded)
# [23:36] * Joins: routed (~user@public.cloak)
# [23:36] <fantasai> ChrisL: I agree that this make smore sense as a descriptor than a property.
# [23:36] <fantasai> ChrisL: Not per-element basis
# [23:37] <fantasai> Florian: Generally yes, but in some cases, you may have the same font and headlines and body, and you're OK with the headlines flickering, but not the body flickering.
# [23:37] <fantasai> Florian: So both are useful. If we only have one, descriptor is better.
# [23:37] <ChrisL> ok, I can go with that
# [23:37] <fantasai> heycam: Could get same behavior by using descriptors
# [23:37] <fantasai> heycam: define different @font-face rules
# [23:37] <fantasai> smfr: Concerned about overhad for implementations, using a property
# [23:38] <fantasai> Florian: If only one, descriptors only
# [23:38] <fantasai> smfr: font descriptor can have more than one font, so need to define behavior there
# [23:38] <fantasai> TabAtkins: The timeout is for initialy using a font name
# [23:38] <fantasai> TabAtkins: So if the first one fails at 1s, other one came in within 1.5s later, then still made it within the 3s timeout
# [23:39] <tantek> :partial pseudo-element for proposed in 1998 for partially loaded elements including images. https://www.w3.org/Style/Group/1998/09/progrend-19980930
# [23:39] <fantasai> TabAtkins: If we consider that we already agree that we can leave discussion of explicit timeouts to later
# [23:39] <tantek> (apologies for the member-only link - that was before I knew better ;) )
# [23:39] <dbaron> (restaurant said they could only do a large group dinner if we came at 6pm)
# [23:39] <fantasai> TabAtkins: I'm fine with leaving optional out for now, while we discuss something that makes everybody happy
# [23:39] <fantasai> TabAtkins: Have two other behaviors that everyone agrees on:
# [23:40] * tantek dbaron how far is the restaurant?
# [23:40] <fantasai> TabAtkins: a) swap - start with fallback, if font loads in reasonable amount of time, show it otherwise stay with fallback
# [23:40] * heycam finds in Tab's accent that "blank" and "blink" sound pretty similar :)
# [23:41] <fantasai> TabAtkins: b) blank - start with blank until it loads, if hasn't loaded by the blank timeout, use fallback
# [23:41] * tantek heycam good point
# [23:41] * fantasai is confused about stability after 30s
# [23:41] <fantasai> leaverou: Why would you want blank?
# [23:41] <fantasai> TabAtkins: Things like brand identity, better to wait to display than to display in fallback font
# [23:41] <tantek> what about font-loading to render the alt text on an image that's taking too long to load?
# [23:41] <fantasai> plinss: Not really ideal for body text
# [23:42] * glazou that’s 30 seconds or thirty years?-)
# [23:42] <fantasai> fantasai: What happens if font loads after 30 seconds?
# [23:42] <fantasai> TabAtkins: under my proposal you have an infinite swappable period
# [23:42] <fantasai> TabAtkins: will always load the real font once it loads
# [23:43] <fantasai> heycam: Unless we make 30 seconds author-controllable, not sure about new hardcoded timeout
# [23:44] <fantasai> dbaron: Nobody suggesting 30s as a timeout for anything. Just as an example
# [23:44] * tantek glazou yeah seriously. ^.^
# [23:44] <fantasai> dbaron: of a time after every timeout discussed
# [23:44] <fantasai> dbaron: anyway
# [23:44] <fantasai> dbaron: These two behaviors you're discussing
# [23:44] * glazou tantek, we are all confused about stability after 30, right?-)
# [23:44] * tantek is still wondering about alt text
# [23:44] <fantasai> dbaron: They vary on two characteristics: what you do before, and also what you do after
# [23:45] * tantek glazou learning rock climbing helped with stability.
# [23:45] <fantasai> TabAtkins: If you have a font that you really-really want to use, want blank
# [23:45] <fantasai> TabAtkins: Not great for body text
# [23:45] <fantasai> TabAtkins: For cases where blocking behavior is intended
# [23:45] * glazou tantek I chose another path, divorce :-D
# [23:45] <fantasai> TabAtkins: Having it load after an arbitrary amount of time [...]
# [23:45] <jdaggett> um, *lots* of sites use fonts for body text
# [23:45] * tantek glazou didn't that choice, and don't envy you for having it and doing it.
# [23:46] <fantasai> TabAtkins: For swapping behavior want to prioritize user something or other .....
# [23:46] * tantek didn't *have
# [23:46] <fantasai> TabAtkins: Can we agree that these two behaviors are good
# [23:46] <fantasai> fantasai: No
# [23:46] * fantasai takes a break
# [23:46] * Florian john you're not minuted
# [23:46] * Joins: gregwhitworth_ (~gregwhitworth@public.cloak)
# [23:46] <gregwhitworth_> scribenick: gregwhitworth
# [23:47] <gregwhitworth_> dbaron: John doesn't have one that never swaps
# [23:48] * Joins: gregwhitworth__ (~gregwhitworth@public.cloak)
# [23:48] * Quits: shepazu (schepers@public.cloak) ("My Mac has gone to sleep. ZZZzzz…")
# [23:48] * Quits: gregwhitworth (~gregwhitworth@public.cloak) (Ping timeout: 180 seconds)
# [23:49] <gregwhitworth__> adjourned
# [23:49] * Quits: ChrisL (clilley@public.cloak) ("Client combusted")
# [23:49] * Quits: dbaron (~dbaron@public.cloak) ("8403864 bytes have been tenured, next gc will be global.")
# [23:50] * Quits: glazou (~glazou@public.cloak) (glazou)
# [23:51] * Quits: lajava (~javi@public.cloak) (Ping timeout: 180 seconds)
# [23:51] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
# [23:51] * Quits: smfr (~smfr@public.cloak) (smfr)
# [23:51] * Joins: Florian (~Florian@public.cloak)
# [23:53] * Quits: tantek (~tantek@public.cloak) (tantek)
# [23:54] * Quits: gregwhitworth_ (~gregwhitworth@public.cloak) (Ping timeout: 180 seconds)
# [23:55] * Rossen is now known as Rossen_away
# [23:56] * Quits: gregwhitworth__ (~gregwhitworth@public.cloak) (Ping timeout: 180 seconds)
# [23:57] * Quits: johanneswilm (~johannes@public.cloak) (Ping timeout: 180 seconds)
# [23:58] * Quits: Florian (~Florian@public.cloak) (Ping timeout: 180 seconds)
# [23:59] * leaverou is now known as leaverou_away
# Session Close: Wed May 20 00:00:00 2015

Think these logs are useful? Then please donate to show your gratitude (and keep them up, of course). Thanks! — Krijn