16:26:42 <RRSAgent> RRSAgent has joined #css
16:26:42 <RRSAgent> logging to http://www.w3.org/2012/01/11-css-irc
16:26:46 <glazou> Zakim, this will be Style
16:26:46 <Zakim> ok, glazou; I see Style_CSS FP()12:00PM scheduled to start in 34 minutes
16:26:52 <glazou> rrsagent, make logs public
16:30:53 <nimbu> apologies cant maek it to the meeting, will be commuting
16:31:04 <glazou> noted nimbu
16:53:38 <dstorey> dstorey has joined #css
16:54:31 <Rossen> Rossen has joined #css
16:55:12 <smfr> smfr has joined #css
16:56:20 <glazou> Zakim, code?
16:56:20 <Zakim> the conference code is 78953 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), glazou
16:56:44 <Zakim> Style_CSS FP()12:00PM has now started
16:56:51 <Zakim> +??P17
16:57:00 <glazou> Zakim, ??P17 is me
16:57:00 <Zakim> +glazou; got it
16:57:21 <Zakim> +[Mozilla]
16:57:35 <dbaron> dbaron has joined #css
16:59:17 <Zakim> +plinss
16:59:23 <antonp> antonp has joined #css
16:59:54 <Zakim> +??P44
16:59:55 <Zakim> + +1.415.871.aaaa
16:59:55 <Zakim> +hober
16:59:56 <oyvind> oyvind has joined #css
17:00:03 <florianr> Zakim, I am ??P44
17:00:03 <Zakim> +florianr; got it
17:00:15 <tantek> Zakim, aaaa is tantek
17:00:15 <Zakim> +tantek; got it
17:00:20 <tantek> Zakim mute tantek
17:00:24 <tantek> Zakim, mute tantek
17:00:24 <Zakim> tantek should now be muted
17:00:29 <Zakim> +antonp
17:00:56 <Zakim> +[Microsoft]
17:00:59 <Zakim> + +1.215.286.aabb
17:01:00 <Zakim> +smfr
17:01:06 <JohnJansen> JohnJansen has joined #CSS
17:01:08 <Zakim> +stearns
17:01:10 <kimberly> kimberly has joined #css
17:01:12 <Zakim> +??P58
17:01:29 <Zakim> +??P61
17:01:33 <JohnJansen> Zakim, microsoft has JohnJansen
17:01:33 <Zakim> +JohnJansen; got it
17:01:52 <Zakim> +??P64
17:02:13 <glazou> Zakim, who is on the phone?
17:02:13 <Zakim> On the phone I see glazou, dbaron, plinss, florianr, tantek (muted), hober, antonp, [Microsoft], +1.215.286.aabb, smfr, stearns, ??P58, ??P61, ??P64
17:02:15 <Zakim> [Microsoft] has JohnJansen
17:02:20 <Rossen> Zakim, ??P61 has Rossen
17:02:20 <Zakim> +Rossen; got it
17:02:21 <fantasai> Zakim, ??P64 is fantasai
17:02:22 <Zakim> +fantasai; got it
17:02:31 <fantasai> zakim, mute fantasai
17:02:31 <Zakim> fantasai should now be muted
17:02:36 <danielweck> danielweck has joined #css
17:02:39 <kimberly> Zakim, +1.215.286.aabb is me
17:02:39 <Zakim> +kimberly; got it
17:02:52 <Zakim> +Bert
17:02:54 <glazou> Zakim, who is on the phone?
17:02:54 <Zakim> On the phone I see glazou, dbaron, plinss, florianr, tantek (muted), hober, antonp, [Microsoft], kimberly, smfr, stearns, ??P58, ??P61, fantasai (muted), Bert
17:02:57 <Zakim> ??P61 has Rossen
17:02:57 <Zakim> [Microsoft] has JohnJansen
17:03:06 <glazou> Zakim, ??P61 is Rossen 
17:03:06 <Zakim> +Rossen; got it
17:04:23 <fantasai> ScribeNick: fantasai
17:04:43 <fantasai> Daniel: Happy New Year everyone!
17:04:46 <fantasai> Daniel: Extra items?
17:04:51 <Rossen> HNY Daniel!
17:05:04 <glazou> http://lists.w3.org/Archives/Public/www-style/2012Jan/0034.html
17:05:05 <fantasai> Topic: Proposal about detecting JavaScript from Media Queries
17:05:18 <fantasai> Daniel: Florian said he is willing to add that to the editor's draft
17:05:36 <Zakim> +??P32
17:05:41 <fantasai> Florian: I do not want to add that for L3, but when considering L4 I think this is interesting both on its own merits and as a general trend of what I'm thinking about
17:05:46 <kojiishi> zakim, ??p32 is me
17:05:46 <Zakim> +kojiishi; got it
17:05:48 <fantasai> Florian: Usefulness described in ML
17:05:56 <fantasai> Florian: For L4, I was thinking to develop more media features
17:06:04 <fantasai> Florian: Currently we detect print as a media type
17:06:11 <fantasai> Florian: Doesn't work well because you can't be both print and screen
17:06:17 <fantasai> Florian: But some devices share aspects of both
17:06:32 <fantasai> Florian: Would be good to detect whether you are paged or not, screen can be refreshed or not,
17:06:40 <fantasai> Florain: detect whether there is a touch screen
17:06:56 <fantasai> Florian: This way can adapt layout for the device without knowing exactly what it is
17:07:15 <fantasai> Daniel: Other opinions?
17:07:19 <fantasai> fantasai: Sounds good to me
17:07:25 <stearns> +1 florian
17:07:27 <Zakim> +??P12
17:07:36 <TabAtkins> +lots
17:07:43 <Bert> q+ to ask if this isn't for CC/PP (UAProf) instead?
17:07:49 <fantasai> Kimberly: Certainly for ComCast devs, when we read the proposal, were very excited. A lot of interest amongst the dev community here
17:08:06 <fantasai> Anton: Someone mentioned NoScript on the mailing list
17:08:13 <tantek> sounds good to me also. (add js detection to media queries 4)
17:08:14 <fantasai> Anton: Can choose to run script on some domain, not others
17:08:32 <danielweck> Zakim, ??P12 is me
17:08:33 <Zakim> +danielweck; got it
17:08:44 <fantasai> Anton: Difficulty with CSS support statement that you either support script or you don't, not clear what it means
17:08:55 <nimbu> nimbu has joined #css
17:09:07 <fantasai> Anton: If I allow base domain to run scripts, but not third-party domains to run scripts, what then?
17:09:36 <tantek> I don't think a URL check is necessary for the common case.
17:09:49 <fantasai> Florian: Haven't thought about that. Maybe we choose yes or no for some scripts. Or maybe we have a finer distinction
17:09:51 <tantek> there are enough 3rd party script blockers that sites have to work without 3rd party scripts anyway
17:10:04 <fantasai> Bert: Wondering if this opens a can of worms.
17:10:10 <glazou> tantek: speak up !
17:10:11 <Zakim> + +1.206.324.aacc
17:10:13 <fantasai> Bert: Script is rather high level, but other things you could want
17:10:18 <sylvaing> sylvaing has joined #css
17:10:22 <fantasai> Bert: Might need a way to control the vocabulary
17:10:25 <tantek> q+ to comment on 3rd party scripts, CC/PP
17:10:38 <fantasai> Bert: Something called CCPP has a URL-based vocabulary and framework
17:10:43 <fantasai> Bert: Let's use that
17:10:46 <sylvaing> Zakim, who is on the phone
17:10:49 <Zakim> I don't understand 'who is on the phone', sylvaing
17:10:55 <sylvaing> Zakim, who is on the phone?
17:10:57 <Zakim> On the phone I see glazou, dbaron, plinss, florianr, tantek (muted), hober, antonp, [Microsoft], kimberly, smfr, stearns, ??P58, Rossen, fantasai (muted), Bert, kojiishi,
17:10:59 <Zakim> ... danielweck, +1.206.324.aacc
17:11:00 <arno> arno has joined #css
17:11:01 <Zakim> Rossen has Rossen
17:11:02 <Zakim> [Microsoft] has JohnJansen
17:11:04 <tantek> Zakim, unmute tantek
17:11:05 <Zakim> + +1.415.832.aadd
17:11:05 <fantasai> Daniel: Is that implemented in browsers?
17:11:05 <arno> arno has joined #css
17:11:09 <Zakim> tantek should no longer be muted
17:11:10 <fantasai> Bert: Some mobile browsers
17:11:12 <sylvaing> Zakim, aacc is sylvaing
17:11:12 <Zakim> +sylvaing; got it
17:11:30 <fantasai> Tantek: I think the 3rd party script case is, from dev standpoint, an edge case
17:11:45 <fantasai> Tantek: Rather than presenting as a problem, would like to know why we care?
17:11:57 <fantasai> Tantek: I think the current use case stands well enough on its own.
17:12:15 <fantasai> Tantek: Would consider case of third-party scripts being disabled as a separate use case.
17:12:37 <fantasai> Florian: So if they're disabled, you would say scripting is supported?
17:13:01 <fantasai> Zakim, unmute me
17:13:01 <Zakim> fantasai should no longer be muted
17:13:15 <fantasai> Tantek: I don't think any modern people care about CCPP or know what it is.
17:13:30 <fantasai> Tantek: And URL-based vocabularies have not been successful on the Web.
17:13:45 <fantasai> Tantek: We can look at CCPP cases one by one to find use cases
17:14:03 <fantasai> Daniel: Not first time we discussed CCPP, never succeeded in integrating
17:14:13 <fantasai> Tantek: There's an opportunity for reuse of terminology, rather than reinvention.
17:14:20 <dstorey> *me neither*
17:14:27 <smfr> TabAtkins: former name for USSR
17:14:36 <glazou> lol
17:14:41 <arno> ccpp = composite capabilities/preferences profiles
17:14:43 <TabAtkins> hehe
17:14:44 <glazou> smfr: was CCCP
17:14:45 <fantasai> Tantek: But I wouldn't expect any web developer to know or use it.
17:14:47 <arno> http://www.w3.org/Mobile/CCPP/
17:14:50 <dbaron> CC/PP
17:15:18 <dstorey> c++?
17:15:26 <fantasai> Tantek: CCPP was designed for previous generation of phones. Hasn't kept up with modern mobile web
17:16:00 <fantasai> Anton: Modern scripts, when they are working with CSS, because there is no syntactic support for using script, what they tend to do is to insert a class into the <body> tag
17:16:24 <fantasai> Anton: And usually that class name is specific to the script, that is if it's a library, it inserts the library name into the <body> tag.
17:16:35 <fantasai> Anton: In the CSS you can distinguish which libraries are loaded from the CSS.
17:16:42 <dbaron> СССР != CC/PP
17:16:54 <fantasai> Anton: What we're seeing with this proposal is that we're loosing that fine-grained control, and to me that feels a little bit of a step backward.
17:17:24 <fantasai> glazou: So you are saying that because the feature is not powerful enough, moving it to declarative is not a good idea.
17:17:42 <fantasai> Anton gives an exampe.
17:18:02 <hober> q+ hober
17:18:05 <tantek> see http://www.modernizr.com/docs/
17:18:08 <Bert> q-
17:18:10 <fantasai> Anton: Until we have some concrete uses -- what exactly would someone be styling differently based on script or no script? -- we are going to get worse-written websites.
17:18:30 <fantasai> Tantek: One of the popular libraries right now, modernizr, specifically provides devs with JS and No-JS class names
17:19:06 <fantasai> Tantek: Since there's a modern library that provides this, that people use, shows that there's a use case for coarse granularity.
17:19:22 <fantasai> Tantek: Not saying there isn't a case for fine granularity, but that coarse granularity has a strong one.
17:19:37 <tantek> specifically, Modernizr replaces the class of "no-js" in the HTML tag, with "js" when JavaScript is present
17:19:59 <fantasai> Daniel: I have a use case for editors, where JS is disabled by default; editing a dynamic document makes no sense.
17:20:02 <hober> q- hober
17:20:07 <tantek> Zakim, q-
17:20:07 <Zakim> I see no one on the speaker queue
17:20:15 <fantasai> Florian: I suggest we start drafting the coarse granularity version
17:20:22 <fantasai> Florian: and then go further if we see the need.
17:20:28 <dbaron> I think the key question is what percentage of the use cases for this a (script) media query would solve, and what percentage would need more detailed domain or script-feature support.
17:20:44 <fantasai> Daniel: Since I see no objection to the original proposal, I say we go ahead and add that. Possibly add a note about finer granularity
17:21:03 <dbaron> q+
17:21:20 <fantasai> Florian: So far dont' have an editor's draft, will put in the wiki
17:21:45 <fantasai> dbaron: Just wanted to comment that, one thing I'm more worried about than domain stuff, is how much people are going to want the detection to be based on particular features in the script
17:21:58 <fantasai> Florian: Once you know script is running, you can do feature-detection in the script.
17:22:21 <fantasai> dbaron: Question is, what is the percentage of use-cases that want feature-detection vs. scriptability detection.
17:22:29 <tantek> dbaron, but this is a replacement for what modernizr does
17:22:31 <fantasai> dbaron: If that percentage is high, then we are not solving the real problem.
17:22:42 <tantek> modernizr replaces "no-js" with "js"
17:22:47 <tantek> and developers style based on that
17:22:48 <fantasai> Florian: Having more concrete use cases would help figure this out.
17:23:22 <fantasai> RESOLVED: Draft script/no-script detection for Media Queries 4
17:23:43 <fantasai> Topic: Publish CSS3 Text / CSS3 Writing Modes
17:24:08 <fantasai> Daniel: jdaggett says he's fine with publishing css3-text, but would like to defer decision to publish css3-writing-modes to next week
17:24:12 <fantasai> Daniel: Anyone else?
17:24:33 <fantasai> Daniel: No objection to publishing CSS3 Text?
17:24:40 <fantasai> Florian: not from me
17:24:47 <fantasai> RESOLVED: Publish CSS3 Text as WD
17:24:54 <fantasai> Writing Modes deferred to next week
17:24:57 <tantek> Zakim, mute
17:24:57 <Zakim> I don't understand 'mute', tantek
17:25:00 <fantasai> Topic: Switching to Mercurial for specs
17:25:13 <smfr> yes please
17:25:19 <tantek> what about git?
17:25:19 <TabAtkins> +1
17:25:29 <TabAtkins> git's my preference, but anything is better than CVS.
17:25:43 <fantasai> Bert: Explain the advantages?
17:25:57 <tantek> er, doesn't mind CVS
17:26:02 <fantasai> Florian: nicer to work offline, diffs are easier, merging is better
17:26:19 <sylvaing> if merging is better, that's big imo
17:26:21 <fantasai> fantasai: We can rename and move files, and fork them while keeping history
17:26:33 <fantasai> fantasai: which we're doing a lot when splitting things into two levels
17:26:46 <fantasai> fantasai: We don't really do any merging, so I don't see that as an advantage here.
17:26:55 <fantasai> Tantek: Consider others like git?
17:27:20 <dbaron> http://hgbook.red-bean.com/ should be a good starting point
17:27:28 <plinss> http://wiki.csswg.org/test/mercurial
17:27:37 <fantasai> plinss: Considering that we're using Mercurial for tests, and others are W3C are using it for both tests and specs
17:27:43 <fantasai> plinss: Don't see the advantage to using git
17:28:11 <arronei> I agree I don't see andy reason for using git.
17:28:16 <fantasai> Tantek: I don't want to switch to another system without at least having parity on documentation for setting up to edit
17:28:27 <sylvaing> agrees with Tantek
17:28:31 <arronei> Mercurial seems to be the common one at W3C
17:28:33 <fantasai> Tantek: "if it's not broken don't fix it" consideration...
17:28:47 <dbaron> http://annevankesteren.nl/2010/08/w3c-mercurial
17:28:59 <fantasai> Kimberly: There's some very good documentation online for Mercurial, they used at TPAC for people starting to write tests. With that documentation, I was up and running in 3 minutes
17:29:03 <fantasai> Tantek: Woah
17:29:13 <fantasai> Florian: Are we importing history from CVS?
17:29:22 <glazou> ROFL @ "the rest is relatively easy. Just invoke hg. "
17:29:31 <dbaron> http://www.w3.org/html/wg/wiki/Testing/Submission/
17:29:34 <sylvaing> there is source control doc, and there is the connectivity part e.g. SSH. I had a far harder time setting up the latter than the former
17:29:47 <tantek> frankly, mercurial is already legacy. open source communities have moved onto git.
17:30:21 <fantasai> fantasai and dbaron explain this is very straightforward to do
17:30:39 <dbaron> Are we planning one repository per spec or one repository for all specs?
17:30:54 <fantasai> Tantek: I want to see documentation at the same level as the CVS documentation we have first.
17:31:02 <TabAtkins> I think current practice is to do one repo per spec?
17:31:26 <fantasai> sylvain agrees
17:31:38 <TabAtkins> One problem I have with the W3C's Hg - it's basically impossible to find the damned spec in the view.
17:31:42 <fantasai> Tantek: Another concern is that Mercurial is already legacy outside of W3C
17:31:53 <TabAtkins> Our CVS view is easy - just go to dev.w3.org/csswg
17:31:54 <fantasai> Tantek: New projects use github, people use git
17:32:16 <fantasai> Daniel: This does not sound like a good argument time. Geeks are going to use the newest best thing.
17:32:34 <fantasai> Florian: For a while it was not clear whether Mercurial or Git was better, now more people prefer Git.
17:32:53 <nimbu1> nimbu1 has joined #css
17:33:23 <fantasai> Florian: While I prefer Git, we are using mercurial throughout W3C, so I don't mind ..
17:33:24 <arno> git does have a lot of wind in its sails
17:33:49 <fantasai> Tantek: I am skeptical about switching to Mercurial and then in a few years switching to git
17:34:02 <fantasai> plinss: There's a lot of cost to us using Git, and W3C using mercurial.
17:34:16 <fantasai> plinss: Even assuming W3C eventually switches to git.
17:34:22 <dstorey> main advantage for me with git is using github over say bitbucket, but I guess w3c will be self hosting rather than on github
17:34:34 <Bert> q+ to ask if we can first ask other WGs for their mercurial experience (don't like to be the first to use a new tool...)
17:34:42 <fantasai> Florian: How many W3C tools, rather than W3C people, rely on Mercurial?
17:34:43 <dbaron> q-
17:34:49 <fantasai> plinss: test suite tools, as well as actual usage
17:35:04 <fantasai> fantasai: A lot of the systems plinss has been building are integrated with mercurial
17:35:30 <fantasai> tantek: People are building tools on top of git, not so much on top of Mercurial
17:35:50 <fantasai> tantek: it's a dying platform
17:36:06 <fantasai> plinss: I don't agree it's a dying platform, and a potential move years in the future
17:36:21 <kojiishi> There seems to be a lot of W3C repositories already at http://dvcs.w3.org/hg
17:36:39 <fantasai> Daniel: I'm hearing no consensus.
17:37:09 <Zakim> -danielweck
17:37:11 <fantasai> Florian: What I'm hearing is ppl who are pushing for hg, write CSSWG-specific documentation for it.
17:37:23 <sylvaing> I have no opinion on moving out of CVS. But if someone writes a doc to switch, I'll test it out and volunteer to document the Windows steps
17:37:23 <Bert> -> http://www.w3.org/blog/systeam/2010/06/16/why_we_chose_mercurial_as_our_dvcs/ W3C systems team on Mercurial vs others
17:37:24 <Zakim> +??P7
17:37:24 <fantasai> Florian: If it's good enough for the skeptics, then we can move.
17:37:29 <danielweck> Zakim, ??P7 is me
17:37:29 <Zakim> +danielweck; got it
17:37:35 <dbaron> I'm not sure the conversion is all that straightforward -- I think conversions from CVS are pretty painful no matter what.
17:37:46 <dbaron> (conversions of existing history, that is)
17:37:58 <sylvaing> dbaron, isn't that true of any source control system migration?
17:38:10 <fantasai> Daniel: who is willing to take an action on writing that documentation?
17:38:22 <dbaron> sylvaing, I think conversions between systems that use atomic commits are a lot easier.
17:38:43 <sylvaing> dbaron, fair. 
17:38:46 <fantasai> Daniel: Mercurial is very powerful, but it is much harder to understand.
17:38:47 <dbaron> sylvaing, though conversions between svn and others are a little painful because of its use of conventions for branching/tagging instead of mechanisms
17:39:28 <fantasai> Koji: I thought Anne said documentation is already available for HTML group, isn't that enough for us?
17:39:34 <kojiishi> http://annevankesteren.nl/2010/08/w3c-mercurial
17:39:39 <tantek> here is the challenge, if you support mercurial, write up documentation *at least as good as*  http://wiki.csswg.org/spec/cvs
17:40:34 <tantek> previous to that cvs documentation there were *tons* of cvs documentation on the web and yet it was still a huge barrier for editors of CSS drafts
17:40:38 <Ms2ger> I would love to see that for git
17:40:49 <tantek> so no, external mercurial documentation is insufficient
17:41:15 <dbaron> tantek, I expect the hg version of that will be a lot shorter
17:41:32 <fantasai> fantasai explains reasoning for opening the discussion
17:41:34 <dbaron> tantek, because there's no ssh involved (w3c setup uses https:)
17:41:42 <tantek> if you want to switch to mercurial, put in the work to provide AS GOOD documentation as CVS
17:41:53 <tantek> if you don't have the time for that, then neither should the rest of the group 
17:42:23 <fantasai> sylvaing: We need a volunteer to write a doc, one to write steps for Windows, and volunteers to test it.
17:42:31 <fantasai> Florian: I'll volunteer to test it; I'm in favor of switching.
17:43:06 <dbaron> can we agree to put said document at http://wiki.csswg.org/spec/hg ?
17:43:08 <fantasai> Daniel: Still need volunteers to write docs
17:43:37 <fantasai> Topic: EXIF orientation for images
17:43:59 <fantasai> dbaron: There are ppl who want to post images that get their EXIF orientation handled by the browser. Since it's not backwards compat, can't do it by default.
17:44:08 <fantasai> dbaron: Thought we had one in an old draft, but maybe I'm misremembering.
17:44:26 <fantasai> fantasai: This would probably be image-orientation property, which never got an auto keyword.
17:44:38 <TabAtkins> I wouldn't mind changing image-orientation's grammar to "[ <angle> || flip ] | auto"
17:44:40 <tantek> or image-orientation: exif ?
17:44:51 <TabAtkins> Or, not auto, "from-image".
17:44:54 <tantek> why not be specific and say exif rather than auto?
17:44:57 <fantasai> dbaron: Question is, do we want to do this, and if so do we want image-orientation to support all EXIF orientations rather than just the 4 it now supports
17:45:22 <fantasai> tantek, because it might be doen via some other technology in some other image format
17:45:28 <fantasai> tantek, CSS keywords are format-agnostic
17:45:40 <fantasai> Florian: Does anyone use the other orientations?
17:45:44 <tantek> analogy: color-profiles
17:45:47 <fantasai> Arno: It's in the spec, but I can't think of any camera that uses them.
17:46:10 <fantasai> Tantek: Some images have embedded color profiles, we never got to using those.
17:46:18 <fantasai> Tantek: We dropped that property due to insufficient interest.
17:46:28 <fantasai> Tantek: Just wanted to point out similar situation.
17:46:47 <TabAtkins> The extra 4 orientations are used sometimes for self-facing cameras.
17:46:57 <fantasai> Florian: One problem was mismatched colors between flash and images. But Flash now does it
17:47:02 <TabAtkins> vs world-facing
17:47:26 <TabAtkins> Note as well that Chrome would like to implement auto-orienting as well.
17:47:38 <tantek> level 4
17:48:13 <fantasai> fantasai: I think it's a fine idea, my concern is whether it should go in L3 or not
17:48:37 <smfr> http://www.w3.org/TR/css3-images/#image-orientation0
17:48:42 <fantasai> smfr: I've seen patches come in that attempt to support this.
17:48:54 <fantasai> smfr: Question is, does this only affect content images, or also CSS images?
17:49:14 <TabAtkins> smfr: image-orientation only affects image elements.
17:49:22 <TabAtkins> It's... kinda underdefined right now.
17:49:34 <fantasai> Florian: Intuitively, I'd say only content images
17:49:37 <TabAtkins> Theoretically it could affect <video> and <canvas> too, I guess.
17:49:58 <alexmog> alexmog has joined #css
17:50:25 <fantasai> fantasai: content images can be injected via CSS, too. Also image-resolution IIRC applies to CSS images as well
17:50:56 <tantek> hence why I said level 4 ;)
17:51:08 <fantasai> Daniel: Let's explore this idea.
17:51:12 <TabAtkins> image-resolution is currently defined on all elements, but that's inconsistent and weird.
17:51:14 <fantasai> fantasai: [...]
17:52:05 <TabAtkins> image() previously allowed resolution-altering on specific CSS images, which I think is a better thing.
17:52:26 <fantasai> fantasai explaisn why image-orientation is in the draft
17:52:45 <fantasai> Florian: Can we adda note that CSS4 will add EXIF support?
17:52:48 <tantek> anything stopping http://dev.w3.org/csswg/css3-ui/ from being published as LC?
17:53:04 <fantasai> Topic: Publish CSS3 UI as LC
17:53:11 <fantasai> Tantek: Checked in changes requested
17:53:20 <fantasai> Tantek: Didn't hear any feedback or objections in the last week
17:53:25 <fantasai> Tantek: So what's the next step?
17:53:44 <fantasai> Florian: I asked for a week review last week, and didn't find time, so I'll just shut up
17:53:55 <fantasai> Tantek: if you want a day, I'm fine with that.
17:54:05 <fantasai> Florian: Don't have time, so I will just trust other people to review.
17:54:11 <fantasai> Tantek: How long do people want the last call?
17:54:42 <Zakim> -[Microsoft]
17:55:32 <fantasai> discussion of when to set the deadline
17:56:00 <Bert> (3 weeks is required)
17:56:05 <fantasai> Daniel: I recommend 4 weeks
17:56:52 <fantasai> fantasai: Working Groups to contact?
17:56:55 <fantasai> Tantek: HTML
17:57:02 <fantasai> Tantek: WAI-PF
17:57:10 <fantasai> Tantek: SVG?
17:57:32 <fantasai> Bert: XForms
17:57:59 <tantek> Bert if there are any problems with publication of the LC (like any details I have forgotten), please let me know!
17:58:08 <tantek> I will be on irc and try to be very accessible to help out
17:58:15 <fantasai> RESOLVED: Publish LC of CSS3 UI with 4 weeks comment period
17:58:25 <fantasai> tantek, make sure you run the validator and the link checker first
17:58:39 <fantasai> Tantek: If anyone has any other issues or typos to report, send them in.
17:58:51 <fantasai> Meeting closed.
17:58:52 <Zakim> -kimberly
17:58:53 <smfr> smfr has left #css
17:58:54 <Zakim> -antonp
17:58:55 <Zakim> - +1.415.832.aadd
17:58:56 <Zakim> -glazou
17:58:58 <Zakim> -sylvaing
17:58:58 <Zakim> -plinss
17:58:58 <Zakim> -Rossen
17:58:59 <Zakim> -florianr
17:59:01 <Zakim> -stearns
17:59:03 <Zakim> -kojiishi
17:59:05 <Zakim> -Bert
17:59:07 <Zakim> -smfr
17:59:09 <Zakim> -??P58
17:59:11 <Zakim> -danielweck
17:59:13 <Zakim> -dbaron
17:59:15 <Zakim> -hober
17:59:19 <Zakim> -fantasai
17:59:21 <Zakim> -tantek
17:59:23 <Zakim> Style_CSS FP()12:00PM has ended
17:59:23 <alexmog> alexmog has left #css
17:59:25 <Zakim> Attendees were glazou, dbaron, plinss, +1.415.871.aaaa, hober, florianr, tantek, antonp, smfr, stearns, JohnJansen, Rossen, fantasai, kimberly, Bert, kojiishi, danielweck,
17:59:28 <Zakim> ... +1.206.324.aacc, +1.415.832.aadd, sylvaing
17:59:58 <dbaron> I started sketching out http://wiki.csswg.org/spec/hg but it needs some more work
18:02:20 <nimbu> nimbu has joined #css
18:05:15 <tantek> ok running link checker
18:05:26 <tantek> oh look, found 2 bad fragments from prev CSS21 references
18:11:57 <Bert> Fantasai, want to do some Backgrounds and borders now?
18:12:19 <fantasai> yep
18:12:31 <fantasai> http://www.w3.org/Style/CSS/Tracker/products/11
18:13:26 <Bert> Does that mean you expect this is going to be difficult? :-)
18:14:06 <fantasai> yes, and, I need more space for IRC, editor, and browser all side-by-side :)
18:15:44 <fantasai> Ok, I'm set up
18:16:24 <fantasai> ISSUE-182
18:16:30 <fantasai> http://www.w3.org/Style/CSS/Tracker/issues/182
18:16:51 <fantasai> trackbot: ISSUE-182
18:16:51 <trackbot> Sorry, fantasai, I don't understand 'trackbot: ISSUE-182'. Please refer to http://www.w3.org/2005/06/tracker/irc for help
18:17:09 <fantasai> ISSUE-182?
18:17:09 <trackbot> ISSUE-182 -- Should box-decoration-break also apply to bidi reordering splits? -- raised
18:17:09 <trackbot> http://www.w3.org/Style/CSS/Tracker/issues/182
18:17:14 <Bert> Your e-mail says that split borders due to bidi could always be 'slice' but shouldn't that be 'clone' instead?
18:17:14 <fantasai> ah, there we go
18:17:24 <fantasai> Bert: No, they're slice in CSS2.1
18:17:32 <Bert> Ah
18:17:39 <fantasai> I have no opinion on this, do you?
18:17:51 <fantasai> I'm thinking we should poke the i18n people and see if they can find an opinion :)
18:18:08 <Bert> Slice seems ugly, but if it is already the current behavior...
18:18:59 <Bert> Maybe I'd want to be able to override 'slice' with 'clone'
18:19:16 <Bert> But asking some bidi experts seems a good idea.
18:19:43 <Bert> I don't have many bidi books to check what they do :-)
18:20:23 <fantasai> it always looks bad when you style text across bidi splits, *especially* if you're using box model stuff!
18:21:27 <Bert> If it happens to be a link source anchor, you might want the two halves to look like buttons.
18:21:54 <fantasai> instead of a broken button? :)
18:21:56 <fantasai> yeah, possibly
18:22:45 <Bert> Not more broken than with a line break in the middle.
18:23:04 <fantasai> yeah, those always look odd too
18:23:12 <fantasai> but not as bad if it's only underlined
18:23:47 <fantasai> I guess I'd lean towards applying it, then.
18:23:50 <fantasai> you?
18:24:03 <Bert> me too, but I don't feel like I really know the answer.
18:24:49 <Bert> If we ask i18n people, do we have a chance of an naswer?
18:25:18 <fantasai> worst case I'll corner Aharon and demand an answer :)
18:25:27 <Bert> :-)
18:25:38 <fantasai> Let's make it apply for now, though?
18:25:42 <fantasai> since it's undefined atm
18:25:54 <Bert> Agreed.
18:26:24 <fantasai> plinss: So, remind me how I get a testcase to load from shepherd?
18:26:31 <fantasai> plinss: I can't seem to click on anything that loads the file
18:26:47 <fantasai> ok, you want to make the edits?
18:26:50 <fantasai> I'll send the email
18:27:13 <Bert> OK
18:27:50 <Bert> Are you putting somthing in tracker, or should I make myself an action?
18:28:02 <Bert> Or I can just wait for your draft, I guess...
18:28:44 <fantasai> I'm just writing up the email right now...
18:30:30 <fantasai> k, sent
18:31:10 <fantasai> Bert: do you have proposed wording?
18:32:23 <fantasai> I guess s/line break/line break or bidi-imposed break/ ?
18:33:43 <Bert> I was trying to write something longer, but that short one might actually be good enough.
18:33:56 <fantasai> ok :)
18:34:08 <fantasai> will you check it in, or should I?
18:34:24 <Bert> I'm editing right now.
18:34:29 <fantasai> ok
18:35:44 <Bert> Done.
18:35:48 <fantasai> cool
18:35:56 <fantasai> ISSUE-189?
18:35:56 <trackbot> ISSUE-189 -- Corner transition point define in spec is wrong -- raised
18:35:56 <trackbot> http://www.w3.org/Style/CSS/Tracker/issues/189
18:36:12 <fantasai> So, we don't actually have a good answer for this, and we know the one in the spec is wrong.
18:36:18 <fantasai> So I'm thinking we should make it undefined.
18:36:27 <fantasai> And just say that it has to be proportional
18:36:44 <fantasai> such that if one border is zero-width, the other border takes up the whole corner curve
18:37:07 <fantasai> That way we can at least have the spec reflect reality, and implementers can poke around and see if they can figure out what actually looks good.
18:37:32 <Bert> That's indeed better than what's there now, but still feels less than ideal.
18:37:49 <fantasai> Yeah. But I know I won't find the right answer any time soon.
18:42:16 <Bert> "Color and style transitions should be as smooth as possible" as the sole content for 5.4?
18:42:18 <fantasai> Bert: Here's what I've got, I'm missing a piece
18:42:21 <fantasai> The center of color and style transitions between adjoining borders
18:42:21 <fantasai> must be proportional to the ratio of the border widths such that when
18:42:21 <fantasai> one border width is zero the style and color of the other takes up the
18:42:21 <fantasai> entire curve, and [something about continuity]
18:42:21 <fantasai> However it is not defined what these transitions look like or how
18:42:23 <fantasai> "proportional" should be interpreted, other than at the extremes.
18:43:44 <fantasai> I think it's reasonably likely that people are assuming that 'border-radius: 5%; border-style: solid none; border-color: green red" shows no red
18:43:50 <danielfilho> danielfilho has joined #css
18:43:58 <fantasai> Other than that, I doubt there's much dependency on anything specific
18:44:13 <fantasai> (if for no other reason than there's no interop, but also split curved borders don't look very nice)
18:44:31 <Bert> Yes, but maybe the case of zero border is an exception, rather than the limit of the general case.
18:45:23 <fantasai> So, imagine a gradient border transition
18:45:34 <fantasai> At zero the border is all green
18:45:44 <fantasai> at 1px vs 50px, it's tinted red all along the curve?
18:46:13 <Bert> Yes, maybe... [Trying to visualize...]
18:47:36 <fantasai> okay, let's poke bradk about this then
18:47:54 <fantasai> but I think we agree it should not immediatley jump to half red half green? :)
18:48:31 <Bert> Yeah, that would be ugly.
18:49:06 <fantasai> okay
18:49:10 <fantasai> I think that makes sense.
18:49:24 <fantasai> so, supposing we draft up your idea...
18:49:56 <fantasai> oh, degenerate cases
18:50:19 <fantasai> ...
18:50:22 <fantasai> ok, don't think it's a problem
18:50:24 <fantasai> :)
18:50:29 <fantasai> right so drafting this thing...
18:52:25 <fantasai> If one of these borders is zero-width, then the other border takes
18:52:25 <fantasai> up the entire transitional area. Otherwise,
18:52:25 <fantasai> the center of color and style transitions between adjoining borders
18:52:25 <fantasai> must be proportional to the ratio of the border such that [something
18:52:25 <fantasai> about continuity].
18:52:27 <fantasai> However it is not defined what these transitions look like or how
18:52:30 <fantasai> "proportional" should be interpreted, other than at the extremes.
18:52:33 <fantasai> ?
18:53:07 <Bert> Yes. I was just writing this: (1) The style and color of a zero-width (absent) border side does not influence the style of the corner (but influences its shapes). (2) The corner between two non-zero borders should show a smooth transition between the styles and colors.
18:53:30 <Bert> s/shapes/shape/
18:53:42 <fantasai> the problem with "smooth transition between styles and colors"
18:53:49 <fantasai> is that it doesn't actually work in practice
18:53:50 <fantasai> first
18:53:55 <fantasai> we want to allow a hard color transition
18:54:07 <fantasai> second, it's very very tricky to do any kind of soft style transition :)
18:54:14 <fantasai> so we also want to allow hard style transitions
18:54:24 <tantek> ah, apparently XForms 1.1 dropped the example I had used from XForms 1.0 so I'll drop it as well. caught by the link checker.
18:54:31 <fantasai> the issue here is that the center of the transition needs to move proportionally
18:58:16 <Bert> I have a hard time determining what it is proportional to. :-(
18:59:16 <fantasai> hmm
19:00:40 <fantasai> ooh, this is ridiculous, but...
19:01:25 <fantasai> Otherwise,
19:01:25 <fantasai> the center of color and style transitions between adjoining borders
19:01:25 <fantasai> must be proportional to the ratio of the border widths such that a
19:01:26 <fantasai> function of its location is continuous as the border widths' ratio changes.
19:01:48 <Bert> Also, if the style is different (say solid/double) and the corner is not rounded, should the color edge still be diagonal?
19:01:54 <fantasai> And we can link to the mathematical definition of 'continuous'.....
19:02:14 <Bert> That requirement of continuity is good, indeed.
19:04:04 <fantasai> is it worded correctly?
19:04:09 <fantasai> 'as the border widths' ration changes'??
19:04:58 <Bert> Maybe easier to say it is continous w.r.t. to both border widths.
19:05:31 <fantasai> the center of color and style transitions between adjoining borders
19:05:31 <fantasai> must be proportional to the ratio of the border widths such that a
19:05:31 <fantasai> function of its location is continuous with respect to the ratio.
19:05:32 <fantasai> 
19:05:34 <fantasai> ?
19:05:46 <fantasai> s/the/this/
19:08:37 <Bert> I think you're trying to say that the center is nearer the thin border than the thick border, but just talking about ratio doesn't make that clear.
19:09:00 <fantasai> It does if you include the first bit about zero-width borders
19:09:07 <fantasai> If one of these borders is zero-width, then the other border takes
19:09:07 <fantasai> up the entire transitional area. Otherwise,
19:09:07 <fantasai> the center of color and style transitions between adjoining borders
19:09:07 <fantasai> must be proportional to the ratio of the border widths such that a
19:09:07 <fantasai> function of its location is continuous with respect to this ratio.
19:09:09 <fantasai> However it is not defined what these transitions look like or how
19:09:12 <fantasai> &ldquo;proportional&rdquo; should be interpreted.
19:10:47 <fantasai> Bert: Do you think that's good enough?
19:12:22 <Bert> Are you sure the zero-width case is a normal case, i.e., captured by your text about "proportional"? Or is rather a separate case with separate rules?
19:13:53 <fantasai> Well, they're technically separate
19:14:00 <fantasai> since there's an "if... otherwise"
19:14:34 <fantasai> But having that first case makes it obvious which way you should skew the proportion.
19:14:38 <fantasai> and why
19:14:44 <fantasai> imo, anyway :)
19:16:02 <Bert> If they are really separate, then the description of the zero-width case does't imply anything about what "proportional" means
19:16:46 <fantasai> No, you're right it doesn't.
19:17:03 <Bert> The word Otherwise separates, rather than connects the cases.
19:17:08 <fantasai> As it's intended to
19:17:40 <fantasai> But if you were going to make the center's location continous
19:17:58 <fantasai> and you started with it at the left end because the top side is zero
19:18:15 <fantasai> then increasing the top side to 1px isn't going to suddenly jump the center to the other end
19:18:24 <fantasai> s/top/left/
19:18:32 <fantasai> s/top/left/
19:20:37 <Bert> Hmm, I can't get rid of the impression that it is the ratio of the radii that determines the center, rather than the ratio of the border widths.
19:21:11 <fantasai> imagine you hold the radii constant
19:21:13 <fantasai> and equal
19:21:20 <fantasai> Now flex the border widths
19:22:00 <fantasai> the radii need to be considered as well, imo
19:22:14 <fantasai> but the proportionality is determined by the border widths
19:22:31 <fantasai> and the radii are only considered in how you map this curved surface to 1D
19:26:37 <Bert> Is the center of the transition a line through the corner of the box with a slope equal to the ratio of the border widths?
19:27:17 <fantasai> in some cases could be, but imo we shouldn't be requiring that
19:27:31 <fantasai> that's the problem we're not trying to solve today :)
19:27:40 <fantasai> because solving it correctly would take a lot of drawings and a lot of web-designer polling
19:27:47 <fantasai> and probably some very tricky maths
19:28:13 <fantasai> I'm going to check in what we have for now.
19:28:39 <fantasai> And we'll see what the WG thinks.
19:29:30 <Bert> OK, I'll try to think about it more later.
19:31:12 <fantasai> ok, checked in
19:31:44 <fantasai> ISSUE-197?
19:31:44 <trackbot> ISSUE-197 -- clarify computed value of background-position -- raised
19:31:44 <trackbot> http://www.w3.org/Style/CSS/Tracker/issues/197
19:31:53 <fantasai> I think I fixed that, dbaron should check
19:32:20 <fantasai> http://dev.w3.org/csswg/css3-background/#the-background-position
19:32:27 <fantasai> ISSUE-207?
19:32:27 <trackbot> ISSUE-207 -- border-image <number> slicing for SVG -- raised
19:32:27 <trackbot> http://www.w3.org/Style/CSS/Tracker/issues/207
19:32:39 <fantasai> http://lists.w3.org/Archives/Public/www-style/2011Sep/0172.html
19:32:56 <fantasai> Bert: I have no idea about this one. Do you?
19:33:10 <Bert> Still reading...
19:35:52 <Bert> I think you did the right thing already.
19:36:11 <Bert> Probably good idea to ask dbaron explicitly to verify.
19:36:54 <Bert> Oh wait, I'm still at 197.
19:37:00 <Bert> Sorry.
19:37:06 <Bert> Reading 207 now.
19:37:24 <fantasai> oh!
19:37:25 <fantasai> heh
19:37:25 <fantasai> :)
19:37:32 <fantasai> well, good to get your review, too ;)
19:37:49 <tantek> ok, link checker fixes completed for css3-ui.
19:38:10 <fantasai> tantek, validator also?
19:38:27 <tantek> yeah did that first
19:38:54 <Bert> We probably cannot say anything more definitive about vector formats in general, but we can say somethign about SVG.
19:39:32 <fantasai> tantek: your status section says you're returning to LCWD because you dropped stuff, but it's also because you added text-overflow. should mention that
19:39:32 <tantek> fantasai, bert, is there any way to include editor's draft specific text that  disappears in a TR version
19:39:50 <Bert> Using viewbox seems right, with width/height as fallback if there is no viewbox.
19:40:03 <fantasai> tantek: comment it out when you publish? :)
19:40:22 <Bert> Other than telling me to remove it by hand, I don't think so, Tantek. :-)
19:41:33 <tantek> ok I'll take care of it
19:41:47 <tantek> good catch fantasai
19:41:52 <fantasai> bert: What if we say that images that need drawing in order to determine slices are drawn at the size of the border image area?
19:41:58 <fantasai> bert: would that make sense? 
19:42:47 <Bert> Yes, that sounds right. Is that actually enough to solve the issue?
19:43:23 <Bert> Hmm, I guess it is.
19:44:23 <fantasai> ok, I'll work on wording
19:44:28 <fantasai> Could you review ISSUE-212?
19:44:31 <fantasai> ISSUE-212?
19:44:31 <trackbot> ISSUE-212 -- background-position grammar is kinda awkward -- raised
19:44:31 <trackbot> http://www.w3.org/Style/CSS/Tracker/issues/212
19:44:43 <fantasai> I just checked in edits for it based on Tab's proposal http://lists.w3.org/Archives/Public/www-style/2011Dec/0447.html
19:44:50 <fantasai> I think that's correct, but, you're the grammar expert
19:45:18 <fantasai> http://dev.w3.org/csswg/css3-background/#the-background-position
19:48:23 <fantasai> Bert: ok, here's my proposed wording for 207
19:48:24 <fantasai>   <dd>Numbers represent pixels in the image (if the image is a raster
19:48:24 <fantasai>     image) or vector coordinates (if the image is a vector image). If
19:48:24 <fantasai>     the image must be sized to determine the slices, then it is sized
19:48:25 <fantasai>     to the <i>border image area</i>.
19:50:21 <Bert> Maybe a note to explain why that last sentence is important? The case of SVG images with no intrinsic size?
19:50:43 <fantasai> it'd also apply to gradients
19:51:46 <dstorey> dstorey has joined #css
19:54:56 <fantasai> Bert: checked in
19:55:36 <Bert> Looks good.
19:55:56 <fantasai> cool
19:56:04 <fantasai> Does 212 look ok?
19:57:35 <Bert> I'm not sure it is actually better. I suspect there are other ways. But I think the grammar is OK.
19:57:53 <fantasai> ok
19:58:00 <fantasai> I agree that the new one is more readable than the one we had
19:59:34 <fantasai> ok, I have to leave in a few minutes
19:59:46 <fantasai> Continue tomorrow?
20:00:10 <Bert> Yes, good idea.
20:00:21 <fantasai> ok
20:00:43 <fantasai> you can look over the other issues and see if you've got good solutions :)
20:00:55 <fantasai> 208 confuses me in particular... ^^;;
20:00:59 <Bert> Yes, will do that.
20:01:12 <Zakim> Zakim has left #css
20:05:54 <plinss> fantasai: click on either the source file link or any revision link, then click 'raw' in the Mercurial view (at the top)
20:06:38 <plinss> fantasai: looks like a recent Mercurial upgrade changed that behavior to serve as application/binary (for security), I just reconfigured to serve as text/html
20:06:46 <plinss> fantasai: should work now...
20:22:46 <nimbu1> nimbu1 has joined #css
20:35:59 <nimbu> nimbu has joined #css
20:37:43 <tantek> fantasai, I've noted the couple new properties/values in the status section up front now and linked to the changes section from there: http://dev.w3.org/csswg/css3-ui/#status
20:38:41 <tantek> Bert, I've commented out the editor's draft only "This version" text/link, and provided the code instead for generating the TR "This version" text/link. http://dev.w3.org/csswg/css3-ui/Overview.src.html
20:39:49 <tantek> (ah, forgot the style sheet)
20:53:02 <dino> dino has joined #css
21:13:30 <tantek> well, tried changing the stylesheet and it didn't make a difference in the post-processed version so presumably either Bert has to do the transformation, or I'm missing something.
22:04:26 <dino> dino has joined #css
22:05:53 <fantasai> tantek: I'll take a look
22:09:31 <cyril> cyril has joined #css
22:13:58 <fantasai> tantek: Need to replace [STATUS] with WD in "This Version"
22:14:06 <fantasai> tantek: then it will regenerate correctly
22:22:32 <dino> dino has joined #css
22:24:37 <nimbu1> nimbu1 has joined #css
22:30:28 <tantek> fantasai - is that documented on the wiki somewhere?
22:30:36 <tantek> too much ceremony still
22:34:14 <fantasai> the processor docs are here - https://www.w3.org/Style/Group/css3-src/bin/README.html
22:34:37 <fantasai> I don't really see where it's explained how to switch statuses...
22:36:53 <ChrisL> ChrisL has joined #css
22:38:43 <ChrisL> ChrisL has joined #css
22:43:33 <tantek> aha maybe this? "If there is a H2 subheading under the H1 that gives the spec's status, the [STATUS] variable will be initialized from that"
22:44:44 <tantek> no, in the case of css3-ui, that h2 is set to [LONGSTATUS]
22:46:13 <fantasai> tantek: cvs up
22:46:56 <fantasai> tantek: In general, Bert takes care of regenerating for the appropriate publication status.
22:47:04 <tantek> I did cvs up
22:47:13 <fantasai> tantek: But the change I made will let you do that yourself too
22:50:38 <tantek> huh ok
22:51:01 <tantek> I think I'm going to replace "SOMETIME IN THE FUTURE AFTER A PUBLIC LCWD IS PUBLISHED" with "4 weeks after the date of publication noted in the header"
22:51:14 <fantasai> you're required to put the date there
22:51:17 <fantasai> so
22:52:15 <fantasai> put 4 weeks from next Tuesday?
22:52:23 <fantasai> that's the next publication date after tomorrow
22:52:33 <fantasai> (W3C publishes on Tuesdays and Thursdays)
22:52:46 <tantek> that's dumb
22:53:00 <fantasai> ?
22:53:07 <tantek> guessword
22:53:16 <tantek> relative reference will have to do 
22:53:25 <tantek> not going to check-in guesswork into CVS, that's dumb
22:53:52 <fantasai> no, it's not dumb, it's convenient for the people who are going to read the draft
22:54:08 <fantasai> that's why there's a fixed date and not "4 weeks from go look at hte header"
22:54:21 <fantasai> the date in the draft is also "gueswork"
22:54:30 <fantasai> until it's published
22:54:32 <fantasai> this is no different
22:55:01 <tantek> no the date in the draft is not guesswork, it is the date the draft was last published to dev.w3.org
22:55:22 <fantasai> ah, well, when it's published it'll be the date it's published
22:55:27 <fantasai> and need to be generated for that date
22:55:31 <fantasai> and placed on the server 
22:55:33 <fantasai> in advance of that date
22:55:40 <tantek> well if there's a [ ] macro for that I'll use it
22:55:48 <fantasai> there isn't
22:55:49 <tantek> otherwise I'm not going to futz with guesswork in CVS
22:56:03 <fantasai> then leave your all-caps so Bert can quickly figure out it needs replacing
22:56:26 <tantek> where is the documentation on how to leave things for Bert to replace?
22:56:34 <fantasai> there isn't one
22:56:52 <fantasai> you can include a list in your email to him
22:57:07 <fantasai> but all-caps are pretty noticeable
22:57:32 <fantasai> so if you've got a FIXME, it's better to write FIXME than fixme
22:57:39 <fantasai> imho
23:01:00 <ksweeney> ksweeney has joined #css
23:01:06 <ksweeney> ksweeney has left #css
23:10:17 <tantek> fantasai, on what basis are you saying "you're required to put the date there" ?
23:10:26 <tantek> if it's just your personal preference, then I choose to disagree.
23:10:50 <tantek> and propose that a relative expression of the date to the absolute date of the document is sufficient
23:15:39 <miketaylr> miketaylr has joined #css
23:30:04 <fantasai> tantek: IIRC, pubrules checks for it
23:30:26 <tantek> well let's see if a relative date passes that test
23:30:42 <fantasai> tantek: if it requires a date, it requires it in a particular format
23:30:49 <tantek> or if not I'm ok with Bert editing it manual before posting to TR
23:30:50 <fantasai> tantek: which is DD MONTH YYYY
23:31:01 <tantek> either way, putting guess work into CVS is dumb and I have better things to do than that
23:32:10 <tantek> I put in something which is more resilient than guesswork.
23:32:28 <tantek> any time there is guesswork in our process it is an indication that something is broken
23:32:46 <tantek> it's worth pointing out when things are broken so we (the group) can fix them
23:33:00 <tantek> that's better than just ignoring them and guessing otherwise
23:34:42 <fantasai> if your publishing date was certain, then it wouldn't be guesswork
23:35:16 <fantasai> if you're aiming to publish Tuesday, and you get all your things together and send them to Bert early enough, then you'll be published Tuesday
23:35:26 <fantasai> if you don't, then you won't.
23:36:30 <fantasai> I can't tell if you'll publish Tuesday because I'm not you, and I don't know if you're going to get your things done and send the request to Bert
23:47:28 <dino_> dino_ has joined #css
23:50:17 <jdaggett> jdaggett has joined #css