08:16:08 RRSAgent has joined #css 08:16:08 logging to http://www.w3.org/2008/08/22-css-irc 08:16:11 RRSAgent, make logs public 08:17:25 on agenda: 08:17:59 -- styling for implicit video controls (discussing who added it to the agenda and if there is a proposal) 08:18:51 Philippe: There are two kinds of controls for the HTML5 video element. There's the default controls, then you can make controls with JS 08:19:54 elika: is there a proposal? 08:20:03 elika: suggest we skip the topic 08:20:06 glazou has joined #css 08:22:30 (further discussion on why implicit video controls are on the agenda and if it needs an action item to follow up) 08:26:21 plinss_ has joined #css 08:26:46 discussion: video control buttons need to be styled. Define pseudo elements for it? 08:27:22 bert: if we don't provide style, the only solution is script 08:27:36 daniel: suggest a proposal comes from implementers 08:28:07 peter: if this is something we want to address, we should at least discuss if this something we need to tackle 08:28:50 steve: we don't need to solicit a proposal, it will happen or not happen 08:29:43 I think we should have a discussion of styling of multimedia, including but not limited to controls, 'stylable aspects' (volume, brightness, contrast, perhaps) and control of optional aspects of the content, particularly accessibility 08:29:55 but I agree the discussion should be anchored by proposals... 08:30:17 and that today may not be the best use of time 08:30:36 bert: if we do something we should do it soon or it will fall off the table 08:31:13 the video-on-the-web group seems to be a good place to discuss cross-group aspects such as CSS implications of media elements, right? 08:31:16 david: looking at what mozilla is doing now 08:31:33 david: controls with SVG, not seeing anything with custom controls 08:31:49 (I am in another stds meeting and cannot call in, only IRC when I am not paying attention here!) 08:32:20 anne: We already have problems styling form controls 08:32:27 (it is noted that David Singer is interested in the topic) 08:32:33 anne: The appearance property is way underspecified 08:33:10 anne: people are implementing form controls in JS, makes it unusable for mobile phones 08:34:11 peter: propose action dsinger and bert to contact someone in mozilla and come up with a proposal 08:34:26 Philippe: someone being Chris Double 08:34:46 I'm happy to work with Bert on "CSS aspects of HTML5 media elements", yes 08:35:18 action bert: come up with a proposal for implicit video controls 08:35:19 Created ACTION-97 - Come up with a proposal for implicit video controls [on Bert Bos - due 2008-08-29]. 08:35:53 plh has joined #css 08:36:00 Topic: block flow 08:36:14 And for what it's worth, I think what we're doing with the controls attribute is pretty much what HTML5 says to do. 08:36:25 elika: molly proposed syntax for block-progression 08:37:07 elika: block-flow: tb | rl | lr | bt (bt is optional) 08:37:30 elika: richard, what do you think 08:37:36 richark: reasonable 08:37:51 david: "flow" could be one of multiple things... 08:38:28 richard: when do we want to talka about case A (on the whiteboard - tbrl flow) 08:38:48 richar: should it be called "block-flow-direction" ? 08:39:08 s/richar/richard/ 08:39:49 elika: when we talk about vertical, we'll say "in left-to-right block flow" 08:40:19 RESOLVED: Molly's proposal accepted 08:40:19 steve: when this replaces property name, do we still say "block flow direction"? 08:40:31 elika: yes 08:43:16 elika: we have a concept of "normal flow" as opposed to out of flow 08:43:39 elika: ... and inline flow direction... 08:44:08 elika: tblr, tbrl = "horizontal block flow" 08:44:26 elika: lrtb, lrbt = "vertical block flow" 08:44:58 steve: bad idea for general terminology 08:45:13 peter: we should always qualify with "inline" or "block" flow 08:45:53 peter: terminology is fine when talking of block flow, not for general discussion where "vertical" means "vertical text" 08:45:57 steve: same objection 08:49:32 elika claims it is a bad idea to use "direction" property in CSS. it should be in html "dir" property because content knows more about its direction 08:49:56 alex is surprised and doesn't yet agree with it 08:50:32 richard: I would use "vertical text mode" even if it isn't text 08:50:43 steve: agree, that is the most common usage 08:52:16 richard: do we need "mode" 08:53:25 alex: in a sentence "in vertical text mode table rows are vertical" - is "mode" necessary? 08:53:43 richard: with "mode" it sounds more specific in terminology 08:53:51 elika: works for me 08:54:31 RESOLVED: "vertical text mode", "horizontal text mode" 08:54:49 richard: So for Mongolian you'd say "left to right vertical text mode" 08:55:03 Bert: I've been using adjective terms mostly 08:55:19 mongolian = "vertical text mode with left-to-right block flow direction" 08:56:02 elika: could say "vertical mode containing block" 08:57:13 elika: ok to use shortened form "vertical block" 08:57:56 alex: define once "vertical block" = "block with vertical text flow direction" 08:59:01 jdaggett has joined #css 08:59:30 daniel: list style "tree" 08:59:38 peter: arron wanted to be on call for that 08:59:54 next topic is CSS Backgrounds and Border 09:00:21 http://dev.w3.org/csswg/css3-background/ 09:01:11 may or may not talk about variables today. it would be good to have apple people for that one. 09:02:18 elika: couple of open issues 09:02:54 -- issue 11: specify which corner offsets are from 09:04:04 (I'm in europe but don't know about variables, I'll ping the other apple folks, but it'll be late in the day if you catch them (for you, that is)) 09:04:17 elika: "background-position: bottom 10px right 25%" 09:04:37 david: what happens when keywords and values are rearranged? 09:05:41 peter: "left 15px" means "0px, 15px" - why? 09:06:02 david: the problem with "bottom right 10px 25%" is, does it mean 10px horiz 25% vert or 10px vert 25% horiz? because currently with coordinates the horiz is always first 09:06:26 david: another way to solve same problem is calc() 09:08:24 alex would find it more intuitive to have a separate property that defines alignment direction 09:08:34 davie would rather leave it to calc() at this point 09:08:50 hakon: can we write an example using calc()? 09:09:30 elika: "background-position: 75% calc(100% - 10px)" 09:09:42 hakon: good case for adding calc 09:09:56 background-position: 75% calc(100% - 10px); 09:10:03 I don't see any reason background-position: 75% calc(bottom - 10px) shouldn't work either 09:11:18 hakon: want inside/outside too 09:11:21 calc(0.25 * start + 0.75 * end) 09:11:33 peter: calc is designed to solve odd cases 09:12:05 peter: you can't build something that depends on direction 09:14:00 saloni: "start + 5px" makes sense 09:14:20 peter: you can't substitute "start" with 0 or 100... 09:14:35 elika: I don't think we should allow keywords in calc 09:14:39 hakon: agree 09:15:27 discussion on difference of start/end and left/right 09:20:45 steve: how do we represent start + 5px? 09:21:02 elika: calc(start + 5px) 09:22:33 background-position: 75% calc(100% - 10px); 09:22:33 background-position: bottom 5px left 45px; 09:22:33 background-position: start 5px top 45px; 09:22:33 background-position: calc(start + 5px) top; 09:22:33 background-position: calc(5px + start) top; 09:22:35 background-position: calc(start + end) top; 09:22:38 background-position: calc(start + bottom) top; 09:22:40 You're going to make Molly cry if you make her do this much math. :( 09:22:43 just to put something in the bottom right corner 09:23:22 (we are looking at examples in http://dev.w3.org/csswg/css3-background/#the-background-position ) 09:23:32 Elika is against putting keywords in calc() 09:23:41 calc(25% + 10px) means you position the 25% point in the image at the 25% + 10px point in the container 09:24:02 The current definition of calc() doesn't allow keywords, so I'm ok with not allowing keywords too. 09:24:07 plinss_ has joined #css 09:26:07 discussion of implementing calc() 09:27:06 background-position: 15px 20% (left top); 09:27:08 (calc() is a fancy notation for a triple (p, q, r) where p is the number of percentages, q the number of ems and r the number of px.) 09:27:14 background-position: 15px 20% (start after); 09:27:41 SteveZ has joined #css 09:28:06 background-position: 0 15px; background-flow: rl-tb; 09:28:55 background-position: [ | ]{2} [ keywords ] {2} 09:31:55 Steve attempting to paraphrase Alex: for writing-mode relative positioning, just add one keyword to make it writing-mode relative 09:32:11 background-position: 15px 20% from-top-left; 09:32:21 RESOLVED: No keywords in calc() 09:32:41 for background-position 09:32:46 background-position: 15px 20% from-before-start; 09:32:49 david: I no longer propose calc() as a solution for RTL background 09:33:19 Richard Ishida draws two images 09:33:38 [ W3C ::: :: : : : ] 09:33:47 [ : : : :: ::: W3C ] 09:35:28 background-position: 15px 20% logical; 09:35:35 it is noted that right-aligned background is possible in CSS2 - "background-position:100%" 09:36:44 ... and then calc(100% - 10px) can handle the right-relative use case 09:39:07 ... to solve vertical, you'd also need background-repeat: repeat-block-progression | repeat-inline-progression 09:39:16 alex: if there is a keyword "logical" it picks one of 4 corners for origin, then tiles normally... 09:39:21 ... and you'd need to make 'logical' on background-position flip the x and y for the vertical case 09:39:48 Elika: ... and you'd also need mirroring / rotating of the image 09:42:22 Corners NW, NE, SE and SW? 09:42:51 background-position: 15px 20% tb-lr; 09:45:52 peter: we don't want to use "top-right" combinations will explode ... "start-right", etc. 09:47:34 hakon supports an additional property that defines origin 09:49:39 david: if there are 8 writing modes, do we need all 8 for background position? 09:49:56 alex: yes, if rotate and mirror are included 09:51:29 Elika: background-remap: absolute | reposition | [ mirror || rotate ] 09:51:53 Håkon: can't live with this 09:52:53 steve: whatever we do should work if image is designed for arabic, then mirrored to english version 09:54:53 steve: the real requirement is for semitic pages to have the same capabilities as western pages 09:56:09 backround-position-mode 09:56:17 background-mode 09:57:52 hakon: why not have a background-offset property? 09:58:26 elika proposes dropping the functionality from CSS3 and taking CSS3 to CR? 09:59:48 fantasai: New proposal: drop background positioning from other corners, push that and border-length to CSS4 BB, publish this draft as WD, then LC/CR around Dec/Jan. 10:03:15 Steve: do we have consensus on using a separate property for defining origin corner? 10:04:07 fantasai: No, because whether I agree with having a separate property depends on what it's defining 10:04:31 fantasai: if we're defining which corner the origin is separate from the offsets, then I don't agree 10:04:37 dbaron: I agree with Elika 10:06:53 Peter: So proposal on the table is to use calc() for positioning from bottom right, and moving on with this draft 10:08:54 Alex: I like Elika's original proposal with bottom and left keywords better than calc() 10:09:47 David: I think I agree with what Alex is saying 10:09:57 David: Take the current set of values, those are still valid 10:10:14 David: Then add to that a syntax for four values 10:11:44 Alex: And it's not allowed to mix logical and physical 10:11:49 Alex: can't mix start and top 10:12:12 Peter: My concern is that it makes the background remap unlikely to work later 10:12:41 Alex: I think this is preferable to dropping values from CSS3 10:12:46 Peter: Are you going to implement this in IE8? 10:12:52 Alex: Unlikely 10:13:09 Alex: If we choose to add something from CSS3 BB in IE8, multiple backgrounds would come much sooner than this 10:18:52 proposal: elika's original version, with restrictions that remove ambiguity 10:19:03 no start/end/before/after in CSS3 10:19:41 (background-position: right 1em 1px bottom 1.4em -1px) 10:19:52 elika shows examples 10:20:28 background-position: left top 10px; 10:20:29 background-position: left 10px top; 10:20:29 background-position: 10px 10px; /* CSS1 */ 10:20:29 background-position: top 10px left 10px; 10:20:29 background-position: left 10px 10px; /* INVALID */ 10:22:31 hakon: what will dom return here? 10:23:06 elika: 4 values 10:23:21 fallback behavior: 10:23:27 background-position: bottom right; 10:23:28 background-position: bottom 10px right 10px; 10:23:44 background-position: bottom right; /* CSS1/2 clients */ 10:23:45 background-position: bottom 10px right 10px; /* CSS3 clients */ 10:24:28 Bert: I want to wait for calc 10:24:46 Daniel: I disagree, I think web authors will not understand calc() 10:25:07 plinss_ has joined #css 10:31:56 resolved: 4-value syntax, two keywords must be present, zero values can be skipped (examples above) 10:32:12 saloni: how about start/end/before/after 10:32:27 I don't think we resolved anything, I think we decided it was unresolved. 10:34:11 no consensus at this point on when start/end are introduced 10:34:26 RESOLVED: new background-position syntax in the draft is ok 10:34:32 I accept the syntax but I want the discussion on start/end to happen soon. 10:36:55 break 10:37:07 Not resolved. Objection from me. 10:38:19 calc() will happen anyway, so don't add redundant syntax. 11:07:40 more BB 11:07:59 elika: there is a proposal to add 'transparent' keyword to border-image property 11:08:11 http://www.w3.org/Style/CSS/Tracker/issues/28 11:08:39 elika: it would complicate the syntax, the image can be made transparent too 11:09:02 david: we can skip it, syntax is complicated enough 11:09:41 peter: it seems a misnomer that border-image includes background, although i see use cases 11:09:51 consensus: no change 11:10:13 RESOLVED: proposal to add "transparent" to border-image is rejected 11:11:00 http://www.w3.org/Style/CSS/Tracker/issues/46 11:11:31 Steve: Why not call it background-position-area 11:12:07 issue 46 -- rename background-origin to background-box 11:12:26 elika: thre is background-clip with same values 11:12:30 peter: sounds consistent 11:12:47 elika: there is background-break property (for page boundaries)... 11:14:33 peter: would expect background-clip to take a rect. should it be background-clip-box? 11:14:40 peter: and background-box 11:15:08 david: don't like bacground-box since there is also two; this is origin for positioning 11:15:17 anne: let's keep it stable 11:16:16 (no strong arguments to making the change) 11:16:50 peter: concern about background-clip - will it interfere with adding a rect clip in the future? 11:17:01 elika: will allow rect in background-clip 11:17:23 steve: background-position-box? 11:18:13 anne prefers to not change; there are implementations already 11:18:16 elika: That's clearer, but my concern is that it breaks the pattern that given properties foo and foo-bar, foo is a shorthand that sets foo-bar 11:18:45 ('background-origin: NE content-corner') 11:19:01 david: ok with changin background-origin; background-clip is fine 11:19:23 ('background-origin' has remained the same since 2002; nobody has suggested something substantially better it seems, otherwise it would've been changed) 11:19:36 s/is fine/is a good name/ 11:19:58 RESOLVED: no change to background-origin/background-clip naming 11:20:32 (Or combine bg-origin and bg-clip into one property?) 11:20:54 elika: added no-clip to background-clip property. marked at-risk. 11:21:14 david: painful to implement... an odd overflow case 11:22:01 elika: no-clip with a no-repeat image overflows the box to however big the image is 11:22:10 steve: what does it do for scrolling 11:22:23 peter: probably should not trigger overflow 11:22:57 alex: if it looks like overflow it should behave like overflow 11:23:08 elika: shadows currently don't trigger overflow 11:23:21 elika: we currently don't define anywhere what triggers overflow 11:24:27 elika: if your element has srollbar and background is scrolled you are allowed to clip to padding edge 11:24:56 saloni: how does overflow background affects other elements? 11:25:09 elika: same stacking order as normal backgrounds 11:26:24 peter: does it belong to the same property? 11:26:56 border-clip: padding-box no-clip 11:27:39 (background-repeat: repeat | no-repeat | repeat-x | repeat-y | no-clip ? Or background-image: url(foo) no-clip ?) 11:27:54 elika notes that no-clip would be marked at-risk 11:28:04 peter: not convinced it is a good idea but if we have to have it I'd prefer a separate keyword 11:28:31 elika: box-shadow property 11:28:56 elika: adding inner shadow -- inset keyword 11:29:17 elika: brad kemper have images for that 11:30:06 david: is the spread feature still in? I know we implement that 11:31:19 elika: want to publish a working draft 11:31:46 david: plan to last call reasonably soon 11:32:21 anne: is border-radius stable? 11:32:30 elika: yes, and we have accepted your proposal 11:33:05 RESOLVED: publish WD 11:37:27 myakura has joined #css 12:38:35 Bert: Can we publish a new working draft of Template Layout that consists of the first section with Template Layout 12:38:40 Bert: with the second and third parts removed? 12:38:51 Bert: Nobody seems interested in the tabbed layout or row-based layout 12:39:41 http://www.w3.org/Style/Group/css3-src/css3-layout/ 12:40:51 Bert: old version http://www.w3.org/TR/2007/WD-css3-layout-20070809/ 12:43:49 Elika: I had a comment that you should be able to assign min/max widths/heights to rows and columns 12:43:54 Bert: there is syntax there for doing that 12:46:29 Daniel: Are implementors interested in this? 12:46:38 Anne, David: we are more interested in flexbox 12:46:54 Howcome, Bert: This has useful things, especially the ability to reorder content 12:47:05 Saloni: How does this fit with the grid proposal? 12:47:12 Bert: they are complementary, they work together 12:47:44 Bert: With the grid module, you establish a grid, but then you need to use top/left etc to position things 12:48:11 Bert: With this you establish the grid and create slots at the same time 12:49:26 ... 12:50:02 Elika: I think Grid is very useful for snap-to-grid 12:50:25 Elika: I think using positioning with grid is not likely to be as robust 12:50:33 Elika: but being able to snap widths/heights to grid 12:50:41 Bert: or float to grid, or space out N items 12:50:45 would be useful for those 12:51:02 ACTION: Bert update CR Exit criteria to latest wording for CSS3 Template module 12:51:03 Created ACTION-98 - Update CR Exit criteria to latest wording for CSS3 Template module [on Bert Bos - due 2008-08-29]. 12:52:02 Topic: Update on changes made by David Hyatt to CSS3 Variables 12:52:02 Latest version of the text: http://www.w3.org/Style/CSS/Tracker/actions/44 12:52:29 Topic: Revisit Issue 14 in CSS2.1 12:53:43 http://lists.w3.org/Archives/Public/www-style/2008Aug/0154.html 12:53:50 http://lists.w3.org/Archives/Public/www-style/2008Aug/0164.html 12:56:30 # The bottom margin of an in-flow block-level element is adjoining 12:56:30 # to its last in-flow block-level child's bottom margin when: 12:56:30 # * the element's specified 'height' is 'auto', 12:56:30 # * the element's used height is the same as it would have 12:56:30 # been if the specified values of 'min-height' and 'max-height' 12:56:32 # were their initial values 12:56:35 # * the element has no bottom padding or border. 13:01:35 Alex: Maybe the bullet about 'overflow' not 'visible' should be generalized to block formatting contexts 13:04:07 Elika adds that as issue 70. 13:06:25 RESOLVED: proposal accepted for Issue 14 13:06:31 Change Vertical margins of elements with 'overflow' other than 'visible' 13:06:31 to Vertical margins of block formatting contexts (such as floats and elements with 'overflow' other than 'visible') 13:06:37 for Issue 70 13:06:46 http://csswg.inkedblade.net/spec/css2.1#issue-70 13:10:00 RESOLVED: proposal accepted for Issue 70 13:10:46 http://csswg.inkedblade.net/spec/css2.1#issue-46 13:10:51 http://lists.w3.org/Archives/Public/www-style/2008Jun/0106.html 13:12:59 David: The issue is that we don't really say how media restrictions work 13:13:13 David: We say that if the @media rule matches, then all the rules inside it apply 13:13:20 David: But we don't say what happens with nesting 13:13:45 David: if you get to a style sheet by multiple links, you don't want to check only the restrictions on the parent link 13:14:09 David: You want to match the media restrictions on all the links 13:14:27 David: Also you want this to work right if you link to the style sheet in multiple places. 13:16:31 Daniel: The last sentence in this proposal doesn't handle media queries 13:16:46 David: This is for 2.1, not CSS3 13:20:41 "The import only takes effect if the target medium matches the media list." <- prepend to last para in 6.3 13:21:45 RESOLVED: Accept dbaron's proposal plus the change above (from plinss). Bert to figure out exact placement etc. 13:23:14 http://csswg.inkedblade.net/spec/css2.1#issue-49 13:23:29 http://lists.w3.org/Archives/Public/www-style/2008Aug/0167.html accepted with s/will more/will be more/ 13:24:49 http://csswg.inkedblade.net/spec/css2.1#issue-62 13:24:53 http://lists.w3.org/Archives/Public/www-style/2008Aug/0168.html 13:25:08 shepazu has joined #css 13:26:06 RESOLVED: Proposal accepted for Issu 62/51 13:29:19 Peter: Melinda raised an issue with the grammar 13:29:46 Peter: rule sets can't contain other blocks 13:31:01 discussion of what 'any' means and whether it is permissive enough 13:33:54 inconclusive 13:34:02 http://csswg.inkedblade.net/spec/css2.1#issue-32 13:35:08 Daniel: I hit exactly the same problem in my source code editor. 13:35:36 Daniel: @ followed by an unrecognized ident will not be recognized as an at-keyword by the parser 13:36:08 David: You shouldn't use Appendix Gs' grammar for parsing 13:36:46 Daniel: If you follow Appendix G you will not recognize @foo as an at-rule. 13:39:48 http://lists.w3.org/Archives/Public/www-style/2008Aug/0165.html 13:40:39 jason_cranfordtea has joined #css 13:44:31 RESOLVED: Proposal by dbaron+fantasai accepted for ISSUE 32 13:45:38 http://csswg.inkedblade.net/spec/css2.1#issue-35 13:48:42 Issue described by 13:48:43 http://lists.w3.org/Archives/Public/www-style/2008Jan/0432.html 13:48:44 and 13:48:48 http://lists.w3.org/Archives/Public/www-style/2008Mar/0026.html 13:49:11 Daniel: I see your point, David, but I think if web authors specify all four offsets they will expect the replaced element to stretch to fit 13:51:20 David: I think this would become the only case where a replaced element with width and height auto would behave differently from a non-replaced element with explicit width and height. 13:51:35 ...and I'm also unsure whether we should be changing the spec at this point because we don't like what it says. 13:54:35 Elika: I think we should make this change for replaced elements without an intrinsic size 13:54:47 David: I don't want to half-make this change. I'd rather either make it or not. 13:54:51 yt? 13:54:52 Elika: The results for http://fantasai.inkedblade.net/style/tests/issues/abspos-replaced-intrinsic-unsized -- using 300px by 150px 13:54:57 Elika: really don't make any sense at all 13:58:35 Seem to agree that this change would make sense for authors, other questions remain 13:58:44 Peter: Would this break existing content? 13:59:01 Peter: IIRC WebKit tried to match the spec here and ran into broken content 14:02:33 discussion between Bert and Peter 14:05:53 everyone tries to convince Bert that flexing auto makes more sense than ignoring a specified offset 14:09:51 Bert is not convinced 14:10:53 Straw Poll: Do we make an absolutely-positioned replaced element with intrinsic size stretch/shrink to fit if all four offsets are specified 14:10:56 ? 14:12:21 Discussion about interoperability 14:13:54 Howcome: It's not worth it to fix it. You can fix this today by setting the width. But we already have interoperability on the currently-specified behavior 14:14:10 Alex: If we change this in the spec, would FF3 fix it? 14:14:19 David: Not for 3.0, but perhaps for 3.1 14:14:50 David: Not saying that we'd necessarily have time to change it, but that we'd be willing to 14:16:19 Howcome: I'm not really convinced that this is worth changing from being interoperable to perhaps years of not being interoperable 14:16:26 Howcome: I think we're taking a risk there. 14:16:30 Howcome: I'm a skeptic 14:16:35 David: Abstain 14:16:40 Daniel: In favor 14:16:45 Saloni: Change 14:16:47 Richard: abstain 14:16:50 Steve: abstain 14:16:53 Peter: in favor 14:17:01 Alex: mixed feelings. I see perfect interop here 14:17:07 Alex: We can improve it, but why 14:17:21 Alex: No change 14:17:25 Bert: No change 14:17:56 Elika: no strong opinion, change iframe not image 14:18:19 Anne: seems there are enough other ways to get this effect that we can address this case using other means 14:18:22 Anne: So I would say no change 14:18:26 From what I have just read I would say no change 14:19:59 Daniel: No consensus at all. 14:20:17 Daniel: So we'll have to say no change. 14:20:35 Elika: Can we undefine the behavior for iframes? 14:26:02
14:30:13
14:35:42 Daniel: I want to discuss the charter and also to report on Variables 14:35:50 Topic: Charter 14:36:01 Philippe: I looked into the charter 14:36:08 Philippe: Listent to you for past three days 14:36:19 Philippe: Don't have any significant changes to suggest. 14:36:20 http://www.w3.org/Style/Group/2008/draft-charter2.html 14:36:41 philippe: I changed the online version of it this afternoon, some minor changes but perhaps they are major for some people 14:36:50 Philippe: We changed success criteria 14:37:59 Philippe: to be relative to each feature instead of each deliverable 14:38:34 Bert: In some cases you might want per-feature, in some cases per-deliverable 14:38:51 Bert: For example with a profile you don't want each feature you want the whole thing 14:40:35 Philippe: My intention was to make it less restrictive. 14:41:04 Philippe: So that you can choose to target the whole deliverable, but in other case you can also target each feature 14:42:06 Philippe: I didn't see any need to call out the W3C RECs for QA Framework, Charmod, Web Architecture 14:42:15 Philippe: We just expect everyone to follow the RECs 14:43:02 Philippe: Removed sentence about minutes being public because that is redundant with the top part of the charter, which says proceedings will be public 14:43:57 Philippe: Removed paragraph saying that we follow Section 3.4 Votes because the previous sentence adds extra restrictions 14:45:36 Philippe: Some concerns about your process. 14:45:47 Philippe: Your Decision Policy requires making decisions only during group meetings 14:47:36 Philippe: And the quorum requirement ... 14:47:56 "When deciding a substantive technical issue" should have "by formal vote" at the end. 14:47:58 Elika: The Decision Policy paragraph seems to impose the 2/3 quorum requirement on allt echnical decisions 14:48:05 Elika: Not just for formal votes. 14:48:16