/irc-logs / w3c / #css / 2014-09-08 / end

Options:

# Session Start: Mon Sep 08 00:00:00 2014
# Session Ident: #css
# [00:15] * Quits: Ms2ger (~Ms2ger@public.cloak) ("nn")
# [00:58] * Joins: glenn (~gadams@public.cloak)
# [01:05] * Quits: glenn (~gadams@public.cloak) (Ping timeout: 180 seconds)
# [01:14] * Joins: lmclister (~lmclister@public.cloak)
# [01:58] * Joins: glenn (~gadams@public.cloak)
# [02:06] * Quits: glenn (~gadams@public.cloak) (Ping timeout: 180 seconds)
# [02:07] * Quits: lmclister (~lmclister@public.cloak) ("")
# [02:59] * Joins: tommyjtl (~tommyjtl@public.cloak)
# [02:59] * Joins: glenn (~gadams@public.cloak)
# [03:06] * Quits: tommyjtl (~tommyjtl@public.cloak) (Client closed connection)
# [03:06] * Joins: tommyjtl (~tommyjtl@public.cloak)
# [03:06] * Quits: glenn (~gadams@public.cloak) (Ping timeout: 180 seconds)
# [04:00] * Joins: glenn (~gadams@public.cloak)
# [04:07] * Quits: glenn (~gadams@public.cloak) (Ping timeout: 180 seconds)
# [05:01] * Joins: glenn (~gadams@public.cloak)
# [05:09] * Quits: glenn (~gadams@public.cloak) (Ping timeout: 180 seconds)
# [05:33] * Joins: jdaggett (~jdaggett@public.cloak)
# [06:01] * Joins: glenn (~gadams@public.cloak)
# [06:09] * Quits: glenn (~gadams@public.cloak) (Ping timeout: 180 seconds)
# [06:27] * Joins: glenn (~gadams@public.cloak)
# [06:34] * Quits: glenn (~gadams@public.cloak) (Ping timeout: 180 seconds)
# [06:34] * leaverou_away is now known as leaverou
# [06:44] * Joins: glenn (~gadams@public.cloak)
# [07:17] * Quits: glenn (~gadams@public.cloak) (Client closed connection)
# [07:33] * Joins: zcorpan (~zcorpan@public.cloak)
# [07:40] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [09:07] * Joins: Ms2ger (~Ms2ger@public.cloak)
# [09:12] * Joins: gregwhitworth (~gregwhitworth@public.cloak)
# [09:18] * Joins: florian (~florian@public.cloak)
# [09:20] * Joins: glenn (~glenn@public.cloak)
# [09:23] * Joins: glazou (~glazou@public.cloak)
# [09:23] * Joins: shans_ (~shans@public.cloak)
# [09:26] * Joins: andreyr (~andreyr@public.cloak)
# [09:26] * Joins: dauwhe (~dauwhe@public.cloak)
# [09:27] * Quits: tommyjtl (~tommyjtl@public.cloak) (Client closed connection)
# [09:27] * Joins: tommyjtl (~tommyjtl@public.cloak)
# [09:29] * Joins: plh (plehegar@public.cloak)
# [09:29] * Joins: tommyjtl_ (~tommyjtl@public.cloak)
# [09:29] * Quits: tommyjtl_ (~tommyjtl@public.cloak) (Client closed connection)
# [09:29] * Quits: tommyjtl (~tommyjtl@public.cloak) (Client closed connection)
# [09:30] * Joins: tommyjtl (~tommyjtl@public.cloak)
# [09:33] * Joins: Rossen_ (~Rossen@public.cloak)
# [09:33] * Joins: Zakim (zakim@public.cloak)
# [09:33] * Joins: Clilley (~Clilley@public.cloak)
# [09:34] * Joins: zcorpan (~zcorpan@public.cloak)
# [09:34] * Joins: ikilpatrick (~ikilpatrick@public.cloak)
# [09:37] * Joins: dbaron (~dbaron@public.cloak)
# [09:37] * dbaron RRSAgent, pointer?
# [09:37] <fantasai> [Agenda discussions]
# [09:37] <dbaron> trackbot, start meeting
# [09:37] * trackbot is preparing a teleconference.
# [09:37] * Joins: RRSAgent (rrsagent@public.cloak)
# [09:37] <RRSAgent> logging to http://www.w3.org/2014/09/08-css-irc
# [09:37] <trackbot> RRSAgent, make logs member
# [09:37] <RRSAgent> I have made the request, trackbot
# [09:37] <trackbot> Zakim, this will be Style_CSS FP
# [09:37] <Zakim> I do not see a conference matching that name scheduled within the next hour, trackbot
# [09:37] <trackbot> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
# [09:37] <trackbot> Date: 08 September 2014
# [09:37] <dbaron> RRSAgent, make logs public
# [09:37] <RRSAgent> I have made the request, dbaron
# [09:37] <dbaron> Zakim, remind us in 9 hours to go home
# [09:37] <Zakim> ok, dbaron
# [09:40] <fantasai> ScribeNick: fantasai
# [09:40] <fantasai> Discussion of Counter Styles LC and CR transition process
# [09:41] <fantasai> Trying to pre-emptively schedule the telecon to shorten CR publication process
# [09:43] * Joins: tommyjtl_ (~tommyjtl@public.cloak)
# [09:44] * Joins: koji (~koji@public.cloak)
# [09:48] * Quits: koji (~koji@public.cloak) ("")
# [09:48] * Joins: koji (~koji@public.cloak)
# [09:49] * fantasai koji, we are just going over the agenda
# [09:49] * Quits: tommyjtl (~tommyjtl@public.cloak) (Ping timeout: 180 seconds)
# [09:51] * fantasai suggest to start with text issue 72, just so Rossen has time to track down ppl before the end of the meeting?
# [09:52] * fantasai do you want to do any others? think we should skip justification today
# [09:52] * fantasai let us know when is a good time to call in, for you
# [09:52] <koji> today?
# [09:53] * fantasai today, or later, whichever works for you
# [09:53] <glazou> koji can you hear us ?
# [09:53] <glazou> through skype
# [09:53] <glazou> apparently not
# [09:53] <koji> I can hear you, sounds like you can't
# [09:54] <astearns_> try calling us
# [09:54] <fantasai> Topic: CSS3 Text
# [09:54] <fantasai> http://dev.w3.org/csswg/css-text-3/issues-lc-2013
# [09:54] <fantasai> http://dev.w3.org/csswg/css-text-3/issues-lc-2013#issue-72
# [09:55] * Quits: andreyr (~andreyr@public.cloak) ("Page closed")
# [09:55] <fantasai> fantasai: We're waitin for MSFT to get back to us on whether we want to make the change.
# [09:55] * Joins: andreyr (~andreyr@public.cloak)
# [09:55] <fantasai> Rossen: We're still waiting to hear on one of the dependency teams we have at Uniscribe/DWrite
# [09:55] <fantasai> Rossen: From our POV, shouldn't be a problem.
# [09:55] <fantasai> Rossen: Compat cost shouldn't be a problem, to basically implement the feature
# [09:56] <fantasai> Rossen: So as of now, tentative OK, unless we hear otherwise from the teams that are lower on the stack.
# [09:56] <fantasai> fantasai: So we'll take that, make the edits, and you can come back with Stop the Presses if needed
# [09:56] <fantasai> Rossen: yep
# [09:57] <fantasai> fantasai: So, resolved to make control chars visible?
# [09:57] <Clilley> presumably not CR and LF?
# [09:57] <fantasai> RESOLVED: Make control characters visible
# [09:57] <Clilley> ok, 80 to 96 ones
# [09:57] <fantasai> (Unicode class Cc)
# [09:58] <fantasai> s/class/category/
# [09:58] <Clilley> ty
# [09:58] * dbaron notes we don't have any control characters in the working group, though we do have some whitespace characters :-P
# [09:58] * Joins: glazou2 (~glazou2@public.cloak)
# [09:58] <fantasai> koji and fantasai will make edits
# [09:58] <fantasai> http://dev.w3.org/csswg/css-text-3/issues-lc-2013#issue-70
# [09:58] <fantasai> http://dev.w3.org/csswg/css-text-3/issues-lc-2013#issue-79
# [09:58] <fantasai> http://lists.w3.org/Archives/Public/www-style/2014Aug/0217.html
# [09:59] <fantasai> fantasai: Issue 70 and 79 have same proposal
# [09:59] <fantasai> http://lists.w3.org/Archives/Public/www-style/2014Aug/0295.html
# [09:59] <fantasai> fantasai: We got a request to clarify when inline joining happens across an inline boundary and when it doesn't
# [10:01] <fantasai> fantasai: There's basically 3 cases:
# [10:01] <fantasai> fantasai: MUST NOT break shaping (no style change, no excuse to break)
# [10:01] <fantasai> fantasai: MUST break shaping
# [10:02] <fantasai> fantasai: RECOMMEND to not break, but depends on font tech
# [10:02] * Joins: yamamoto (~yamamoto@public.cloak)
# [10:03] <fantasai> dbaron: Seems like 2 is 2 different cases, e.g. no reasonable way to render an fi ligature with one from one font and one from other is clearly nonsensical
# [10:03] <fantasai> dbaron: but Arabic shaping is doable
# [10:04] <glazou2> Present: glenn, astearns, dhauwe, hober, Bert, dbaron, florian, zcorpan, yamamoto, Chris, ?, shane, TabAtkins, gregwhitworth, rossen, krit, plh, andreyr, SimonSapin, fantasai, plinss, glazou, koji (skype)
# [10:04] <fantasai> fantasai: There's cases in the middle that are less clear, e.g. Indic shaping, which can be done by ligatures, contextual forms, etc.
# [10:04] <fantasai> fantasai: So while we can say clearly for fi ligature, and for Arabic forms you can force shapes by using ZWJ/ZWNJ at the edge of runs so that's always technically possible, a lot of things in between we can't say, depends on exact case
# [10:04] <glazou2> s/?,/Ian Kilpatrick (Google),
# [10:05] <fantasai> fantasai asks whether ppl ok with split into 1-3
# [10:06] <fantasai> dbaron: yes, but unsure if SHOULD should be that strong
# [10:06] <fantasai> TabAtkins: want to have more than a may
# [10:07] <dbaron> dbaron: seems odd to say, e.g., that implementations SHOULD NOT break shaping across changes in font-size
# [10:07] <fantasai> TabAtkins: "Totally should, probably can't"
# [10:08] <fantasai> TabAtkins: totally should avoid breaking Arabic, but probably can't avoid breaking ligatures
# [10:08] * TabAtkins_ is now known as TabAtkins
# [10:08] <fantasai> fantasai: Cases which are 3
# [10:08] <fantasai> fantasai: Proposed to have 3 cases:
# [10:08] <fantasai> A. one of margin/border/padding are non-zero
# [10:08] <fantasai> B. vertical-align is not 'baseline'
# [10:08] <fantasai> C. it is a bidi isolation boundary
# [10:10] <fantasai> Seem to have agreement on A
# [10:11] <fantasai> fantasai: second case is if vertical-align doens't match
# [10:12] <fantasai> fantasai: thought about matching values, but actually, want to say if not baseline (not matching parent)
# [10:12] <fantasai> fantasai: e.g. top and middle won't align baselines anyway
# [10:13] <fantasai> TabAtkins: And def don't want adjacent superscripts to join
# [10:14] <fantasai> [fantasai said something about siblings and parent relationships and vert-align not inheriting]
# [10:14] <fantasai> astearns: maybe there are cases where we want two top things to join if htey happen to line up?
# [10:14] <fantasai> fantasai: Think we wnat it predictable
# [10:14] <fantasai> TabAtkins: We know there are cases where we don't want it to join
# [10:14] <fantasai> TabAtkins: Also, you can always put them in common parent and vert-align that
# [10:15] <fantasai> florian: i18n concerns?
# [10:16] <fantasai> fantasai: cases where you have different alignment i18nwise, done with change in which baseline you align to
# [10:16] <fantasai> Seem to have agreement on B
# [10:16] <fantasai> fantasai: Third case was bidi isolation boundary
# [10:17] <fantasai> fantasai: I can't think of a case where you would want joining across a bidi isolation boundary
# [10:17] * dbaron RRSAgent,pointer?
# [10:17] <fantasai> fantasai: but this is overloading a bidi control
# [10:17] * dbaron RRSAgent, pointer?
# [10:17] * RRSAgent See http://www.w3.org/2014/09/08-css-irc#T08-20-51
# [10:18] <fantasai> florian, Tab: doesn't make sense to join across that boundary...
# [10:19] <fantasai> florian, Tab: not worry about CJK
# [10:19] <fantasai> fantasai: Theoretically, CJK can be writen cursively
# [10:19] <fantasai> fantasai: Do you want to break between Japanese and Chinese words in a paragraph? Maybe maybe not.
# [10:20] <fantasai> glenn: language changes might cause switching of font tables
# [10:20] <fantasai> florian: that would fall under Should join if you can pull it off
# [10:20] * Quits: jdaggett (~jdaggett@public.cloak) (Ping timeout: 180 seconds)
# [10:21] <fantasai> TabAtkins: But def should break on bidi isolation
# [10:21] <fantasai> fantasai: Any other comments on bidi isolation and joining
# [10:21] * Clilley considers proposing the zero-width join-me-maybe
# [10:21] <TabAtkins> Clilley: That's crazy
# [10:22] * hober hey i just met you / and this is crazy / but here's my baseline / so join-me-maybe
# [10:22] <fantasai> fantasai: Unicode defines bidi isolation codes, doesn't define them to have any effect on shaping. Probably want to ask them about it, too.
# [10:22] * Clilley nice
# [10:24] <fantasai> fantasai: So, should we put this in the spec and then ask Unicode to comment?
# [10:24] <fantasai> glenn: impls don't connect over level runs
# [10:25] <fantasai> dbaron: might just be direction changes, rather than control chars
# [10:25] <fantasai> florian: If you have control chars that keep in the same level?
# [10:25] <fantasai> fantasai: case of 2 embeddings next to each other
# [10:25] <fantasai> fantasai: do those join
# [10:26] <fantasai> glenn: they would be the same level... so yes, would join
# [10:26] <fantasai> florian: ...
# [10:27] <dbaron> (probably embedding level changes rather than direction changes, maybe)
# [10:27] <fantasai> fantasai: because embeddings are not fully encapsulated, can't have rule about boundaries because text can shuffle around/through that boundary
# [10:28] <fantasai> fantasai: but for bidi isolation you can, because it fully encapsulates its contents
# [10:28] <fantasai> dbaron: Gecko does ligaturize across an embedding boundary
# [10:29] <fantasai> fantasai: for bidi isolation, you don't shuffle text around/through the boundary, and you can detect the boundary by just looking for it
# [10:29] <fantasai> fantasai: But I'm okay either way on this point.
# [10:30] <dbaron> http://lists.w3.org/Archives/Public/www-archive/2014Sep/att-0001/lig.html
# [10:30] <dbaron> was my testcase
# [10:30] <fantasai> fantasai: As long as we have A and B, most problematic cases should be taken care of
# [10:32] <fantasai> dbaron: I'm fine with saying break across an isolation boundary
# [10:33] <fantasai> http://www.unicode.org/reports/tr9/#Shaping
# [10:33] <fantasai> "Thus, the characters before and after a directional isolate will not join across the isolate, even if the isolate is empty or overflows the depth limit."
# [10:33] <Clilley> if anyone thinks you should not break over an isolation boundary they are welcome to write the opentype feature that implements it
# [10:33] <glazou2> it's hard to record a consensus from two opinions...
# [10:34] <fantasai> fantasai: Looks like Unicode already says you don't break across isolation, so I think we're good on that.
# [10:34] <fantasai> s/break/join/
# [10:35] * Quits: Ms2ger (~Ms2ger@public.cloak) (Ping timeout: 180 seconds)
# [10:35] <fantasai> RESOLVED: Accept proposal
# [10:35] <dbaron> http://lists.w3.org/Archives/Public/www-archive/2014Sep/att-0001/lig.html is about level changes, not isolation boundaries
# [10:35] <fantasai> For C, refer to UAX9
# [10:36] <dbaron> ... and only the first example actually has a level change
# [10:36] <dbaron> ... the first should not have a ligature, the second and third should be a ligature
# [10:37] <fantasai> dbaron: There's interesting markup in there, but there isn't text inside it
# [10:37] <fantasai> dbaron: so the text should just ligaturize
# [10:37] * zcorpan dbaron - http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3158 blink only does the ligature for <p>fi
# [10:38] * dbaron RRSAgent, pointer?
# [10:38] * RRSAgent See http://www.w3.org/2014/09/08-css-irc#T08-41-14
# [10:38] <fantasai> http://dev.w3.org/csswg/css-text-3/issues-lc-2013#issue-59
# [10:39] <fantasai> http://lists.w3.org/Archives/Public/www-style/2014Aug/0321.html
# [10:40] <fantasai> Issue was, do we add inter-character as equivalent to distribute, because ppl are confused what distribute means.
# [10:40] * trackbot doesn't understand that ISSUE command.
# [10:40] <fantasai> Rossen asked to defer to F2F
# [10:41] * glazou2 ahem :-)
# [10:42] <fantasai> koji: distribute also has a side-effect of changing text-align-last
# [10:42] <fantasai> koji: that behavior is probably confusing
# [10:43] <fantasai> koji: inter-character and distribute are different use cases and don't want to change
# [10:43] <fantasai> fantasai: I think you're thinking of inter-ideograph
# [10:44] <fantasai> koji: no, distribute causes text-align-last to justify, inter-character would be confusing
# [10:44] <fantasai> florian: So you're saying that distribute implies an extra bit of magic
# [10:44] <koji> yes
# [10:45] <fantasai> Bert: why does it do that?
# [10:45] <fantasai> fantasai: The use cases that wanted distribute wanted the last line to justify, so to avoid having to specify 'text-align: justify; text-justify: distribute; text-align-last: justify', we made the 'auto' value of text-align-last account for distribute
# [10:46] <fantasai> fantasai: Maybe it would have better to have text-align: distribute; and have that just do the right thing... but have to think about that more.
# [10:47] <fantasai> fantasai: we actually have a similar issue with kashida
# [10:47] <fantasai> fantasai: But we can go over that another time.
# [10:47] <fantasai> RESOVLED: no change
# [10:47] <fantasai> fantasai: That's it for Text for today.
# [10:47] * Joins: Ms2ger (~Ms2ger@public.cloak)
# [10:48] <fantasai> [round of intros]
# [10:49] <fantasai> glazou, plinss, fantasai, simonsapin,andrey,plh, krit, rossen, Greg, Tab, Shane, Ian, ChrisL, Yamamoto, dbaron, hober, zcorpan, astearns, glenn, bert, dave cramer
# [10:52] * Quits: koji (~koji@public.cloak) (Client closed connection)
# [11:00] * leaverou is now known as leaverou_away
# [11:01] * Quits: florian (~florian@public.cloak) (Ping timeout: 180 seconds)
# [11:06] * Quits: ikilpatrick (~ikilpatrick@public.cloak) (Ping timeout: 180 seconds)
# [11:08] * Joins: koji (~koji@public.cloak)
# [11:10] * Joins: ikilpatrick (~ikilpatrick@public.cloak)
# [11:11] <Bert> ScribeNick: Bert
# [11:12] <Bert> Topic: Display module
# [11:12] <Bert> fantasai: This discussion doesn't affect the next publication, but the one after.
# [11:13] <Bert> ... Want to limit the number of shorthands.
# [11:13] <fantasai> s/shorthands/value combinations/
# [11:13] <Bert> TabAtkins: Keep the longhands.
# [11:14] <Bert> ... Some combinations not very popular with implementers, like tablecell and flexbox
# [11:14] <fantasai> http://dev.w3.org/csswg/css-display-3/
# [11:14] <fantasai> s/longhands/longhand-combining syntax of the shrothand/
# [11:14] <fantasai> s/shrot/short/
# [11:15] <Bert> fantasai: Publish today without this change. So that it is recorded.
# [11:15] <Bert> ... We can refer to it when we want to re-add.
# [11:15] <Bert> ... But now simplyfy for level 3
# [11:16] * Joins: florian (~florian@public.cloak)
# [11:16] <Bert> florian: I liked them separate... but well.
# [11:17] <Bert> fantasai: we found the "noneness" of display was difficult to combine.
# [11:17] <Bert> florian: Leave to split and mark at risk?
# [11:17] <Bert> fantasai: No, don't want to do that.
# [11:17] <Bert> TabAtkins: No, because nobody want to implement combination like table-cell/flexbox
# [11:18] <Bert> ... We publish it to keep the history and may want to visit again later.
# [11:18] <Bert> Rossen_: Or call out the combinations that are not supproted explicitly?
# [11:18] <Bert> TabAtkins: Difficult.
# [11:18] <Bert> Rossen_: We effectively have the split inside/outside internally anyway,
# [11:18] <fantasai> ^fantasai: We had originally split them out at this level because we needed noneness to be a separate control. And if we were going to split 'display', we had to split it into whatever our final set of longhands would be. But now that we've realized noneness needs to be an independent control, that is not a longhand of display, that constraint no longer exists, and we can split 'display' later just fine.
# [11:18] <Bert> TabAtkins: We don't
# [11:19] <Bert> Rossen_: I'm partially excited about the possibilities. Better than cram everything in one property.
# [11:19] <Bert> ... Your proposal might be better, but haven't seen it,
# [11:20] <Bert> fantasai: Danger is that what we define now and people use it, that will be it. Cannot change anymore.
# [11:20] <Bert> ... If we add that as syntactic possibility now, it will be forever the same behavior.
# [11:20] <Bert> ... So restrict the syntax so that that is not possible right now.
# [11:21] <Bert> ... Remove things we don't want to support right now by restricting syntax
# [11:21] <Bert> ... At som epoint in the future we want to have all combinations.
# [11:21] <Bert> Rossen_: OK, in favor of publishing as-is and then change as proposed.
# [11:22] <Bert> TabAtkins: Table internal ones will not allow a second value. Maybe remove inside:auto
# [11:22] <Bert> fantasai: [Shows section 2.4 from ED]
# [11:23] <Bert> plinss: Confused, can you still [?]
# [11:23] <Bert> ... flex inside table row?
# [11:23] <Bert> TabAtkins: Table row generates a wrapper automatically. No change from current.
# [11:23] <Bert> fantasai: We want other combinations in the future, but syntactically restricting them for now.
# [11:24] <Bert> TabAtkins: We provavlye want to define some single-value tings and say also which can be arbitrarily combined,
# [11:24] <fantasai> http://dev.w3.org/csswg/css-display-3/#box-suppress
# [11:24] <Bert> TabAtkins: Also we want feedback on box-suppress naming issues.
# [11:24] <Bert> fantasai: Other ideas welcome.
# [11:25] <Bert> florian: Property name and values both?
# [11:25] <Bert> TabAtkins: We want just one value that keeps things visible, so easy to toggle.
# [11:25] <Bert> Rossen_: I'd expect something like 'box-display'
# [11:26] <Bert> SimonSapin: Special case for display:none?
# [11:26] <Bert> TabAtkins: Yes, that is explained in the spec.
# [11:26] <Bert> dbaron: Is the 'hide' well defined?
# [11:26] <Bert> ... It looks like it requires every other feature in CSS not to define if it is hide or not.
# [11:27] <Bert> ... What is intuitive for some is not so for everybody.
# [11:27] <Bert> TabAtkins: Fair point.
# [11:27] <Bert> dbaron: Animations don;t count as layout?
# [11:27] * dauwhe display-inside-tabs-head: auto;
# [11:27] <Bert> TabAtkins: Right, animations themselves don't do layout.
# [11:28] <Bert> fantasai: It is only that the timer doesn't stop.
# [11:28] <Bert> dbaron: That is not clear. In FF animations stopped. Recently changed it.
# [11:28] <Bert> ... Has to do with display:none that is short.
# [11:29] <Bert> ... Hmm, no, boxes go away when display is none.
# [11:29] <Bert> TabAtkins: We may to define it better.
# [11:29] <Bert> Rossen_: Collapsing?
# [11:29] <Bert> TabAtkins: That counts as layout.
# [11:29] <Bert> dbaron: Anumous box construction is important to define.
# [11:30] <Bert> ... Hide could be implemented with a new kind of box.
# [11:30] <Bert> ... Anonymous boxes are an interesting case.
# [11:30] <Bert> TabAtkins: ... An anonymous empty flex...
# [11:31] <Bert> TabAtkins: Does hide on a table cell create a table row around it?
# [11:31] <Bert> fantasai: Relates to collapsing bahvior we talked about earlier, visibility: collapse.
# [11:31] <Bert> ... We expect something to happen for flexbox...
# [11:31] <Bert> ... So how does this behave for collapsing? Or *is* this the collapsing control?
# [11:32] <Bert> ... Outside tables and flex, 'collapse' means 'hide'
# [11:32] <Bert> ... In tables without spanning cells, it does something sensible.
# [11:32] <Bert> ... With spanning cells, it just clips.
# [11:32] <Bert> ... Did we define it for flexbox?
# [11:33] <Bert> Rossen_: And grids?
# [11:33] <fantasai> I guess box-collapse might be a naming idea
# [11:33] <Bert> Clilley: Box-suppress can be used for things that do not use box model (such as SVG)?
# [11:34] <Bert> TabAtkins: SVG has a box model, it just has not been defined yet...
# [11:34] * Quits: koji (~koji@public.cloak) (Client closed connection)
# [11:34] <Bert> Clilley: Is this clear in the spec?
# [11:34] <Bert> TabAtkins: No, not clear [that this proeprty applies to SVG]
# [11:34] <Bert> fantasai: We can take an action to say it applies to SVG.
# [11:35] <fantasai> or display-collapse
# [11:35] <Bert> SimonSapin: 'box-suppress' makes sense for SVG. The values can have a reasonable interpretation.
# [11:35] <Bert> Clilley: Yes, just wanted to know if it was meant to apply.
# [11:35] <Bert> fantasai: Does anybody implement 'visibility: collapse' for flex?
# [11:35] <Bert> [several: don't think so]
# [11:36] <Bert> fantasai: In that case, we can just restrcit it to tables and define something new for flex here.
# [11:36] <Bert> dbaron: It looks like FF does stuff...
# [11:36] <Bert> ... Not widely used.
# [11:37] <Bert> plinss: Or counter proposal: put this under 'visibility'
# [11:37] <Bert> TabAtkins: We still want to support 'display: none'
# [11:37] <Bert> ted: [missed]
# [11:38] <Bert> plinss: Add values to 'visibility' is possible. Like 'suppress'
# [11:38] <Bert> fantasai: Need to think about usability. And about effect on speech.
# [11:38] <Bert> florian: Visibility is not a great word to use with speech...
# [11:38] <Bert> dbaron: Does 'hide' stop speech?
# [11:38] <Bert> fantasai: Currently no.
# [11:39] <dbaron> s/hide/box-suppress: hide/
# [11:39] <Bert> TabAtkins: Well, speech is a kind of layout...
# [11:39] <Bert> fantasai: Need to discuss...
# [11:39] <Bert> ... Let us know about issues like this!
# [11:41] <Bert> ... Display-outside issue with counters:
# [11:41] <Bert> TabAtkins: If you suppress the box, you also suppress the counter.
# [11:42] <Bert> fantasai: We need to work on that.
# [11:42] <Bert> dbaron: I think animations continue, but counters stop.
# [11:42] <Bert> ... It's a long time since I worked on counters...
# [11:43] <Bert> ... Counters need to be updated dynamically.
# [11:43] <Bert> [discussion about diffrent implementations of counters...]
# [11:44] * Quits: Rossen_ (~Rossen@public.cloak) (Ping timeout: 180 seconds)
# [11:44] <Bert> dauwhe: I'm probably the one here who uses coutners most, but I don't really have an opinion yet...
# [11:44] <fantasai> Scribe: fantasai
# [11:44] <fantasai> Topic: Backgrounds
# [11:44] * Joins: koji (~koji@public.cloak)
# [11:44] * Quits: koji (~koji@public.cloak) ("Leaving")
# [11:44] <fantasai> Bert: We decided we needed an erratum for interaction of body, canvas, background, and display: none
# [11:44] <fantasai> Bert: Decided if there's no box, then the background is transparent
# [11:45] <fantasai> Bert: Came up with some text for that
# [11:45] <fantasai> http://lists.w3.org/Archives/Public/www-style/2014Jul/0312.html
# [11:45] <fantasai> fantasai: works for me
# [11:46] <glazou2> +1
# [11:46] * Joins: Rossen_ (~Rossen@public.cloak)
# [11:48] <fantasai> dbaron: This is another interesting case for display: contents.
# [11:48] <fantasai> fantasai: Yes, that's why we changed the text.
# [11:49] <fantasai> plinss: what about display: contents on the root?
# [11:49] <fantasai> fantasai: computes to block
# [11:49] * hober emblockification will continue until morale improves
# [11:50] <fantasai> RESOLVED: accept erratum
# [11:50] * glazou2 hober, that's emblockificationning right ?
# [11:51] <fantasai> Topic: Line Gird
# [11:51] <fantasai> s/Gird/Grid/
# [11:51] <astearns_> http://dev.w3.org/csswg/css-line-grid/#change-log
# [11:51] <Bert> scribenick: Bert
# [11:51] <fantasai> astearns_: Mainly I took things out
# [11:51] * zcorpan wonders what happens with display:contents on svg elements
# [11:51] <Bert> astearns_: I think we should publishe with these chages I just linked.
# [11:52] <Bert> several: no objection to publishing
# [11:52] <Bert> fantasai: Value names for navigation?
# [11:52] <Bert> astearns_: Happy to discuss the names, but maybe not hold up publication.
# [11:53] <Bert> fantasai: Yes, we renamed to start/end elswehere. Should do similar here.
# [11:53] <Bert> RESOLVED: publich WD of line-gird
# [11:53] <Bert> s/gird/grid/
# [11:53] <fantasai> old draft : http://www.w3.org/TR/css-line-grid-1/#box-snap
# [11:54] <fantasai> er http://www.w3.org/TR/2014/WD-css-line-grid-1-20140403/#box-snap
# [11:54] <fantasai> none of the values are in common except none
# [11:55] * plh wallstreet movies?!?
# [11:55] <Bert> andreyr: We have been using webkit for the terminal.
# [11:55] <Bert> ... We'd like to control the clor of the cursor.
# [11:55] <Bert> s/clor/color/
# [11:55] <Bert> fantasai: There is interest in coloring the caret.
# [11:56] <Bert> ... Should be something like 'cursor-color'
# [11:56] <Bert> glazou2: And what if you set color on a cursor defined as an image.
# [11:56] * dauwhe http://en.wikipedia.org/wiki/Bloomberg_Terminal
# [11:56] <Clilley> carrot: {color: orange}
# [11:56] <Bert> dbaron: Caret and cursor not the same
# [11:57] <Bert> andreyr: Yes, I mean the caret.
# [11:57] <Bert> ... Orange is great.
# [11:57] <Bert> TabAtkins: 'caret-color' is fine.
# [11:57] <Bert> andreyr: We have a patch for chromium.
# [11:57] <fantasai> hober: existing css3-ui thread
# [11:58] <fantasai> hober: Tantek has the notes for this in the planning page, but hasn't been any edits to any documents
# [11:58] <Bert> ted: Lea raised something. Tantek has some notes for it in UI planning page.
# [11:58] <fantasai> hober: so where would this live
# [11:58] * Joins: koji (~koji@public.cloak)
# [11:58] <Bert> ... Where would this go?
# [11:58] <Bert> fantasai: css3-ui (which is bit of a mess right now...)
# [11:58] * Quits: koji (~koji@public.cloak) (Client closed connection)
# [11:59] <Clilley> how is caret different to cursor: text?
# [11:59] <Bert> ted: If you hav text in several colors, caret should reflect that as it moves along the text.
# [11:59] * Joins: koji (~koji@public.cloak)
# [11:59] <Bert> ... 'invert' is suboptimal for that. Take the case with compositing.
# [11:59] <Bert> ... Not enthusiastic about implementing 'invert'
# [11:59] * Quits: koji (~koji@public.cloak) (Client closed connection)
# [11:59] <Bert> TabAtkins: invert still fails on gray anyway.
# [12:00] * Joins: koji (~koji@public.cloak)
# [12:00] <Bert> ted: Yes, something with invert only after a threshold...
# [12:00] * Quits: koji (~koji@public.cloak) ("")
# [12:00] <Bert> ... And the case of two authors, author of content and author of content-editable thing. One doesn't know the color of the other.
# [12:01] <Bert> glazou2: We proposed ::selection for that.
# [12:01] * Joins: koji (~koji@public.cloak)
# [12:02] <Bert> Clilley: How is the caret different from the text cursor?
# [12:02] <Bert> TabAtkins: The cursor is the I-beam.
# [12:03] <Bert> ... the caret is the editable point in the text.
# [12:03] <Bert> fantasai: It's the one that blinks :-)
# [12:03] <Bert> RESOLVED: add 'caret-color' to css3-ui
# [12:03] <Bert> andreyr: I'd also like to set foreground/background of selected text.
# [12:04] <dbaron> http://lists.w3.org/Archives/Public/www-style/2008Oct/0268.html
# [12:04] <Bert> fantasai: We all want it, we had it at some point.
# [12:04] <Bert> dbaron: I did half of the required analysis. Most engines have some sort of selection feature.
# [12:05] <Bert> ... I listed five requirements and three solutions. But didn't do enough testing.
# [12:05] <Bert> ... I think not all implementations meet the five reqs.
# [12:05] <Bert> ... A usefule next step would be to test what impls. do.
# [12:06] <Bert> fantasai: And andreyr wanted to propose equivalent selections for highlighted spelling errors.
# [12:06] <Bert> dbaron: Different DOM selections can maybe be associated with particular styles.
# [12:06] <Bert> TabAtkins: A style without th need to put in a SPAN.
# [12:06] <Bert> ted: A DOM range.
# [12:07] <Bert> glazou2: Related to what we discussed earlier about selecting non-ele,ments?
# [12:07] <fantasai> ScribeNick: fantasai
# [12:07] <Bert> fantasai: No, different,
# [12:07] <fantasai> dbaron: This is an extension of ::selection, where you could associate a DOM range with a name, and select (in the same way as ::selection) based on that DOM rane
# [12:07] <fantasai> dbaron: Want to create it using ranges, then create styles for this
# [12:07] <fantasai> dbaron: The styling would work the same as ::selection, so limited set of things
# [12:07] <fantasai> hober: I love this idea
# [12:07] <fantasai> glazou: me too
# [12:08] <fantasai> TabAtkins: If we ever explicitly expose browser spellcheck, could need to be restricted even further
# [12:08] <fantasai> TabAtkins: because of concerns wrt exposing user dictionaries
# [12:08] <fantasai> dbaron: would expose user's language and also user's dictionary
# [12:09] <fantasai> Andrey: Problem is that color of underline is hard-coded, want to chagne that
# [12:09] <fantasai> dbaron: Once we solve for ::selection, will be most of the way through solving for multiple selection. Though a few more issues.
# [12:09] <fantasai> hober: I imagine that I wrote an email for a similar thing, might not hvae actually written it...
# [12:09] <fantasai> hober: Was a proposal for creating identified DOM ranges, syntax to select it
# [12:10] * glazou2 loves it
# [12:10] <fantasai> fantasai: Andrey's immediate problem is changing the color of squiggly underlines, can we do anything about that?
# [12:10] <dbaron> https://bugzilla.mozilla.org/show_bug.cgi?id=256773
# [12:10] <fantasai> ::spelling-error { text-decoration-color: orange; }
# [12:11] <fantasai> fantasai: would that be something that we can do?
# [12:11] <fantasai> hober: You shoudln't be able to discover this style by checking
# [12:11] <fantasai> zcorpan: Ther'es spelling errors, and also spelling suggestions
# [12:12] <fantasai> ...
# [12:12] <fantasai> plinss: extension mechanism should also be able to handl spelling and grammar check etc.
# [12:13] <fantasai> TabAtkins: Things that are security-sensitive need to be built in
# [12:13] <fantasai> TabAtkins: If they're using info not available to the page, you cna't build into the page.
# [12:13] <fantasai> TabAtkins: That's why spellcheck, if we want customization of it, it has to be built-in
# [12:13] <fantasai> hober: Or you build your own
# [12:13] <fantasai> dbaron: Gecko currently has 9 different types of internal selections
# [12:13] <dbaron> (FWIW, Gecko has 9 different types of custom selection, listed at http://hg.mozilla.org/mozilla-central/file/2255d7d187b2/content/base/public/nsISelectionController.idl#l23
# [12:14] <fantasai> TabAtkins: wasn't there talk of exposing find to the page?
# [12:15] <fantasai> TabAtkins: Ignoring urlsecondary (we don't know what it is), doesn't seem like any others need to be security-sensitive
# [12:15] <fantasai> fantasai: IME stuff might also expose user dictionaries
# [12:16] <fantasai> fantasai: Aren't there 2 finds? One you're on currently, and others on the page?
# [12:16] <fantasai> glazou: Should we resolve to add ::selection back? Who's going to work on it?
# [12:16] <fantasai> hober: Which spec should this be in?
# [12:16] <fantasai> fantasai: Pseudo-elements Level 4
# [12:17] <fantasai> fantasai: Should probably have L4 just be this and the L3 pseudos.. .do fancy extra stuff in L5
# [12:17] <fantasai> dbaron: I'm happy for adding an issue to the spec
# [12:18] <fantasai> Rossen: Stuff happening in WebApps for selection
# [12:18] <Rossen_> http://w3c.github.io/editing-explainer/
# [12:18] <fantasai> hober: Seleciton task force
# [12:18] <fantasai> Rossen: efforts in that direction for defining most of the things that we actually want, from what I'm hearing
# [12:18] <fantasai> Rossen: Not sure how much overlap there is
# [12:18] <fantasai> Rossen: Would be good to sync up with them
# [12:19] <fantasai> Rossen: Wouldn't expect us to define ::selection
# [12:19] <Bert> s/Seleciton/Selection/
# [12:19] <fantasai> fantasai: We don't define what is selected, but define how the styling works.
# [12:19] * Clilley can't define a selection, but knows one when he sees it
# [12:19] <hober> s/hober: Selection task force/hober: Editing Task Force/
# [12:19] <fantasai> RESOLVED: Add ::selection to Pseudo-elements 4
# [12:19] * Rossen_ when selection is stylable I'll make sure Clilley will not see it
# [12:20] <fantasai> glazou: So who is working on this?
# [12:20] <fantasai> glazou counts astearns, fantasai, andreyr
# [12:20] <fantasai> Topic: outline-radius
# [12:20] <fantasai> andreyr: Mozilla has it implemented, no one else does
# [12:20] <andreyr> https://developer.mozilla.org/en-US/docs/Web/CSS/-moz-outline-radius
# [12:21] <fantasai> dbaron: We agreed at some point that we didn't want this property, just wanted outline to follow border-radius
# [12:21] <fantasai> dbaron: spec says that's what should happen
# [12:21] <fantasai> dbaron: We have a bug on dropping outline-radius and implementing what the spec says, but haven't gotten around to it
# [12:21] <fantasai> krit: defautl impl uses outline of the operating system
# [12:21] <fantasai> krit: might not be able to allow border-radius
# [12:22] <fantasai> krit: so this would only be for styled outlines, e.g. said it should be solid red
# [12:22] <fantasai> krit: focus-ring and outlines are basically the same thing
# [12:22] <fantasai> http://www.w3.org/TR/CSS21/ui.html#dynamic-outlines
# [12:23] <fantasai> Rossen: We don't have such limitations in Windows, can't speak for others...
# [12:23] <fantasai> fantasai: CSS3 UI doesn't say anything about border-radius
# [12:23] <fantasai> fantasai: So if we want that, we need to add it to the spec
# [12:23] <fantasai> fantasai: I agree that makes more sense
# [12:24] <fantasai> dbaron: Def discussed before. I brought up outline-radius, and ppl said should just follow border-radius
# [12:25] <fantasai> fantasai: So do implementors agree they want to do this?
# [12:26] <fantasai> fantasai: Make inner outline radius match border-radius
# [12:26] <fantasai> Rossen_: Trying to think if there's fragmented inlines, unsure what should happen... but do want to match border-radius
# [12:26] <fantasai> krit: Might need to account for http://dev.w3.org/csswg/css-ui/#outline-properties
# [12:27] <fantasai> krit: outline-offset
# [12:27] <fantasai> hober: Agree we should do this, if there's a problem, bring it up.
# [12:27] <fantasai> dbaron: If anyone does this for Gecko, will have to go through our existing uses of outline-radius, and will find out if there's reasons for wanting something different.
# [12:28] <fantasai> krit: Might possibly want rounded outline for square border-radius
# [12:28] <fantasai> hober: Maybe need some text wrt default outline matching system conventions, which may or may not match border-radius
# [12:29] <fantasai> fantasai: In cases where outline is just outside border, should amtch the border.
# [12:29] <fantasai> fantasai: For buttons, e.g., focus outline is around just the text sometimes, not the button shape, in that case could say whatever that thing is that is surrounded, it has a border-radius.
# [12:30] <fantasai> andreyr: Mozilla had it, was hoping that others would implement.
# [12:30] <fantasai> fantasai: Now you can just say that "your behavior is wrong, here's a patch"
# [12:31] <fantasai> fantasai: Mozilla wants to drop outline-radius and just follow border-radius
# [12:31] <dbaron> is outline-radius expansion the same as box-shadow spread expansion?
# [12:32] <fantasai> Greg: Do we have any author feedback on this?
# [12:32] <fantasai> ACTION: glazou Ask authors for feedback on this
# [12:32] * trackbot is creating a new ACTION.
# [12:32] * RRSAgent records action 1
# [12:32] <trackbot> Created ACTION-635 - Ask authors for feedback on this [on Daniel Glazman - due 2014-09-15].
# [12:32] <fantasai> RESOLVED: outline corners follow border-radius (no additional outline-radius property needed)
# [12:34] <fantasai> <br type=lunch>
# [12:35] * Quits: Rossen_ (~Rossen@public.cloak) (Ping timeout: 180 seconds)
# [12:35] * dauwhe CSS itself is simpler than CSS-Lunch
# [12:36] * Quits: gregwhitworth (~gregwhitworth@public.cloak) (Ping timeout: 180 seconds)
# [12:37] * Quits: glazou2 (~glazou2@public.cloak) (Ping timeout: 180 seconds)
# [12:37] * Quits: glazou (~glazou@public.cloak) (Ping timeout: 180 seconds)
# [12:40] * Quits: andreyr (~andreyr@public.cloak) (Ping timeout: 180 seconds)
# [12:41] * Quits: florian (~florian@public.cloak) (Ping timeout: 180 seconds)
# [12:42] * Quits: glenn (~glenn@public.cloak) (Ping timeout: 180 seconds)
# [12:42] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [12:50] * Quits: ikilpatrick (~ikilpatrick@public.cloak) (Ping timeout: 180 seconds)
# [12:50] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [13:46] * Quits: Ms2ger (~Ms2ger@public.cloak) (Ping timeout: 180 seconds)
# [13:49] * Joins: dauwhe (~dauwhe@public.cloak)
# [13:56] * Joins: ikilpatrick (~ikilpatrick@public.cloak)
# [14:01] * Joins: andreyr (~andreyr@public.cloak)
# [14:02] * Joins: Rossen_ (~Rossen@public.cloak)
# [14:03] * Joins: glazou (~glazou@public.cloak)
# [14:03] * Joins: glazou2 (~glazou2@public.cloak)
# [14:06] <andreyr> first up geometry working draft
# [14:06] <krit> http://dev.w3.org/fxtf/geometry/
# [14:06] <glazou2> ScribeNick: andreyr
# [14:07] <andreyr> the main feedback was there shouldn't be interfaces which describe as magic
# [14:07] * Joins: SteveZ (~SteveZ@public.cloak)
# [14:07] * Joins: gregwhitworth (~gregwhitworth@public.cloak)
# [14:07] <andreyr> feedback was to create constructors
# [14:08] <andreyr> read only interfaces have constructors now
# [14:08] <andreyr> any objections?
# [14:08] <andreyr> comments?
# [14:10] * Joins: florian (~florian@public.cloak)
# [14:10] <andreyr> dbaron: I worry it might be confusing where some properties are writable and some are not
# [14:10] <andreyr> did original proposal have these?
# [14:11] <andreyr> spec has not reallly changed
# [14:11] <andreyr> we would like to have a working draft
# [14:11] <dbaron> s/spec has not/dirk: spec has not/
# [14:11] <andreyr> it's intended to have consutructor defined in the spec
# [14:12] <andreyr> resolution publish working draft for geometry interfaces
# [14:13] <andreyr> Next topic stacking context within SVG
# [14:13] <plinss> s/resolution/RESOLVED:/
# [14:14] <andreyr> would like to have feedback making SVG elements embeded
# [14:16] <TabAtkins> :not(svg|*) > svg { stacking-context: new !important; }
# [14:17] * Joins: zcorpan (~zcorpan@public.cloak)
# [14:19] <fantasai> ScribeNick: fantasai
# [14:19] <zcorpan> :not(svg|*) > svg|svg { stacking-context: new !important; }
# [14:19] <fantasai> [discussion of display property applied to SVG, problem with back-compat due to ppl applying random other displays and it having no effect]
# [14:20] <Bert> bert: z-index applies then, don't need to set position: abs?
# [14:20] <Bert> tab: correct.
# [14:20] <fantasai> Discussion is that SVG automatically creates stacking context.
# [14:20] <fantasai> Also that SVG allows z-index without requiring position: relative.
# [14:21] <fantasai> Clilley asks about foreignObject
# [14:21] * fantasai missed the answer
# [14:22] <fantasai> Clilley: <foreignObject> should also create a stacking context, shouldn't intermix with other SVG things
# [14:23] <fantasai> RESOLVED: root SVG element automatically creates a stacking context, as does <foreignObject>.
# [14:23] <fantasai> RESOLVED: SVG elements honor z-index automatically (like flex items), without requiring 'position'
# [14:24] <fantasai> file:///home/fantasai/w3c/csswg/css-flexbox/Overview.html#painting
# [14:24] <fantasai> Rossen: Grid automatically creates a stacking context for grid items
# [14:25] <fantasai> fantasai: Thought that was a pseudo-stacking context
# [14:25] <fantasai> ...
# [14:25] <fantasai> http://dev.w3.org/csswg/css-flexbox/#painting
# [14:25] <fantasai> fantasai: For SVG elements, should be full stacking context. Think grid/flexbox is pseudo-stacking
# [14:26] <fantasai> Rossen: Wrt perf concerns of stacking context in SVG...
# [14:26] <fantasai> Rossen: People might use that a lot. might result in creating too many stacking contexts
# [14:26] <fantasai> ...
# [14:27] <fantasai> krit: We have CSS properties that create a stacking context. Some of them, like transforms, used very commonly in SVG.
# [14:27] <fantasai> krit: So we resolved that properties like transform don't create stacking context unless 3D
# [14:27] <fantasai> Rossen: Should we do the same thing with z-index?
# [14:28] <fantasai> ...
# [14:28] <fantasai> Rossen: Then we're good
# [14:28] <fantasai> Topic: Prioritizing image(color)
# [14:28] <fantasai> krit: image() function
# [14:29] <fantasai> krit: we had lots of discussion wrt image() function, syntax thereof, responsive images, etc.
# [14:29] <fantasai> TabAtkins: We have that already.
# [14:30] <fantasai> fantasai: What's in Images 3 is a superset of that atm, going to strip it down.
# [14:32] <fantasai> Topic: randomize()
# [14:32] <fantasai> fantasai: Is that like cycle(), except non-deterministic?
# [14:33] <fantasai> Tab writes on the board
# [14:33] <fantasai> We discover that the board doesn't erase.
# [14:34] <fantasai> Tab finds another board
# [14:34] <fantasai> Which also doesn't erase
# [14:34] <fantasai> We find some paper
# [14:34] <fantasai> Which doesn't erase, but there are multiple sheets
# [14:34] <fantasai> Tab writes:
# [14:34] <fantasai> @random foo
# [14:34] <fantasai> red, blue
# [14:35] <fantasai> random-color();
# [14:35] <fantasai> TabAtkins: This is a random generator. It'll first try to exhaust its list. Then it'll generate from the generator.
# [14:35] <fantasai> TabAtkins: If I write
# [14:35] <fantasai> el { color: random(foo); }
# [14:36] <fantasai> TabAtkins: Do I get a brand new color for every single element? Or a color that changes over time?
# [14:36] <fantasai> TabAtkins: Need to specify when the randomness is applied.
# [14:36] <fantasai> TabAtkins: Options we consider so far are per-element or per-rule.
# [14:36] <fantasai> dauwhe: Why do we want to do this?
# [14:36] * Joins: shans__ (~shans@public.cloak)
# [14:36] <fantasai> hober: My use case is that I want to make a really ugly webpage.
# [14:37] <fantasai> krit: It's for abspos, want randomly-positioned items.
# [14:37] <fantasai> Rossen: If the only use case is sprites, one line of JS is a good enough solution.
# [14:37] <fantasai> TabAtkins: If we are going to do random, should be something like this, and need to be able to say when randomness is applid.
# [14:38] <fantasai> Rossen: interoperability testing?
# [14:38] <fantasai> TabAtkins: Dunno, might want to be able to specify seed.
# [14:38] <fantasai> florian: Is this stable across page loads?
# [14:38] <fantasai> fantasai: I think I'm with Rossen, this should be solved with JS for now.
# [14:39] <fantasai> hober: It's already possible to make really ugly webpages, so my use case is already solved without this.
# [14:40] * Quits: shans_ (~shans@public.cloak) (Ping timeout: 180 seconds)
# [14:40] * dauwhe http://www.1001fonts.com/ransom-note-fonts.html
# [14:41] <fantasai> plinss: Is this solveable right now in JS?
# [14:41] <fantasai> TabAtkins: yes
# [14:41] * astearns_ SimonSapin: http://en.wikipedia.org/wiki/Cousin
# [14:41] <fantasai> TabAtkins: for per-element, alter .style of the elements; for per-rule, alter the rule in the style sheet
# [14:41] * astearns_ ooh! SVG! http://en.wikipedia.org/wiki/Cousin#mediaviewer/File:Canon_law_relationship_chart.svg
# [14:41] <fantasai> krit: so what's feedback?
# [14:42] <fantasai> various: Need more use cases to justify something this complicated for something so simple to do in JS
# [14:43] * krit <shape-radius> closest-side/furthest-side and calc()
# [14:43] <fantasai> Topic: <shape-radius>
# [14:43] <fantasai> RESOLVED: Not pursuing randomness at this time.
# [14:43] <fantasai> plinss: We will pursue it at some random future date.
# [14:44] <fantasai> krit: Got request for shape-radius, to have half of farthest-side/closest-side keyword
# [14:44] * glazou2 let's pursuize the randomness
# [14:44] <fantasai> krit: Would like something like calc(farthest-side/2)
# [14:44] <fantasai> krit: Would like to be able to animate that.
# [14:44] <fantasai> astearns: Can we do keywords in calc()?
# [14:45] <fantasai> TabAtkins: Not yet. But rejecting WS change request at last F2F makes it easier to do.
# [14:45] <fantasai> TabAtkins: These become lengths
# [14:45] <fantasai> fantasai: So does auto keyword for width.
# [14:45] <fantasai> fantasai: These aren't computed values.
# [14:45] <fantasai> TabAtkins: Can't do a transition on it, but could do a calc on it.
# [14:46] <fantasai> fantasai, dbaron: If you can do a calc() on it, then you can do a transition on it.
# [14:47] <fantasai> fantasai: We know we want to do this. We've discussed it before. We deferred it from css3-values because it's complicated implementation-wise.
# [14:47] <fantasai> fantasai: Right now, you can implement calc() as a tuple of absolute length and percentage.
# [14:47] <fantasai> fantasai: if you allow keywords, which have to be maintained as keywords, you need to express calc as an expression
# [14:48] <fantasai> TabAtkins: So is the implementation work feasible? Because that is what is stopping us.
# [14:48] <fantasai> krit: Expanding data structure should be straightforward
# [14:49] <fantasai> dbaron: The data structure is the easy part.
# [14:49] <fantasai> dbaron: Have to also modify other things to handle, e.g. all things that handle input of 'auto' to handle input of 'auto' with calc()
# [14:50] <fantasai> fantasai: Have to consider, e.g. for height of 'auto', have margin collapsing, but non-auto have no margin collapsing, what do you do with calc involving auto?
# [14:50] <fantasai> TabAtkins: Might be hard for auto.
# [14:51] <fantasai> plinss: Do we want a whitelist or blacklist?
# [14:51] <fantasai> Rossen: Probably want a whitelist
# [14:51] <fantasai> fantasai: Whitelist isn't per-keyword, it's per keyword-property combination.
# [14:52] <fantasai> fantasai: Going to have to modify propdef table again. Though I suspect animatability, computed value, and calcability are closely related and could be compressed down
# [14:53] <fantasai> fantasai: So, what action do we give krit?
# [14:53] <fantasai> TabAtkins: Make sure implementations are willing to do this
# [14:53] <fantasai> fantasai: And maybe come up with the whitelist
# [14:54] <fantasai> TabAtkins: Want to see if we can come up with generalizable rules.
# [14:54] <fantasai> TabAtkins: Would FF be interested in doing this, if we whitelist some keywords?
# [14:54] <fantasai> dbaron: Yes, just depends on prioritization.
# [14:55] <fantasai> fantasai: There was also min()/max(), which had complications. Are those complications related?
# [14:55] <fantasai> dbaron: No, it's different.
# [14:56] <fantasai> dbaron: For example, if you have a div that has a 200px-wide image inside it, and has margin-left: 50%
# [14:56] <fantasai> dbaron: The div's parent might, depending on other things, have an intrinsic width of 400px depending on other things
# [14:57] <fantasai> dbaron: You say this div needs to be 50% + 200px wide, so the total has to be 400px
# [14:57] <fantasai> dbaron: That inversion of logic depends on being able to say that "this element has a length of 200px+50%"
# [14:58] <fantasai> dbaron: Once you have a min or a max that has a length on one side and a percentage on the other.
# [14:58] <fantasai> dbaron: Then you can't do that.
# [14:58] <fantasai> dbaron: This happens most often in table layout, though there are a few other cases
# [14:58] <fantasai> dbaron: I think this was the issue that made me give up on min/max
# [14:59] <fantasai> dbaron: The percentage and length thing, you can use a length and a percentage where, essentially, if you have something that is 50% plus 200px,
# [14:59] <fantasai> dbaron: If you graph the percentage basis against the result
# [14:59] <fantasai> dbaron: This is some monotonic line
# [14:59] <fantasai> dbaron [draws graph of basis (x) time result (y)
# [15:00] <fantasai> line goes from 200px at zero upwards
# [15:00] <fantasai> dbaron: With min/max you can have any piecewise continuous line
# [15:00] <fantasai> [draws a zigzag]
# [15:00] <fantasai> dbaron: you might find more than one solution, or none
# [15:01] <fantasai> dbaron: Maybe we need to go back and define table layout and what you do here.
# [15:01] <fantasai> dbaron: Or maybe not, just say we don't care...
# [15:01] <fantasai> dbaron: I think that was the main issue with min/max
# [15:01] <dbaron> http://lists.w3.org/Archives/Public/www-style/2011Oct/0735.html
# [15:02] <fantasai> [quick look at css3-values to see if any other issues, no not really]
# [15:02] <dbaron> s/piecewise continuous/continuous and piecewise-linear/
# [15:03] <fantasai> Topic: Motion path
# [15:03] <fantasai> krit: Would like to present a solution for motion path.
# [15:03] <krit> http://dirkschulze.github.io/specs/motion-1/
# [15:03] <fantasai> krit: Not asking for resolution or anything, just want to present it
# [15:03] <fantasai> krit: This proposal is about specifying a path along which object moves or transforms
# [15:03] <fantasai> krit: SVG wants all kinds of animation things. Was also requested to have that on HTML elements
# [15:04] <fantasai> krit: For this proposal I created 3 different longhand propoerties
# [15:05] * Rossen_ it looks like Geco is the only impl that reverse resolves % inside shrink-to-fit http://jsfiddle.net/cy0nnLcn/
# [15:05] <fantasai> krit shows an example of airplane along an S-curved path.
# [15:05] <fantasai> plane turns to stay facing forward along path
# [15:06] <fantasai> krit: You could use motion-path property, which takes <basic-shape> | path() | <url> pointing to SVG
# [15:06] <fantasai> krit: motion-position defines position along the path
# [15:06] <fantasai> krit: motion-position: <length> | <percentage>
# [15:06] <fantasai> krit: can animate along the path
# [15:07] <fantasai> krit: motion-rotation: [auto | reverse] && <angle>
# [15:07] <fantasai> krit: ...
# [15:07] <fantasai> krit: Shane proposed to have a motion() function, which is a CSS transform function
# [15:07] <fantasai> krit: Can be used together with other transform functions (like rotate, translate, etc)
# [15:07] <fantasai> krit: Syntax would be same as motion shorthand property
# [15:07] <fantasai> krit: all i want to do is present proposal, ask you to look at it for next F2F
# [15:08] <fantasai> astearns: motion-position, takes any length, e.g. ems?
# [15:08] <fantasai> yes
# [15:08] <fantasai> fantasai: What if too long?
# [15:09] <fantasai> krit: Definitely issues to discuss, need mroe proposals
# [15:09] <fantasai> gregwhitworth: position only beginning and end right?
# [15:09] <fantasai> gregwhitworth: Might want to snap to various places
# [15:09] <fantasai> TabAtkins: use another transform to shif tthe plane around
# [15:10] <fantasai> gregwhitworth: might want to pivot around a corner
# [15:10] <fantasai> krit: Can apply motion-rotation and transform together
# [15:10] <fantasai> TabAtkins: motion() does some magic combination of translate and rotate
# [15:10] <fantasai> Bert: A bit confusing that this property doesn't create motion, need to animate it
# [15:11] <fantasai> glazou: tried to make planets with moons on this
# [15:11] <fantasai> glazou: Miss one thing to do that... calculating angle based on position
# [15:12] <shans__> if you use the motion function as part of a transform specification then you can do that
# [15:12] <fantasai> Clilley: Good to call it motion-path because a) that's what SVG calls it and b) it's a path along which the thing is intended to move
# [15:12] <fantasai> Bert: Yes, but if you don't combine with animation, then it's equivalent to translate
# [15:12] <fantasai> Bert: It's a nice way to define a translation
# [15:13] <fantasai> Bert: but nothing moves
# [15:13] <fantasai> Bert: Maybe if SVG calls it that, then okay. But I found it confusing because the motion comes from somewhere else
# [15:13] <fantasai> fantasai: Well, you can propose new names if you have a good suggestion
# [15:14] <fantasai> glazou: This is 2D only?
# [15:14] <fantasai> krit: Atm, yes. Could expand to 3D
# [15:14] <fantasai> shans__: Dino brought up point on the ML that you need to specify the motion-path multiple times
# [15:15] <fantasai> shans__: Can we get around that somehow?
# [15:15] <fantasai> TabAtkins: Could have a null path value, it assumes the same path
# [15:15] <fantasai> shans__: would we run into trouble later if we ever want null path to mean an empty path?
# [15:15] <fantasai> fantasai: Just put a zero-length path
# [15:15] <fantasai> Clilley: That's not quite the same
# [15:16] <fantasai> Clilley: zero-length path does give you an orientation. Does have a coordinate system, even if just a point. So affects rotation
# [15:16] <fantasai> Clilley: But def want to avoid repeating the path spec
# [15:16] <fantasai> TabAtkins: Need to have some kind of default value fo rmotion to fill in for transform animations
# [15:16] <fantasai> shans__: Could maybe have motion() and motion-position()
# [15:17] <fantasai> krit: Could say that if you odn't specify a path in motion(), take it from motion-path property.
# [15:17] <TabAtkins> motion(auto 20% 10deg)
# [15:17] * Quits: andreyr (~andreyr@public.cloak) (Ping timeout: 180 seconds)
# [15:17] <fantasai> krit: But can discuss later if interest
# [15:18] <fantasai> fantasai: So, seems like everyone likes this proposal and wants us to work on it. Any objections to making an ED?
# [15:18] <fantasai> general agreement
# [15:18] <fantasai> TabAtkins: [something about WebApps]
# [15:18] <shans__> ^^ This can also make the WebAnimation spec smaller
# [15:19] <dbaron> s/WebApps/Web Animations/
# [15:19] <fantasai> glazou: When you define a motion-path, and you query computed value of transforms. Does it reflect the motion?
# [15:19] <fantasai> TabAtkins: yes
# [15:19] <fantasai> TabAtkins: it's just translate+rotate
# [15:19] <fantasai> TabAtkins: gets reflected in matrix the same way
# [15:19] <fantasai> shans__: But not exactly the same, cuz can't animate from that to a translation
# [15:19] <TabAtkins> TabAtkins: The WebAnim spec already has a specialized construct for this precise use-case.
# [15:19] <fantasai> krit: So if anyone has concerns about it, please post
# [15:20] <fantasai> glazou: What happens i fyou have both transform and motion
# [15:20] <fantasai> krit: Proposal currently says that motion is premodded by transform
# [15:20] <fantasai> krit: So you apply the motion path, then you apply the transform
# [15:20] <shans__> s/premodded/premultiplied/
# [15:20] * Joins: andreyr (~andreyr@public.cloak)
# [15:20] <fantasai> krit: Like writing writing the transform functions over the other transform functions
# [15:21] <fantasai> dbaron: Is premultiple cation going to give you transform of the thing or transform of the path?
# [15:21] <fantasai> dbaron: One of the multiplications will rotate the thing and then move it along the path,
# [15:21] <fantasai> dbaron: Other will rotate the path and then move along that
# [15:22] * fantasai is confuzed
# [15:23] <fantasai> [unminuted confuzzliness]
# [15:23] <dbaron> Tab: ... ... So it will rotate the thing rather than the path.
# [15:23] <fantasai> shans__: Transform function happens after the path.
# [15:23] <fantasai> shans__: wherever the element ends up on the path, it gets transformed there.
# [15:23] <shans__> s/function/property/
# [15:23] <TabAtkins> dbaron: If I did {motion: foo; translate: 50px; }, does it move it 50px and then do the motion stuff, or do the motion and then translate it in whatever direction the element is now pointing?
# [15:24] <TabAtkins> TabAtkins: The second one. If you want the first, use transform:translate(...) motion(...); explicitly.
# [15:24] <fantasai> RESOLVED: Make this an official editors draft
# [15:25] <fantasai> fantasai: Action on the WG to read, review, send comments about what you would like changed or noted or marked as an issue for FPWD
# [15:25] <fantasai> krit: Editors will be krit, shane, Tab
# [15:25] <fantasai> <br type=coffee>
# [15:30] * Quits: plh (plehegar@public.cloak) ("Leaving")
# [15:31] * sylvaing__ is now known as sgalineau
# [15:42] * Joins: plh (plehegar@public.cloak)
# [15:45] * Quits: florian (~florian@public.cloak) (Ping timeout: 180 seconds)
# [15:51] * Joins: florian (~florian@public.cloak)
# [15:57] * Clilley cries off until he can hear properly
# [15:57] * Clilley tomorrow
# [15:58] <SimonSapin> ScribeNick: SimonSapin
# [15:58] * Quits: Rossen_ (~Rossen@public.cloak) ("Page closed")
# [15:58] <SimonSapin> florian: Issues in MQ4
# [15:58] <florian> http://dev.w3.org/csswg/mediaqueries4/
# [15:58] * Joins: Rossen_ (~Rossen@public.cloak)
# [15:59] <SimonSapin> florian: Values and Units don’t define ratios, so MQ does
# [15:59] * Quits: andreyr (~andreyr@public.cloak) (Ping timeout: 180 seconds)
# [15:59] <SimonSapin> florian: used for aspect ratios. Defined as integer/integer
# [16:00] <SimonSapin> florian: there are reports of ppl writing non-integers in the wild: 1.5/1
# [16:00] <SimonSapin> TabAtkins: I’ve seen arbitrary ones with weird numbers
# [16:00] <SimonSapin> florian: I feel it’s not worth defining this
# [16:00] <Clilley> 1.77777777777777778 : 1 ( == 16:9)
# [16:01] <SimonSapin> florian: do we want to allow nonintegers?
# [16:01] <SimonSapin> Clilley: only a problem with squares
# [16:02] <SimonSapin> Clilley: if you do something almost square, you can do the usual epsilon thing to compare floating point numbers
# [16:02] * Quits: koji (~koji@public.cloak) (Client closed connection)
# [16:02] * Joins: koji (~koji@public.cloak)
# [16:02] <SimonSapin> florian: do we wantto define floating point equality, or is it not worth the bother?
# [16:03] * glazou2 TabAtkins (1+sqrt(5))/2 ?
# [16:03] <SimonSapin> florian: if nobody cares let’s do the easy one
# [16:03] <SimonSapin> RESOLVED: no change : aspect ratios remain integers
# [16:04] <SimonSapin> florian: (min/max)-device-(width/height) is the size of the screen, not browsers. It’s not useful. Drop it?
# [16:05] <SimonSapin> s/Drop/Deprecate/
# [16:05] <SimonSapin> Clilley: (explains how sites use it wrong)
# [16:05] <SimonSapin> florian: also used to detect iphones
# [16:06] <SimonSapin> zcorpan: can we change the semantics to be equivalent to (min/max)-(width/height)?
# [16:06] <SimonSapin> dbaron: also fun on mobile, browsers uses different ideas of viewport
# [16:07] <SimonSapin> Clilley: sounds reasonable. If the spec documents that these approaches are fragile, explaining why
# [16:07] <dbaron> ppk on the viewport stuff: http://vimeo.com/channels/cssday/100523275
# [16:07] <SimonSapin> florian: so far, sites use the very few media features available. If you’re 320px wide, you probably have touch
# [16:09] <SimonSapin> RESOLVED: Deprecate device-* media features. Keep behavior, but authors "must not use"
# [16:09] <SimonSapin> Bert: so are we continuing to support it?
# [16:09] <SimonSapin> Clilley: yes, supporting forever but not recommended, that’s what deprecated means
# [16:09] <Clilley> yes, that is what deprecation means
# [16:10] <SimonSapin> Glenn: "should not use"?
# [16:10] <SimonSapin> TabAtkins: we can use "must" for author conformance, it’s fine
# [16:10] * glazou2 it's recommended that web authors don't use...
# [16:10] <SimonSapin> plinss: really should not
# [16:11] <SimonSapin> TabAtkins: resolution MQ has interesting handling of non-square pixels
# [16:11] <SimonSapin> TabAtkins: exact value never matches non-square. min/max do, but behave differently
# [16:12] <SimonSapin> TabAtkins: we have to decide what the <= syntax does
# [16:12] * renoirb_afk is now known as renoirb
# [16:12] <SimonSapin> TabAtkins: we define min/max by saying they’re equivalent to <= or >=, but that doesn’t tell us how to handle this
# [16:13] <TabAtkins> (resolution < 4/3) {...} (resolution >= 4/3) { ... }
# [16:13] <SimonSapin> florian: it does, but [example] doesn’t cover the whole range
# [16:13] <TabAtkins> resolution < 2x and resolution >= 2x
# [16:13] * glazou2 changes topic to '#css http://wiki.csswg.org/planning/sophia-2014#agenda'
# [16:13] <SimonSapin> TabAtkins: I’d prefer to have <= >= work sanely, be consistent
# [16:14] <SimonSapin> TabAtkins: then we might as well say that exact resolution works with non-square
# [16:14] * sgalineau likes that sanity is now a mere preference
# [16:14] <SimonSapin> plinss: what behavior, use the smaller? larger?
# [16:14] <SimonSapin> TabAtkins: pick one
# [16:14] <SimonSapin> TabAtkins: do we have non-rectangular pixels in practice?
# [16:14] <SimonSapin> Glenn: All the time [missed example]
# [16:15] <SimonSapin> dbaron: do browsers do this per spec?
# [16:15] <SimonSapin> TabAtkins: good question
# [16:15] <SimonSapin> dbaron: Gecko does not. We have a single number
# [16:15] <glazou2> s/[missed example]/[televisions for instance]
# [16:15] <SimonSapin> Rossen_: We used to support non-square, and deprecated it. No one complained that we know of.
# [16:15] <SimonSapin> florian: most likely, browser engine doesn’t know
# [16:16] <SimonSapin> TabAtkins: proposal: work on some undefined number in the range
# [16:16] <SimonSapin> dbaron: on windows/linux, gecko uses the vertical resolution
# [16:16] <SimonSapin> Rossen_: we do the same
# [16:16] <SimonSapin> zcorpan: In CSSOM View, device px ratio uses the smaller
# [16:17] <SimonSapin> dbaron: on Mac, we call the system API which gives a single number
# [16:17] <SimonSapin> TabAtkins: would ppl be ok with just using the vertical resolution?
# [16:17] <SimonSapin> SimonSapin: do we know what the Mac system API does?
# [16:17] <SimonSapin> hober: *shrugs* returns a number
# [16:18] <SimonSapin> florian: that’s better than different behavior in min- and max-
# [16:18] <SimonSapin> hober: I wanna check compat-wise
# [16:19] <SimonSapin> dbaron: no idea if other browsers are consistent
# [16:19] <SimonSapin> florian: "should use vertical if you have both, whatever if you can’t" ?
# [16:19] <SimonSapin> TabAtkins: if somebody can’t do it, they’ll tell us
# [16:20] <SimonSapin> dbaron: checking if the resolution from the OS actually influences the MQ at all
# [16:21] <SimonSapin> florian: we care about CSS px, not device pixels
# [16:21] <dbaron> dbaron: ... it's not actually relevant
# [16:21] <dbaron> florian: this only happens if you're putting a different number of device pixels per CSS pixel vertically vs. horizontally
# [16:22] <SimonSapin> TabAtkins: proposed: use the vertical resolution
# [16:22] <SimonSapin> RESOLVED: 'resolution' MQ uses the vertical resolution when pixels are not square
# [16:22] <SimonSapin> florian: next issue, we might want a separate MQ for the kind of resolution printing cares about
# [16:23] <SimonSapin> florian: nobody really asked for it
# [16:24] <SimonSapin> florian: Issue 5: overflow-block, overflow-inline. On screen, you get scrollbars. In print, next page. You might want different behavior in each direction
# [16:24] <SimonSapin> florian: issue 6 is naming for these properties
# [16:25] <SimonSapin> florian: issue 5 is, spec says "when things overflow the viewport", but viewport is not the right term. What is the right term?
# [16:25] <SimonSapin> plinss: if you change writing mode, you change what is inline or block, but not your paper
# [16:25] <SimonSapin> florian: still helps for mostly-vertical documents
# [16:26] <SimonSapin> plinss: not sure it’s rational to use logical terms rather than physical
# [16:26] <SimonSapin> TabAtkins: yes, that’s the issue, we’re not sure
# [16:26] <SimonSapin> plinss: At MQ time, do we ever know which is which?
# [16:26] <SimonSapin> TabAtkins: that’s a question: should we have MQ for "main writing mode"
# [16:26] <SimonSapin> TabAtkins: user preference for display layout
# [16:27] <SimonSapin> florian: If no UA can switch mode initially, yes
# [16:27] <SimonSapin> plinss: if I switch printer to landscape…
# [16:27] <SimonSapin> florian: you change the ratio, but keep directions
# [16:28] <SimonSapin> dbaron: Is there a way for author to know what the default direction is?
# [16:28] <SimonSapin> TabAtkins: might be to expose in MQs
# [16:28] <SimonSapin> TabAtkins: ereaders exist in japanese market that let you swap between vertical and horizontal text
# [16:28] <SimonSapin> florian: we want to stop people querying for print when they want to query for pages
# [16:29] <SimonSapin> florian: now the two properties take different values: -inline only takes none or scroll. -block also has page. Can’t do that with physical… or maybe we can
# [16:29] <SimonSapin> plinss: odd pages on the right, even pages on the left, in 2-page spreads
# [16:30] <SimonSapin> plinss: [...] it’s complicated
# [16:30] <SimonSapin> TabAtkins: too complicated to be distilled into the common case for something like this?
# [16:30] <SimonSapin> florian: if you overflow in the block direction, go to the next page
# [16:31] <SimonSapin> plinss: In a spread, if something overflows in the inline directions, theoritically it should overflow into the next page
# [16:31] <SimonSapin> plinss: commonly done with images overflowing over a two-page spread
# [16:32] <SimonSapin> TabAtkins: [...] special-case spreads
# [16:32] <SimonSapin> TabAtkins: can probably leave it out for now, needs input. But works within this paradigm
# [16:32] <SimonSapin> plinss: every other page can overflow in every other direction
# [16:33] <SimonSapin> dauwhe: can’t really define speards in CSS right now
# [16:33] <SimonSapin> plinss: yes, but we should
# [16:33] <dauwhe> s/speards/spreads/
# [16:33] <SimonSapin> TabAtkins: there’s still a main overflow direction, and the other where you shouldn’t overflow
# [16:34] <SimonSapin> TabAtkins: not use it’s always left and down
# [16:34] <SimonSapin> Bert: this is before the page has any content, talking about device here
# [16:34] <SimonSapin> florian: but you expect things in a given direction
# [16:35] <SimonSapin> Bert: I have to mentally translate from block/inline
# [16:35] <SimonSapin> TabAtkins: you already have to do that anyway
# [16:35] <SimonSapin> plinss: we also have physical properties
# [16:35] <SimonSapin> TabAtkins: these are legacy
# [16:36] <SimonSapin> plinss: but this is about physical characteristics of the device, not sure of the value of making these logical
# [16:36] <SimonSapin> florian: interaction between physical device and what you lay out on it
# [16:36] <SimonSapin> florian: It’s tricky. I guess we don’t have a resolution?
# [16:36] <SimonSapin> TabAtkins: not yet
# [16:36] <SimonSapin> florian: ok, issue 5.
# [16:37] <SimonSapin> florian: the thing being overflowed is not the viewport, what is it?
# [16:37] <SimonSapin> hober: initial containig block?
# [16:38] <SimonSapin> TabAtkins: yeah, probably
# [16:38] <SimonSapin> Clilley: current CB? I want the current page, not first page
# [16:38] <SimonSapin> TabAtkins: ICB changes per page
# [16:38] <SimonSapin> SimonSapin: does it really? css3-page says not
# [16:38] <SimonSapin> plinss: that’s a bug
# [16:39] <SimonSapin> SimonSapin: We discussed it, but haven’t updated the spec
# [16:39] <SimonSapin> TabAtkins: not sure how that works, then
# [16:39] <SimonSapin> TabAtkins: action on me and Simon to check what css-page says, and what it should
# [16:40] <SimonSapin> SimonSapin: it’s complicated because viewport units
# [16:41] <SimonSapin> florian: Issue 7. Light-level MQ, to tweak contrast. But E-ink would not
# [16:41] <fantasai> No, the ICB does not change per page.
# [16:41] <SimonSapin> florian: there is a Microsoft MQ for high contrast. a11n feature when users forces it
# [16:41] <SimonSapin> florian: it’s not ideantical to our MQ, but very related
# [16:41] <fantasai> If you abspos a thing, it always goes to the first page.
# [16:41] <SimonSapin> florian: in addition, there is an inverted mode
# [16:42] <SimonSapin> florian: suggest to add one value to the existing meadia feature, and add one with three values.
# [16:43] <SimonSapin> florian: the extra value to light-level is activated when browser forces you into high constrat. It ignores your CSS or tweaks it. You react to it.
# [16:43] <SimonSapin> hober: what’s it called
# [16:43] <hober> There's also one in Indie UI
# [16:43] <hober> http://www.w3.org/TR/indie-ui-context/#user-contrast
# [16:43] <SimonSapin> florian: Microsoft has a prefixed media feature. When it puts you in hight contrast mode, it let’s you know
# [16:43] <SimonSapin> plinss: can’t override, but can adapt
# [16:43] <SimonSapin> hober: [link above] more general than the MSFT proposal
# [16:44] <SimonSapin> hober: could translate -ms-high-constrast to -1 .. 0 .. +1
# [16:44] * Quits: yamamoto (~yamamoto@public.cloak) ("Page closed")
# [16:44] <SimonSapin> hober: negative number represents lower than average contrast
# [16:44] <SimonSapin> TabAtkins: I really don’t like this design
# [16:45] <Clilley> so -1.0 means "unreadable"
# [16:45] <SimonSapin> florian: finishing this proposal: new media feature inversion has 3 values: none, requested and enforced
# [16:46] <SimonSapin> none is as usual. Requested: nothing has happened, but you should invert yourself. Enforced: you have been inverted but might want to double invert some images
# [16:46] <hober> Indie UI also has a color inversion bit:
# [16:46] <hober> http://www.w3.org/TR/indie-ui-context/#colors-inverted
# [16:46] <SimonSapin> TabAtkins: shouldn’t work quite that way [...]
# [16:47] <SimonSapin> TabAtkins: might be useful to add high-contrast to light-level, and add the MSFT proposal that tells you what you’re in
# [16:48] <SimonSapin> TabAtkins: if the high contrast MF is set but light-level: high-contrast is false, you are requested but not forced
# [16:48] <SimonSapin> florian: you dev on a device that can force you but not request. You invert images. On another device that asks you, you just invert images.
# [16:49] <SimonSapin> TabAtkins: Inverting is stupid. It’s just a cheap way to do white on black text
# [16:49] <SimonSapin> florian: the MSFT value says you *have been* inverted… Doc is not clear. But another property lets you disable it, suggesting it’s done to you
# [16:50] <SimonSapin> florian: that’s my proposal: 2 axiseseses
# [16:50] <SimonSapin> hober: on the constrast case, OS X has a continuous contrast adjuster
# [16:51] <SimonSapin> TabAtkins: light level uses keywords to split into significant buckets. You’re not gonna do a whole range of variation, but I don’t know what values mean
# [16:51] <SimonSapin> hober: you typically pick a threshold
# [16:51] <SimonSapin> TabAtkins: what threshold? Keywords pick for you
# [16:52] <SimonSapin> TabAtkins: invert is weird, you want to respond specifically
# [16:52] <SimonSapin> TabAtkins: on android, it literally inverts pixels. It often gives you white and black, but not always, and makes you images look stupid
# [16:53] <SimonSapin> TabAtkins: Windows adjusts your CSS to match the desired scheme
# [16:53] <SimonSapin> fantasai: why can’t browsers do intelligent things?
# [16:53] <SimonSapin> TabAtkins: the android a11n level is low level
# [16:54] <SimonSapin> fantasai: browser can still uninvert images by itself
# [16:54] <SimonSapin> hober, florian: unclear what should be inverted, not, or removed. (e.g. shadows)
# [16:54] <SimonSapin> florian: could be in user stylesheet: please invert my things
# [16:55] <SimonSapin> fantasai: rather, please you white text on a black background
# [16:55] <SimonSapin> hober: the user pref is about a color scheme, but system-level not
# [16:56] * sgalineau recalls the -ms queries were about customizing the design when high-level contrast is on e.g. preserve or remove backgrounds, shadows etc. back then printing disabled backgrounds by default but not high-contrast.
# [16:56] <SimonSapin> florian: proposal: add a value to light-level: you have been put in high contrast. And add a new media feature: you have been inverted, you may want to adapt
# [16:57] <SimonSapin> fantasai: having light-level should stay about light level. You can have another thing for high contrast/inversions/etc
# [16:57] <SimonSapin> plinss: call it accessibility
# [16:58] <SimonSapin> florian: might or might not want to merge with printer wants to save ink
# [16:58] <SimonSapin> TabAtkins: that’s requested too
# [16:59] <SimonSapin> hober: as far as having high contrast keyword vs values, author will pick a threshold. I’m worried about apps with a web view where the rest of the app reacts continuously, but web view can’t
# [16:59] <SimonSapin> TabAtkins: sensors are terribly calibrated. If you want fine-grained control, do it in JS, there’s an API
# [17:00] <SimonSapin> fantasai: could have keywords *and* numeric value?
# [17:00] <SimonSapin> florian: one media feature with all the things done to you?
# [17:01] * glazou2 is suprised we don't pronounce MediaQueries as MediaQuerize these days...
# [17:01] <SimonSapin> hober: they’re independent
# [17:01] <SimonSapin> fantasai: although inverted *and* saving ink doesn’t really work
# [17:01] * astearns_ MediaQuerii
# [17:02] <SimonSapin> fantasai: typically remove background, and increase contrast of text
# [17:02] <SimonSapin> hober: greyscale?
# [17:02] <SimonSapin> fantasai: there’s a MQ for that.
# [17:02] <SimonSapin> plinss: iOS a11n settings has three settings for constrast [...] everybody does it differently
# [17:03] <fantasai> hober, return 0 for http://www.w3.org/TR/css3-mediaqueries/#color
# [17:04] <SimonSapin> TabAtkins: possibly don’t adjust light-level, but pull the indie UI color inversion thing and the MSFT one
# [17:04] <SimonSapin> hober: both keywords and numeric?
# [17:04] <Bert> -> http://www.w3.org/TR/indie-ui-context/#colors-inverted indie-ui colors-inverted
# [17:04] <SimonSapin> florian: drop the active value and pull in the rest of MSFT proposal
# [17:04] <SimonSapin> fantasai: 'none' should be falsy
# [17:05] <SimonSapin> florian: we’ve used 0 and 1 for booleans
# [17:05] <SimonSapin> TabAtkins: that was dumb
# [17:06] <SimonSapin> florian: prefixed version can keep 'active'
# [17:06] <fantasai> s/fantasai: 'none' should be falsy/TabAtkins: I think active was because none didn't used to be falsy/
# [17:06] * Quits: plh (plehegar@public.cloak) ("Leaving")
# [17:06] * glazou2 astearns_ then MediaScrutinies in latin...
# [17:06] <SimonSapin> florian: should we include printer saving ink?
# [17:07] <SimonSapin> fantasai: yes, it’s very similar
# [17:08] <florian> prop 1: pull in high-contrast from http://msdn.microsoft.com/en-us/library/windows/apps/hh465764.aspx, without the active value
# [17:08] <florian> prop 2: add "inverted" with values "none" and "inverted"
# [17:08] <SimonSapin> TabAtkins: the color-adjust property takes 'economy' and 'exact'. Take that as a media feature
# [17:08] <SimonSapin> TabAtkins: we also want a 'none' value for no adjustment
# [17:08] <SimonSapin> plinss: property vs. media query?
# [17:09] <SimonSapin> TabAtkins: you want to say don’t do this (property) or adapt when it,s done (MQ)
# [17:09] <florian> prop 3: as ink-saving, with none and economy
# [17:10] <SimonSapin> fantasai: economy is default. Author can override to exact, and users can override again to force economy
# [17:11] <SimonSapin> TabAtkins: color adjusting is not just a print thing
# [17:11] * sgalineau needs very high contrast after a night at Sherry Butt
# [17:11] <SimonSapin> fantasai: doesn’t matter on e-ink, right? Maybe on something white is more expansive
# [17:12] <SimonSapin> TabAtkins: we want to get rid of the print media type
# [17:13] <SimonSapin> fantasai: "don’t use too much black" is different from "you don’t get backgrounds"
# [17:13] <SimonSapin> TabAtkins: yes, you can want not to override adjustment, but still react to it
# [17:14] <SimonSapin> fantasai: this media feature doesn’t tell me that I’m printing
# [17:16] <SimonSapin> dbaron: there’s a tradeoff, you’re asking the authors to make fine-grained decisions that they probably don’t care about. Making stylesheets for situations they’re never gonna test
# [17:16] <fantasai> dbaron++
# [17:16] <SimonSapin> dbaron: you have to split it up at levels authors will care about
# [17:17] <SimonSapin> fantasai: if we have the color-adjust property, authors who care will set it to exact and do the right thing
# [17:18] * Joins: plh (plehegar@public.cloak)
# [17:18] <SimonSapin> plinss: color adjust will prevent the browser to remove backgrounds as well?
# [17:18] <SimonSapin> TabAtkins: yes
# [17:18] * Joins: Ms2ger (~Ms2ger@public.cloak)
# [17:19] <SimonSapin> florian: proposal 3 above is rejected?
# [17:19] <SimonSapin> TabAtkins: correct
# [17:19] <SimonSapin> TabAtkins: proposals 1 and 2 look like they have consensus
# [17:19] <SimonSapin> hober: I’d like to phrase 1 differently
# [17:20] <SimonSapin> hober: keywords vs numerical value vs both
# [17:20] <SimonSapin> TabAtkins: that’s independent
# [17:20] <SimonSapin> hober: I disagree
# [17:22] <fantasai> color-adjusted: none | light-high-contrast | dark-high-contrast | inverted
# [17:22] <fantasai> color-preference: none | light-on-dark | dark-on-light
# [17:22] <fantasai> color-adjusted: none | [ light-high-contrast | dark-high-contrast ] || inverted
# [17:22] <SimonSapin> florian: also include inversion in that media feature?
# [17:23] <SimonSapin> florian: do we want inverted high contrast dumb variant?
# [17:23] <SimonSapin> fantasai: high contrast gets rid of the grays
# [17:23] <SimonSapin> TabAtkins: then maybe we want inversion separate
# [17:24] <hober> colors-inverted: none | inverted
# [17:24] <SimonSapin> TabAtkins: you can still test for inversion alone in a multi-value media feature
# [17:25] <SimonSapin> fantasai: in MSFT high-contrast, is everything forced to white and black?
# [17:25] <SimonSapin> gregwhitworth: no, it’s light and dark
# [17:26] <fantasai> gregwhitworth: you can have colored high-contrast
# [17:27] <hober> @media (colors-inverted)
# [17:28] <SimonSapin> TabAtkins: we still want inversion an additional separate MQ, for the boolean context to be useful
# [17:28] <SimonSapin> fantasai: in that case, split it out even more
# [17:29] <fantasai> high-contrast: white-on-black | black-on-white | none
# [17:30] <SimonSapin> florian: original reason to bundle this with light level is that light level can be faked for a11n
# [17:31] <SimonSapin> s/a11n/a11y/g
# [17:31] <SimonSapin> florian: intentionally bundle a11y things with non-a11y, so they get used
# [17:32] <SimonSapin> hober: there’s a treadoff between one n-dimensional MQ, and a bunch of booleans
# [17:33] <SimonSapin> fantasai: responding to light and responding to want white and black / black on white is similar
# [17:34] <astearns_> add "inverted" with values "none" and "inverted"
# [17:34] <SimonSapin> RESOLVED: Add color-inverted media feature with values 'none' and 'inverted'
# [17:35] <astearns_> pull in high-contrast from http://msdn.microsoft.com/en-us/library/windows/apps/hh465764.aspx, without the active value, adding the boosted value?
# [17:35] * sgalineau color-inverted: inverted looks like a double negative
# [17:35] <SimonSapin> florian: next: pull in media constrast media feature from MSFT, remove 'active', and add 'boosted' which is pixel level rather than CSS level
# [17:35] <fantasai> It should probably be color-inverted: none | all | luminance | hue
# [17:36] <fantasai> or something
# [17:36] <SimonSapin> hober: (responding to sgalineau) doesn’t matter, in practice you use it as a boolean.
# [17:36] <fantasai> color-inverted: none | luminance || hue
# [17:36] * liam hopes there is also a low-contrast mode supported in there somewhere
# [17:37] <SimonSapin> fantasai: do we need low contrast?
# [17:37] <SimonSapin> florian: does it exist in any OS?
# [17:38] <SimonSapin> plinss: it’s possible to lower
# [17:38] <liam> [yes, gnome supports it, across platforms]
# [17:38] <fantasai> color-contrast: normal | high | low
# [17:38] <liam> [both high and low contrast "themes" are supplied, for accessibility reasons]
# [17:39] <hober> http://www.w3.org/TR/indie-ui-context/#media-feature-user-contrast
# [17:40] <fantasai> color-contrast: <number>
# [17:40] <SimonSapin> hober: Indie UI is -1 to 1, I assume they have good reasons. Also think it belongs in CSS
# [17:41] <SimonSapin> hober: 3 things: system inversion, system contrast, and user preferences
# [17:41] <SimonSapin> fantasai: forced inversion might be combined with a forced [...]
# [17:42] * Joins: jet (~junglecode@public.cloak)
# [17:44] * glazou2 starts thinking we need one or more mojitos to end this discussion
# [17:45] * sgalineau oh look, hober wants a watered-down resolution....
# [17:45] <SimonSapin> RESOLVED: We will add one or more high-contrast related media feature
# [17:45] <SimonSapin> florian: issue 8: we have a media feature do detect if scripting is disabled
# [17:46] <SimonSapin> florian: should we differentiate between scripting not supported, or disabled by the user?
# [17:46] <SimonSapin> (several): no.
# [17:47] <dbaron> RESOLVED: we won't distinguish between "UA doesn't support scripting" and "scripting is supported but turned off"
# [17:47] <SimonSapin> florian: We’re trying to break apart media types into media feature, it would be good to do so with input (mouse, touch, ...)
# [17:47] <fantasai> mouse: none | yes | awkward
# [17:47] <SimonSapin> florian: We need moar things.
# [17:48] <plinss> http://www.w3.org/TR/view-mode/
# [17:49] * plh refrains from proposing a "finger" media type
# [17:49] <SimonSapin> florian: Issue 12: there’s a spec call View Mode, in REC. Has media features to detect full screen, borderless window, etc. Written for widgets, ignored for a while, but could be relevant to browser-based OSes
# [17:49] <SimonSapin> Clilley: Is it ignored because nobody likes widgets?
# [17:49] <SimonSapin> plinss: we looked at it, it was controversial…
# [17:50] <SimonSapin> florian: seems relevant. Do we let it die and develop something new? Or pull it into MQs?
# [17:50] <SimonSapin> plh: marcos also has things
# [17:51] <plh> http://w3c.github.io/manifest/#display-member
# [17:52] <SimonSapin> zcorpan: there’s a pseudo-class for Fullscreen
# [17:53] <SimonSapin> florian: View Mode semantics are a bit richer
# [17:53] <zcorpan> http://fullscreen.spec.whatwg.org/#:fullscreen-pseudo-class
# [17:53] * hober sgalineau: http://w3cmemes.tumblr.com/post/76437924728/
# [17:54] <plh> http://w3c.github.io/manifest/#display-modes
# [17:54] * Quits: shepazu (schepers@public.cloak) (Client closed connection)
# [17:54] * Joins: shepazu (schepers@public.cloak)
# [17:55] * sgalineau it's nearly pastis time
# [17:55] <SimonSapin> RESOLVED: close issue 12, no change
# [17:55] <SimonSapin> plinss: we’re done for the day
# [17:55] <glazou2> <adjourn>
# [17:55] * Quits: glazou (~glazou@public.cloak) ("Page closed")
# [17:55] * Quits: glazou2 (~glazou2@public.cloak) ("Page closed")
# [17:55] * Quits: gregwhitworth (~gregwhitworth@public.cloak) ("Page closed")
# [17:59] * Quits: shepazu (schepers@public.cloak) ("is probably traveling...")
# [17:59] * Joins: shepazu (schepers@public.cloak)
# [17:59] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [18:02] * Quits: Rossen_ (~Rossen@public.cloak) (Ping timeout: 180 seconds)
# [18:04] * Quits: plh (plehegar@public.cloak) ("Leaving")
# [18:07] * Quits: SteveZ (~SteveZ@public.cloak) (Ping timeout: 180 seconds)
# [18:07] * Quits: jet (~junglecode@public.cloak) (jet)
# [18:07] * Quits: shans__ (~shans@public.cloak) (Ping timeout: 180 seconds)
# [18:08] * Quits: ikilpatrick (~ikilpatrick@public.cloak) (Ping timeout: 180 seconds)
# [18:08] * Quits: Clilley (~Clilley@public.cloak) (Ping timeout: 180 seconds)
# [18:08] * Quits: florian (~florian@public.cloak) (Ping timeout: 180 seconds)
# [18:09] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [18:09] * Quits: dbaron (~dbaron@public.cloak) (Ping timeout: 180 seconds)
# [18:15] * leaverou_away is now known as leaverou
# [18:35] * Joins: lmclister (~lmclister@public.cloak)
# [18:37] <Zakim> dbaron, you asked to be reminded at this time to go home
# [18:39] * Joins: eliezerb (~Eliezer@public.cloak)
# [18:40] * Quits: eliezerb (~Eliezer@public.cloak) ("Leaving")
# [18:45] * Quits: koji (~koji@public.cloak) ("Leaving...")
# [18:47] * Joins: eliezerb (~Eliezer@public.cloak)
# [18:47] * Quits: eliezerb (~Eliezer@public.cloak) ("Leaving")
# [18:47] * Joins: eliezerb (~Eliezer@public.cloak)
# [18:49] * Quits: tommyjtl_ (~tommyjtl@public.cloak) (Ping timeout: 180 seconds)
# [18:53] * Zakim excuses himself; his presence no longer seems to be needed
# [18:53] * Parts: Zakim (zakim@public.cloak) (Zakim)
# [18:54] * Joins: lmcliste_ (~lmclister@public.cloak)
# [18:54] * Quits: lmclister (~lmclister@public.cloak) (Client closed connection)
# [18:55] * Joins: lmclister (~lmclister@public.cloak)
# [18:55] * Quits: lmcliste_ (~lmclister@public.cloak) (Client closed connection)
# [18:55] * Joins: tommyjtl (~tommyjtl@public.cloak)
# [18:59] * Joins: dauwhe (~dauwhe@public.cloak)
# [19:02] * Quits: tommyjtl (~tommyjtl@public.cloak) (Ping timeout: 180 seconds)
# [19:06] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [19:07] * Joins: jcraig (~jcraig@public.cloak)
# [19:14] * Quits: eliezerb (~Eliezer@public.cloak) ("Leaving")
# [19:18] * leaverou is now known as leaverou_away
# [19:20] * Joins: jet (~junglecode@public.cloak)
# [19:45] * Quits: Bert (bbos@public.cloak) (Ping timeout: 180 seconds)
# [19:54] * Joins: lmcliste_ (~lmclister@public.cloak)
# [19:54] * Quits: lmclister (~lmclister@public.cloak) (Client closed connection)
# [19:56] * Joins: adenilson (~anonymous@public.cloak)
# [19:58] * Joins: lmclister (~lmclister@public.cloak)
# [19:58] * Quits: lmcliste_ (~lmclister@public.cloak) (Client closed connection)
# [20:00] * Joins: dauwhe (~dauwhe@public.cloak)
# [20:02] * Joins: dsinger (~dsinger@public.cloak)
# [20:03] * Quits: dsinger (~dsinger@public.cloak) (dsinger)
# [20:07] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [20:08] * Joins: Bert (bbos@public.cloak)
# [20:30] * Quits: lmclister (~lmclister@public.cloak) (Client closed connection)
# [20:30] * Joins: lmcliste_ (~lmclister@public.cloak)
# [20:51] * Quits: lmcliste_ (~lmclister@public.cloak) (Client closed connection)
# [20:51] * Joins: lmclister (~lmclister@public.cloak)
# [20:54] * Quits: jcraig (~jcraig@public.cloak) (jcraig)
# [20:55] * Joins: jcraig (~jcraig@public.cloak)
# [21:19] * Quits: jcraig (~jcraig@public.cloak) (jcraig)
# [21:23] * Joins: jcraig (~jcraig@public.cloak)
# [22:18] * Quits: jcraig (~jcraig@public.cloak) (jcraig)
# [22:19] * Joins: jcraig (~jcraig@public.cloak)
# [22:22] * Joins: dauwhe (~dauwhe@public.cloak)
# [22:27] * Joins: lmcliste_ (~lmclister@public.cloak)
# [22:27] * Quits: lmclister (~lmclister@public.cloak) (Client closed connection)
# [22:55] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [22:58] * Quits: jcraig (~jcraig@public.cloak) (Ping timeout: 180 seconds)
# [23:55] * Joins: dauwhe (~dauwhe@public.cloak)
# Session Close: Tue Sep 09 00:00:00 2014

The end :)