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