00:25:52 <miketaylr> miketaylr has joined #css
00:36:07 <dbaron> dbaron has joined #css
03:17:55 <miketaylr> miketaylr has joined #css
03:24:28 <miketaylr> miketaylr has joined #css
04:00:57 <Liam> Liam has joined #css
05:08:53 <tantek> tantek has joined #css
06:36:00 <drublic> drublic has joined #css
06:50:11 <ayanes> ayanes has joined #css
07:10:34 <drublic> drublic has joined #css
08:50:00 <Ms2ger> Ms2ger has joined #css
09:51:15 <SimonSapin> SimonSapin has joined #css
10:01:14 <tantek> tantek has joined #css
10:47:37 <dbaron> dbaron has joined #css
11:19:38 <SimonSapin> SimonSapin has joined #css
11:37:00 <dbaron> dbaron has joined #css
15:56:27 <RRSAgent> RRSAgent has joined #css
15:56:27 <RRSAgent> logging to http://www.w3.org/2012/07/18-css-irc
15:56:29 <trackbot> RRSAgent, make logs member
15:56:29 <Zakim> Zakim has joined #css
15:56:31 <trackbot> Zakim, this will be Style_CSS FP
15:56:31 <Zakim> ok, trackbot, I see Style_CSS FP()12:00PM already started
15:56:32 <trackbot> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
15:56:32 <trackbot> Date: 18 July 2012
15:56:43 <ChrisL> rrsagent, make logs public
15:56:56 <Zakim> -??P8
15:57:14 <arron> zakim, 253 is me
15:57:14 <Zakim> sorry, arron, I do not recognize a party named '253'
15:57:32 <Zakim> +??P12
15:57:42 <florian> Zakim, I am ??P12
15:57:42 <Zakim> +florian; got it
15:57:53 <Zakim> -rbetts
15:58:02 <Zakim> +[Microsoft]
15:58:10 <Zakim> +??P15
15:58:11 <Zakim> +rbetts
15:58:23 <arron> Zakim: Who is on the phone?
15:58:33 <Zakim> +ChrisL
15:59:02 <glenn> zakim, who's noisy?
15:59:12 <Zakim> glenn, listening for 10 seconds I could not identify any sounds
15:59:34 <rbetts> same
15:59:42 <glenn> i'm also hearing clicking
15:59:42 <Zakim> -ChrisL
15:59:46 <rbetts> better now
15:59:47 <glenn> it went away
15:59:48 <sylvaing> that was intense
16:00:08 <glenn> zakim, ??p15 is me
16:00:08 <Zakim> +glenn; got it
16:00:11 <antonp> antonp has joined #css
16:00:16 <Zakim> +[Mozilla]
16:00:22 <Zakim> +ChrisL
16:00:32 <dbaron> Zakim, [Mozilla] has dbaron, fantasai, jdaggett, jkew
16:00:33 <Zakim> +dbaron, fantasai, jdaggett, jkew; got it
16:01:06 <Zakim> +stearns
16:01:10 <Zakim> +antonp
16:01:37 <antonp> ScribeNick: antonp
16:01:43 <Zakim> +Bert
16:01:59 <antonp> Extra agenda item: css3-color errata
16:02:11 <antonp> will be item 1.5
16:02:23 <Zakim> - +1.253.307.aaaa
16:03:01 <tabatkins_> tabatkins_ has joined #css
16:03:10 <Zakim> + +1.253.307.aabb
16:03:41 <arron> Zakim: aabb is me
16:03:55 <jdaggett> jdaggett has joined #css
16:03:57 <antonp> Zakim, who is here?
16:03:57 <Zakim> On the phone I see florian, [Microsoft], glenn (muted), rbetts, [Mozilla], ChrisL, stearns, antonp, Bert, +1.253.307.aabb
16:04:00 <Zakim> [Mozilla] has dbaron, fantasai, jdaggett, jkew
16:04:00 <Zakim> On IRC I see jdaggett, tabatkins_, antonp, Zakim, RRSAgent, rbetts, ChrisL, florian, arron, glenn, shepazu, krit1, jet_, jarek, dbaron, SimonSapin, tantek, Ms2ger, drublic, Liam,
16:04:02 <Zakim> ... macpherson, dglazkov, isherman, gsnedders, stearns, trackbot, TabAtkins, alexmog, vhardy, logbot, sylvaing, heycam, shans, CSSWG_LogBot, paul___irish, krijnhuman, hober,
16:04:05 <Zakim> ... fantasai, Bert, decadance, plinss, Hixie, arronei
16:04:32 <arno> arno has joined #css
16:04:56 <Zakim> +tabatkins_
16:04:57 <bradk> bradk has joined #css
16:05:00 <antonp> ACTION: Chris to follow up on invited expert issue: ask about employment status
16:05:00 <trackbot> Created ACTION-484 - Follow up on invited expert issue: ask about employment status [on Chris Lilley - due 2012-07-25].
16:05:25 <antonp> ITEM: css3-color errata
16:05:48 <antonp> new comment: css3-color says don't use system colors, use something else
16:05:57 <antonp> It's a change to a non-normative note
16:06:15 <ChrisL> http://lists.w3.org/Archives/Public/www-style/2012Jul/0423.html
16:06:18 <Zakim> +bradk
16:06:21 <Zakim> +[Apple]
16:06:24 <hober> Zakim, Apple has me
16:06:49 <Zakim> +hober; got it
16:07:09 <antonp> fantasai: it makes sense
16:07:31 <antonp> dbaron: are we still pushing the 'appearance' property forward? I thought we weren't
16:07:40 <antonp> ChrisL: the note says that it's been deprecated
16:08:04 <Zakim> +[Microsoft.a]
16:08:10 <JohnJansen> JohnJansen has joined #css
16:08:17 <antonp> ChrisL: the change deletes the entire note, and says that it's deprecated
16:08:23 <glenn> q+
16:08:30 <JohnJansen> zakim, microsoft has JohnJansen
16:08:30 <Zakim> +JohnJansen; got it
16:08:33 <antonp> ChrisL: it removes the admonition to use the 'appearance' property
16:08:42 <ChrisL> ack glnn
16:08:49 <ChrisL> ack glenn
16:09:08 <glenn> zakim, unmute me
16:09:08 <Zakim> glenn was not muted, glenn
16:09:47 <antonp> glenn: avoiding having specs referring to future features would be a good idea
16:09:53 <glenn> ack glenn
16:09:59 <antonp> RESOLUTION: accept ChrisL's suggested change
16:10:01 <Zakim> +SteveZ
16:10:04 <fantasai> fantasai: There was also an errat on currentColor that's missing
16:10:07 <florian> http://lists.w3.org/Archives/Public/www-style/2012Mar/0327.html
16:10:11 <ChrisL> rrsagent, here
16:10:11 <RRSAgent> See http://www.w3.org/2012/07/18-css-irc#T16-10-11
16:10:17 <Zakim> +??P57
16:10:17 <antonp> ITEM: DOM issue
16:10:24 <antonp> florian: function called removeProperty
16:10:33 <antonp> ... not defined what it returns
16:10:50 <SteveZ> SteveZ has joined #css
16:10:53 <antonp> ... we propose it returns same thing as getPropertyValue
16:11:21 <antonp> dbaron: our implementation does something relevant
16:11:35 <antonp> ChrisL: sounds like change would be compatible with at least 2 implementations
16:11:42 <antonp> ChrisL: any objections?
16:11:58 <dbaron> s/does something relevant/does that, i.e., calls getPropertyValue(), removes the property, and returns what getPropertyValue() returned before removing the property/
16:12:05 <antonp> ??: should we check implementations first?
16:12:14 <glenn> can someone file a bug against cssom to record this?
16:12:22 <antonp> florian: I don't see what other behaviours could be useful
16:12:28 <antonp> s/??/sylvaing 
16:12:49 <glenn> ok, i will do so
16:12:54 <antonp> RESOLVED: accept the proposal from florian
16:13:10 <dbaron> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cbody%20style%3D%22color%3A%20blue%22%3E%0A%3Cscript%3E%0Avar%20s%20%3D%20document.body.style%3B%0Adocument.write(s.removeProperty(%27color%27))%3B%0A%3C%2Fscript%3E
16:13:12 <dbaron> is a testcase
16:13:13 <antonp> Bert: I think that's what the recommendation already says
16:13:21 <antonp> ... the current DOM spec
16:13:27 <antonp> florian: Oh?
16:13:41 <antonp> ... maybe I missed that.
16:13:52 <antonp> dbaron: lots of things in DOM spec didn't get into CSS
16:13:54 <glenn> DOM-2 currently says "Returns the value of the property if it has been explicitly set for this declaration block. Returns the empty string if the property has not been set or the property name does not correspond to a known CSS property."
16:13:59 <Bert> -> http://www.w3.org/TR/2000/REC-DOM-Level-2-Style-20001113/css.html DOM 2 style
16:14:11 <glenn> so it doesn't exactly say return what getPropertyValue() returns
16:14:11 <antonp> ChrisL: since DOM-2 Style doesn't have much life expectancy, so my opinion is to put it in CSS
16:14:26 <antonp> dbaron: I'm happy to have it in CSS
16:15:33 <dbaron> well, actually, it's a copy-paste with a bugfix
16:16:11 <antonp> RESOLVED: florian to file CSSOM bug and glenn to update CSSOM spec
16:16:12 <alexmog_> alexmog_ has joined #css
16:16:29 <antonp> ITEM: css-device-adaptation
16:16:41 <antonp> florian: descriptor called 'resolution'
16:16:55 <antonp> ... introduced to be an equivalent to ??? dip
16:16:58 <antonp> ... introduced to be an equivalent to ??? dpi
16:17:33 <antonp> florian: we introduced resolution to be compatible with lots of things, but we think it's actually harmful because it tricks people into thinking it's good to use it
16:18:26 <florian> equivalent to target-densityDpi. Generally useless, only supported in the android version of webkit (not including chrome)
16:18:29 <fantasai> alexmog_: Did you get a chance to look at http://lists.w3.org/Archives/Public/www-style/2012Jul/0385.html ?
16:18:32 <Zakim> +[Microsoft.aa]
16:18:44 <alexmog_> zakim, microsoft.aa is me
16:18:44 <Zakim> +alexmog_; got it
16:18:51 <tabatkins_> FYI, WebKit also returns the getPropertyValue() value from removeProperty().
16:19:23 <antonp> RESOLVED: drop 'resolution' descriptor from css-device-adaptation
16:19:34 <Zakim> -??P57
16:19:38 <antonp> ACTION: florian to make that edit
16:19:38 <trackbot> Created ACTION-485 - Make that edit [on Florian Rivoal - due 2012-07-25].
16:19:44 <Zakim> +[Microsoft.aa]
16:19:47 <alexmog_> fantasai: yes, it seems reasonable
16:19:57 <antonp> ITEM: default font features
16:20:01 <jdaggett> http://lists.w3.org/Archives/Public/www-style/2012Jul/0155.html
16:20:01 <jdaggett> http://lists.w3.org/Archives/Public/www-style/2012Jul/0184.html
16:20:01 <jdaggett> http://lists.w3.org/Archives/Public/www-style/2012Jul/0377.html
16:20:37 <antonp> jdaggett: we've talked about the way font features are supported. Spec all along has wording that turns things like ligatures on by default
16:20:54 <antonp> ... When I was looking at implementations, I noticed that they were using two different modes
16:21:01 <antonp> ... default mode has no default font features
16:21:28 <antonp> ... enabling any value other than normal for a setting would flip the mode, and other settings would be change too
16:21:38 <jdaggett> http://people.mozilla.org/~jdaggett/tests/simplekerningligs.html
16:21:38 <jdaggett> http://people.mozilla.org/~jdaggett/images/fftrunk-ie10-chrome-defaults.png
16:21:46 <antonp> ... odd model; features pop on based on whether some random property is used or not
16:22:00 <antonp> ... test case shows rendering in different browsers
16:22:11 <antonp> ... there are distinct variations depending upon browser
16:22:13 <Rossen> Rossen has joined #css
16:22:27 <antonp> ... look at the 't' and 'o'; kerning is on in Fx but not in Wk or IE
16:22:38 <Rossen> Zakim, Microsoft has me
16:22:38 <Zakim> +Rossen; got it
16:22:47 <antonp> ... if you turn on a random feature, kerning gets enabled
16:23:14 <antonp> ... <jdaggett describes more examples>
16:23:38 <antonp> jdaggett: Microsoft said that this is a performance problem, and that we shouldn't turn on features by default
16:24:01 <jdaggett> Existing def'n of font-kerning:
16:24:01 <jdaggett>   font-kerning : auto | normal | none
16:24:01 <jdaggett> Additions needed to support "user agent decides defaults" behavior:
16:24:01 <jdaggett>   font-feature-settings : auto | normal | <feature-tag-value>#
16:24:02 <jdaggett>   font-variant : auto | normal | ...
16:24:02 <jdaggett>   font-variant-ligatures : auto | normal | [ <common-lig-values> || <discretionary-lig-values> ... ]
16:24:30 <antonp> jdaggett: would need to have an additional 'auto' value, meaning that UAs could do whatever they want
16:25:05 <antonp> ... Not a good authoring model; too magic
16:25:41 <antonp> ChrisL: re performance: I saw an assertion that it slowed down, and another assertion that the slow-down was due to something else.  Which is correct?
16:26:19 <antonp> jdaggett: Sergey (Microsoft) says there's a hit, but I think it's not major
16:26:41 <antonp> ??: failing to pay attention to default features makes browsers non-compliant
16:26:56 <antonp> jdaggett: Sergey doesn't want IE to be non-compliant
16:27:04 <dbaron> s/??/glenn/
16:27:19 <bradk> ("bla" on) is the new 'zoom:1' for mode switching.
16:27:20 <antonp> jdaggett: I dont' think there's any wording in the OpenType spec saying that you're non-compliant if you don't use the settings
16:27:44 <antonp> florian: I agree with jdaggett, better to have a good default
16:27:47 <SteveZ> +1 for current default
16:28:09 <antonp> ChrisL: I agree, if authors could switch it off via stylesheet then we get best of both worlds
16:28:38 <antonp> ChrisL: font designers have designed the font knowing that it works well with certain settings
16:28:47 <antonp> ... better to trust what the font designer thought.
16:29:18 <antonp> jdaggett: we make the problem more difficult if authors are given ability to make lots of feature switches
16:29:37 <glenn> http://www.microsoft.com/typography/otspec/features_ko.htm#liga
16:29:38 <antonp> ... within MS, is it just Sergey, or are there other people worried about performance
16:29:45 <antonp> sylvaing: performance is always an issue
16:29:54 <glenn> says "UI suggestion: This feature serves a critical function in some contexts, and should be active by default."
16:30:09 <ChrisL> would be interested to hear what Si Daniels from Microsoft Typography thinks about this
16:30:18 <antonp> ... recent raw memories about a past migration to a different tech that changed font layout
16:30:30 <glenn> so a number of registered OT features says they "should" be active by default
16:30:51 <antonp> sylvaing: using an 'auto' magic value is ok, but prefer to reach an agreement on concrete behaviour
16:31:11 <antonp> ... Fx proves that perf is ok, but we'd like more time to understand impact
16:31:36 <antonp> sylvaing: maybe we can recover from the perf hit, but we are cautious because it requires further work
16:31:47 <antonp> jdaggett: would you object to spec as it currently is/
16:32:06 <antonp> sylvaing: if this is about going to CR, we would probably want to object
16:32:19 <antonp> ... we want to convince Sergey first
16:32:29 <Zakim> - +1.253.307.aabb
16:32:35 <fantasai> jdaggett^: you can recover some perf by checking if the font uses features, and if not, go with the fast path
16:32:49 <antonp> ??: next step is to get an apples to applies comparison
16:32:59 <antonp> sylvaing: good to have test case to test against
16:33:20 <antonp> ChrisL: no objections at this stage, general agreement to go forward, but want a test case to test agains
16:33:38 <dbaron> s/ChrisL:/ChrisL: in summary,/
16:33:48 <JohnJansen> s/??/JohnJansen
16:33:48 <antonp> szilles: important that default is default, but that there's a way of getting rid of things.  'none' value?
16:34:13 <glenn> +1 for a 'none' value
16:34:22 <antonp> jdaggett: we need to finish spec before test cases
16:34:38 <antonp> ChrisL: I disagree: the sooner we have tests the better, since the spec isn't finished without them
16:34:50 <antonp> jdaggett: tests aren't ready for submission
16:34:59 <alexmog_> fantasai -- reread your proposal on table captions, still agree
16:35:05 <antonp> ... I wouldn't start to put test cases into normal W3 form until LC
16:35:12 <fantasai> alexmog_: good, I'll close that issue pending edits, then :)
16:35:19 <antonp> ... I don't see there would be a big lag between LC and test cases
16:35:48 <antonp> ChrisL: My personal opinion: I find it easier to understand spec when there are tests, and easier to spot problems.  Can be easier to get test out before LC
16:36:28 <stearns> +1 on more test cases sooner
16:36:37 <Ms2ger> What he said
16:36:37 <antonp> JohnJansen: We're ok in principal, but want test cases to test with
16:36:47 <fantasai> s/principal/principle/
16:37:17 <antonp> <conflicting opinions about need for test cases sooner rather than later?
16:37:21 <antonp> <conflicting opinions about need for test cases sooner rather than later>
16:37:38 <antonp> szilles: where do we put incoming test cases that haven't been verified?
16:38:12 <antonp> ChrisL: can you submit any tests you already have?
16:38:15 <stearns> test cases that aren't ready for official submission can go into an "incoming" folder
16:38:26 <Zakim> +[Microsoft.aaa]
16:38:29 <arronei> zakim, microsoft has me
16:38:29 <Zakim> +arronei; got it
16:38:40 <antonp> ChrisL: easier for people to contribute tests if we can see what's already been done
16:38:51 <antonp> jdaggett: half of the problem is designing the font, not the test
16:38:57 <antonp> jdaggett: we have some fonts, but we will need more
16:39:21 <antonp> ChrisL: I understood that Tal Lemming was designing some fonts; would be good to see them
16:39:52 <antonp> ACTION: jdaggett to supply fonts and tests
16:39:52 <trackbot> Created ACTION-486 - Supply fonts and tests [on John Daggett - due 2012-07-25].
16:40:29 <antonp> ChrisL: no resolution needed because it's not a change
16:40:37 <antonp> glenn: how about a resolution on the 'none' value?
16:40:44 <antonp> jdaggett: I'll think about it and write it up
16:41:55 <antonp> ITEM: flexbox issues
16:41:57 <fantasai> http://dev.w3.org/csswg/css3-flexbox/issues-lc-2012
16:42:08 <fantasai> http://dev.w3.org/csswg/css3-flexbox/issues-lc-2012#issue-10
16:42:10 <glenn> apache FOP recently added a complex text path and chose to make it enabled by default, with a means for user to disable it, i.e., an equivalent to 'none'
16:42:16 <antonp> fantasai: Change request we want to reject:
16:42:37 <antonp> ... <see e-mail>
16:43:00 <glenn> http://xmlgraphics.apache.org/fop/1.1rc1/complexscripts.html#Disabling+complex+scripts
16:43:36 <antonp> fantasai: We think it doesn't make sense to follow the flex flow of the item itself
16:43:53 <antonp> florian: What I understood makes me agree with fantasai 
16:44:23 <antonp> <szilles seeks clarification>
16:44:31 <antonp> ChrisL: any objections?
16:44:37 <antonp> RESOLUTION: reject change proposal
16:44:38 <fantasai> http://dev.w3.org/csswg/css3-flexbox/issues-lc-2012#issue-14
16:44:47 <antonp> fantasai: Issue 14
16:45:00 <fantasai> http://lists.w3.org/Archives/Public/www-style/2012Jul/0121.html
16:45:01 <antonp> ... <fantasai describes issue>
16:45:17 <antonp> fantasai: in Hamburg we decided that it should redo line breaking
16:45:37 <antonp> szilles: did Kenny give additional reasons why he wanted a change?
16:46:07 <antonp> fantasai: if you have a flexbox toolbar, don't have enough room, things flow into multiple line, if you want to collapse a set of items, you want to save that space
16:46:19 <antonp> florian: why not use visibility:hidden
16:46:27 <antonp> fantasai: that just makes it invisible; doesn't save space
16:46:38 <antonp> fantasai: if you want things on different lines, usually that's a semantic things
16:46:52 <antonp> ... so you wouldn't use flexbox's multiline support
16:47:04 <antonp> <szilles reasks his question>
16:47:07 <antonp> fantasai: no
16:47:15 <antonp> szilles: then I agree with the rejection
16:47:23 <antonp> RESOLUTION: reject the change proposal
16:47:30 <fantasai> http://dev.w3.org/csswg/css3-flexbox/issues-lc-2012#issue-4
16:47:39 <antonp> ITEM: open issue, #4
16:48:02 <antonp> fantasai: comment was that since order doesn't affect speech or tab order, why does it have a generic name?
16:48:16 <antonp> florian: Tab also objected to renaming
16:48:46 <antonp> Tab: we did all the renaming before LC, and we discussed this specific issue knowing the consequences
16:49:01 <antonp> Tab: I don't feel that the comment adds anything new
16:49:30 <antonp> fantasai: display-order and box-order weren't specifically rejected; we just straw-polled on 'order'
16:49:44 <antonp> ... and we hadn't decided on tab order, for example
16:50:03 <antonp> sylvaing: I don't understand why we're causingin people pain by renaming
16:50:20 <antonp> ... renaming is important, but it has to happen early in spec roadmap
16:50:39 <antonp> florian: irrelevant for flexbox; what's done is done.  What do we think about this spec/issue?
16:50:51 <antonp> sylvaing: I don't see a strong case for renaming
16:51:06 <antonp> Tab: there's not a strong case
16:51:27 <antonp> szilles: I think we should think about having a name freeze time that predates LC as a step in the process
16:51:36 <antonp> ... but I observe that this name change is relatively recent
16:51:53 <antonp> ... any name change probably needs a couple of months to smooth itself out
16:52:01 <JohnJansen> +1 to szilles on having a freeze to names that predates LC
16:52:11 <antonp> ... let's try to fix it so we don't do this in future, so that we can have those months
16:52:18 <sylvaing> +1 to szilles as well
16:52:20 <dbaron> I agree with Steve that we have to be able to revisit a decision two months after we make it.
16:52:39 <antonp> ChrisL: a way forward is to not change the name but have a note explaining why the name is what it is, and why there might be issues about it
16:52:49 <antonp> fantasai: that's not the issue; the spec is clear about what the property does
16:53:08 <antonp> ... I'm not going to object to anything, but this issue has been in the open for a while
16:53:29 <antonp> ChrisL: Will we make an exception for this one case?
16:53:44 <antonp> sylvaing: we don't have a new name!
16:53:59 <antonp> florian: if we change, we must change sooner not later
16:54:57 <antonp> fantasai: question would be: if we redid the straw poll, would people change their minds
16:55:09 <antonp> Tab: I wouldn't, but I would still be objecting
16:55:30 <antonp> fantasai: what's the rationale for rejecting the change proposal?
16:55:39 <antonp> Tab: small benefit, and too late in process
16:55:52 <antonp> fantasai: too late is the only good reason
16:55:59 <antonp> szilles: I agree with fantasai
16:56:22 <fantasai> http://dev.w3.org/csswg/css3-flexbox/issues-lc-2012#issue-17
16:56:26 <Bert> q+ to say "too late in the process" is not a good reason. It's WD and we did ask for comments...
16:56:36 <antonp> RESOLUTION: reject the change proposal for reason of being too late in the process
16:56:46 <Bert> q-
16:56:48 <antonp> ITEM: next issue
16:57:06 <dbaron> s/next issue/flexbox issue 17/
16:57:33 <antonp> Bert: "too late in process" is not a good reason on an WD
16:57:46 <Zakim> -ChrisL
16:58:53 <antonp> fantasai: please could everyone try to think about the issue for the next call
16:59:13 <antonp> alexmog: why is it even an issue?
16:59:31 <Zakim> -[Microsoft.a]
16:59:52 <antonp> Tab: I argue the other way; placeholders should "inherit" reasonable properties from their abspos
17:00:05 <antonp> fantasai: they dont' get padding or margin, why should they get 'order'?
17:00:13 <antonp> dbaron: does it concern painting order?
17:00:24 <antonp> Tab: that would be a separate question
17:00:26 <Zakim> -rbetts
17:00:52 <ChrisL> rrsagent, make minutes
17:00:52 <RRSAgent> I have made the request to generate http://www.w3.org/2012/07/18-css-minutes.html ChrisL
17:00:54 <antonp> alexmog: two adjacent abspos, is there one or two placeholders?
17:01:01 <antonp> ... does alignment apply?
17:01:03 <antonp> Tab: yes
17:01:08 <antonp> fantasai: I disagree
17:01:50 <dbaron> dbaron: I think that by default, nothing applies to the placeholder, and if you want something to, you should say so.
17:02:13 <antonp> haha
17:02:45 <drublic> drublic has joined #css
17:02:52 <fantasai> szilles: I think we should deal with 18 first, then 17
17:02:55 <Zakim> -tabatkins_
17:02:57 <Zakim> -[Microsoft]
17:02:57 <Zakim> -[Apple]
17:02:57 <Zakim> -[Mozilla]
17:02:58 <fantasai> antonp: I hate placeholders.
17:03:00 <Zakim> -Bert
17:03:00 <antonp> CONSENSUS: meeting closed
17:03:01 <fantasai> Meeting closed.
17:03:02 <Zakim> -[Microsoft.aa]
17:03:03 <Zakim> -SteveZ
17:03:04 <Zakim> -[Microsoft.aaa]
17:03:07 <Zakim> -stearns
17:03:09 <tabatkins_> Man, we'll never get to CR. ;_;
17:03:10 <Zakim> -alexmog_
17:03:13 <Zakim> -bradk
17:03:14 <Zakim> -antonp
17:03:17 <Zakim> -glenn
17:03:30 <fantasai> tabatkins_: yeah
17:03:42 <fantasai> tabatkins_: So, what was your rationale that wasn't "it's too late in the process"?
17:04:13 <Ms2ger> It's too late in the real world?
17:04:30 <fantasai> Ms2ger: note "process" is lower-case :)
17:04:35 <Bert> I think the argument is that the WG can't find any better name.
17:04:50 <Ms2ger> No
17:05:07 <Ms2ger> The argument is that flexbox properties have been renamed ten times too much already
17:05:14 <tabatkins_> I gave it in the call.  The benefit is arguable (I think 'order' is a great name). If we assume there's a benefit, it's very small.  The pain of changing names this late in the process outweighs the benefit.
17:05:17 <antonp> display-order might be more appropriate in one sense, but it looks like a longhand component property of display 
17:05:30 <antonp> Which makes it a bad choice IMO
17:06:06 <fantasai> I think Florian suggested 'visual-order' as an alternative, maybe that's better?
17:06:40 <fantasai> Bert: That is a better rationale to give
17:06:45 <jdaggett> jdaggett has joined #css
17:06:56 <alexmog_> if I was making a call right now to implement flexbox unprefixed, I would say wait for a while, naming can still change
17:07:04 <antonp> Yeah, visual-order is worth thinking about
17:07:05 <alexmog_> oh wait, we just have done that...
17:07:42 <alexmog_> "late in the process" is a valid argument, but lck of a better name is a stronger one
17:07:58 <tabatkins_> And with their powers combined...
17:08:11 <antonp> it's an invincible argument
17:08:18 <Zakim> disconnecting the lone participant, florian, in Style_CSS FP()12:00PM
17:08:19 <Zakim> Style_CSS FP()12:00PM has ended
17:08:19 <Zakim> Attendees were rbetts, +1.253.307.aaaa, florian, ChrisL, glenn, dbaron, fantasai, jdaggett, jkew, stearns, antonp, Bert, +1.253.307.aabb, tabatkins_, bradk, hober, JohnJansen,
17:08:19 <Zakim> ... SteveZ, [Microsoft], alexmog_, Rossen, arronei
17:08:25 <antonp> antonp has left #css
17:08:26 <alexmog_> "late" really menas that a change has to be really really awesome to be accepted
17:08:59 <tabatkins_> Exactly.  Please don't read "late" as "lol too late, pay more attention"
17:09:05 <alexmog_> on placeholders.... 
17:09:54 <alexmog_> earlier decisions on placeholers were based on the agreement that absolute positioned flex items doon
17:10:07 <alexmog_> ... don't have any meaningful use cases
17:10:36 <alexmog_> theh whateve is defined for absolute flex items needs to be definite and simple to implement
17:10:49 <tabatkins_> Yes.
17:11:01 <alexmog_> placeholders with no properties whatsoever IMO are best
17:11:05 <alexmog_> no order or alignment
17:11:17 <fantasai> that's what Mozilla implements, too
17:11:26 <fantasai> although bz says it would be easy to make it accept 'order'
17:11:54 <alexmog_> of course it is easy. alignment is easy too. just why we care???
17:11:56 <tabatkins_> I'm perfectly fine either way.
17:12:15 <alexmog_> we can even define that placeholders are zero size and are all at (start, before)
17:12:27 <fantasai> and therfore don't affect layout :)
17:12:31 <alexmog_> yes
17:12:36 <fantasai> which solves #18
17:12:39 <tabatkins_> That's called "there's no such thing as placeholders, tables are an aberration".
17:12:50 <fantasai> http://lists.w3.org/Archives/Public/www-style/2012Jul/0419.html
17:13:17 <alexmog_> note that with the latest change to how text wrappers work, it may be reasonable
17:13:20 <fantasai> looks like Proposal A in Kenny's email
17:13:38 <tabatkins_> Yes, it is.
17:13:53 <fantasai> btw, any suggestions on where to put the text in http://lists.w3.org/Archives/Public/www-style/2012Jul/0385.html ?
17:13:56 <alexmog_> before,  abspos element in the middle of text would behave just as if it was in the middle of that text anywhere
17:15:00 <tabatkins_> fantasai: At the end of 4.0.
17:15:45 <alexmog_> now, abspos elements split text blocks... could just as well get collected at a random place, like table captions...
17:16:41 <tabatkins_> I'm fine with anything reasonably consistent.  I was trying to line up with the model suggested by table layout, but if we'd prefer to ignore that as a mistake and just say that complex layouts don't play with well abspos auto positioning, I'm fine with that as well.
17:16:42 <alexmog_> (but don't take this too seriously, I don't think I actually like that more than plain vanilla placeholders with no properties propagated to them)
17:19:08 <fantasai> is the static position of an abspos a point or a box?
17:19:50 <arronei> it should be a point.
17:19:51 <fantasai> http://www.w3.org/TR/CSS21/visudet.html#abs-non-replaced-width
17:20:00 <fantasai> There's different positions for left and right
17:20:03 <fantasai> so maybe it's a line segment
17:20:04 <fantasai> :)
17:21:44 <arronei> Maybe its a line segment that is a point.
17:22:13 <fantasai> arronei: that would make the left and right static positions identical, which they are not in 10.3.7
17:23:17 <arronei> so where is the definition of line segment?
17:23:25 <fantasai> in your math texbook
17:23:31 <fantasai> *textbook
17:23:36 <fantasai> ?
17:23:56 <arronei> I was worried we may have our own definition of line segment in CSS somewhere
17:24:05 <fantasai> heh, no
17:24:14 <fantasai> we do define the sign of zero
17:24:24 <fantasai> as being not negative
17:24:31 <fantasai> (although we don't say whether it's positive or not)
17:24:51 <arronei> Yeah which I still have a strong opinion of that
17:24:57 <fantasai> ?
17:25:26 <arronei> -0 is negative, 0 is not negative and not positive, +0 is positive
17:25:43 <arronei> that's at least how atleat 10 people on my team have thought about it.
17:25:50 <fantasai> heh
17:25:52 <fantasai> well
17:26:40 <arronei> different issue though, lets get back to the "point", the abspos point.
17:26:42 <tabatkins_> Two zeros arent' enough for you?
17:27:15 <fantasai> right, so
17:27:30 <fantasai> if the "hypothetical box" in Chapter 10 is made to be the flex container
17:28:26 <fantasai> then the effect is the same as having it be a point placed in the start head corner
17:28:29 <fantasai> yes?
17:28:41 <arronei> yes that is what I would think
17:28:55 <fantasai> Ok, so that's proposal A
17:29:31 <fantasai> Proposal B is to define it as halfway between the margin edges off the two flex items its between
17:29:43 <fantasai> but that doesn't say what the behavior is at the edges
17:30:14 <fantasai> Proposal C is to make each abspos placeholder a flex item
17:30:21 <tabatkins_> He elaborates (it's what I tried to do earlier, where it depends on the justify-content)
17:30:33 <fantasai> B and C have the issue of, do 'order' and/or 'align-self' have an effect on the placeholder
17:30:52 <tabatkins_> B has the further problem of actually being work, when this is probably a non-issue.
17:31:40 <fantasai> yeah
17:32:23 <arronei> arronei has joined #css
17:32:29 <arronei> 'order' I don't think would either
17:33:21 <arronei> Yeah I think "A" makes more sense.
17:34:18 <tabatkins_> It just means that we're abandoning the precedent set by tables, and killing any possible usefulness of auto positioning.
17:34:28 <fantasai> Spec prose would just be then "The hypothetical box used to calculate the static position of an abspos box corresponds to the content-box of the flex container."
17:34:31 <fantasai> ?
17:34:57 <fantasai> tabatkins_: if we're going to make it useful, we should actually make it useful. Right now it's half-assed.
17:36:03 <tabatkins_> I'm not objecting.  Just laying the consequences out fully. ^_^
17:36:39 <arronei> I think this is an issue we should really target in the next level if we think its important.
17:36:57 <fantasai> I can't think of a good use case.
17:37:07 <fantasai> The ones people brought up seem to make more sense by putting the abspos inside a flex item
17:37:12 <arronei> I can't either at the moment.
17:37:52 <fantasai> I think it's more likely that authors will be annoyed that abspos elements take up space than that they'll be annoyed it sort-of-kind-of follows its would-be flex position
17:38:02 <fantasai> s/it/it doesn/t
17:40:18 <arronei> So I think we are settled on "A" for the moment.
17:40:25 <fantasai> You and I are, anyway :)
17:40:30 <fantasai> tabatkins_, alexmog_ ?
17:40:42 <tabatkins_> Don't particular care, but let me ping ojan and tony.
17:53:35 <alexmog_> ... sorry wasn't looking at IRC for a while...
17:54:55 <alexmog_> if "A" means the container is the auto position, I am personaly fine with that
17:55:36 <alexmog_> I think the placeholder is marginally more useful though, and more consistent with abspos elsewhere (e.g. grid)
17:56:07 <alexmog_> both us and mozilla already implement placeholders in some way, so it is not more work.
17:56:24 <alexmog_> but I would be ok either way
17:56:53 <alexmog_> ... need to step out of office now...
17:59:37 <jet> jet has joined #CSS
17:59:43 <tabatkins_> Ojan and Tony are okay with the change.
18:00:47 <arno> arno has joined #css
18:18:53 <arno> arno has joined #css
18:31:59 <tantek> tantek has joined #css
18:38:01 <leaverou> leaverou has joined #css
18:44:38 <fantasai> tabatkins_ , alexmog_ : So if we're agreed on Proposal A, how about I send mail to www-style, update the DoC, and edit that in
18:44:53 <fantasai> tabatkins_, alexmog_ : and then we can try to close it with the WG next week?
19:04:28 <tabatkins_> fantasai: Yes, sounds good.
19:06:54 <fantasai> tabatkins_: proposed edit: replace 4.1 with a paragraph:
19:07:03 <fantasai> 	The hypothetical box used to calculate the <i>static position</i>
19:07:03 <fantasai> 	of an absolutely-positioned flex item corresponds to
19:07:03 <fantasai> 	the content-box of the flex container.
19:07:03 <fantasai> 	As in block layout, the absolutely-positioned box has no effect
19:07:03 <fantasai> 	on the layout of surrounding content.
19:07:09 <fantasai> (with appropriate link to 2.1
19:07:59 <tabatkins_> That should have an explanation in English that this means the auto position is the start/head corner of the flex container.
19:08:36 <fantasai> lol
19:08:38 <fantasai> ok
19:10:22 <fantasai> Add
19:10:23 <fantasai> 	(This effectively defines the <i>static position</i> as
19:10:24 <fantasai> 	the head start content-box corner of the flex container.)
19:10:25 <fantasai> ?
19:14:22 <fantasai> tabatkins_: ^
19:14:38 <Zakim> Zakim has left #css
19:18:52 <krit> krit has joined #css
20:01:32 <tantek> tantek has joined #css
20:02:35 <Mhz> Mhz has joined #css
20:03:14 <tantek> tantek has joined #css
20:04:28 <Mhz> Mhz has left #css
20:25:45 <tabatkins_> fantasai: Sounds fine.
20:53:24 <jet> jet has joined #CSS
20:58:12 <leaverou> leaverou has joined #css
21:01:04 <jet> jet has joined #CSS
21:29:56 <leaverou> leaverou has joined #css
21:31:46 <leaverou> leaverou has joined #css
21:51:14 <leaverou_> leaverou_ has joined #css
22:08:27 <dbaron> dbaron has joined #css
22:12:58 <arno> arno has joined #css
22:15:37 <krit> krit has joined #css
22:17:13 <krit1> krit1 has joined #css
22:17:22 <jwir3> jwir3 has joined #css
22:33:36 <jdaggett> jdaggett has joined #css
22:37:45 <krit> krit has joined #css
23:11:35 <arno> arno has joined #css