07:06:06 RRSAgent has joined #css 07:06:06 logging to http://www.w3.org/2017/08/03-css-irc 07:06:08 RRSAgent, make logs public 07:06:11 Zakim, this will be Style_CSS FP 07:06:11 Meeting: Cascading Style Sheets (CSS) Working Group Teleconference 07:06:11 Date: 03 August 2017 07:06:11 ok, trackbot 07:06:47 Bonjour to Zakim, RRSAgent, and trackbot 07:10:48 bdc has joined #css 07:12:25 dauwhe_ has joined #css 07:17:23 Florian has joined #css 07:18:31 ericwilligers has joined #css 07:19:03 bdc has joined #css 07:20:45 present+ 07:20:48 present+ 07:20:56 present+ 07:21:06 present+ Myles 07:21:08 present+ 07:21:09 present+ 07:21:10 present+ Surma 07:21:12 present+: Myles 07:21:20 ScribeNick: fantasai 07:21:38 present+ bdc 07:21:45 present+ dauwhe 07:22:33 gregwhitworth: Issue wrt replaced elements as table cell 07:22:37 https://github.com/w3c/csswg-drafts/issues/508#issuecomment-317529294 07:22:43 present+ 07:22:45 present+ 07:23:01 Topic: replaced elements as table cells 07:23:03 gregwhitworth: We added a diagram of what the spec says to do 07:23:08 github: https://github.com/w3c/csswg-drafts/issues/508 07:23:14 https://github.com/w3c/csswg-drafts/issues/508#issuecomment-260486721 07:23:31 dgrogan has joined #css 07:23:33 gregwhitworth: Made a table of results 07:23:46 glazou has joined #css 07:23:59 gregwhitworth: what we tried to do, where it behaved more like block, specified to be as block 07:24:08 gregwhitworth: if behaved more like inline, specified as inline 07:24:12 gregwhitworth: we dont' have a strong pref 07:24:24 gregwhitworth: This is 1st to discuss 07:24:42 dgrogan: WE talked about this in Chrome, don't want to defend our behavior. I todesn't make much sense 07:24:57 gregwhitworth: For firefox, we prefer firefox behavior 07:25:11 gregwhitworth: It seems like author did something wrong, so make it more obvious it's wrong 07:25:22 dbaron: One question here is do you do anonymous box construction around these things 07:25:26 gregwhitworth: 07:25:29 gregwhitworth: no 07:25:38 dbaron: Do you think some of these results are because of anonymous box construction? 07:25:59 gregwhitworth: they don't create separate cells 07:26:08 present+ 07:26:11 fantasai: They wouldn't, if they did anonymous box construction ...? 07:26:16 gregwhitworth: ... 07:26:39 gregwhitworth: So besides Chrome having pref, anyone else? 07:26:45 tantek has joined #css 07:26:52 svillar has joined #css 07:27:01 Rossen: So path forward is to fall back to Firefox's behavior? 07:27:19 tantek has changed the topic to: Paris agenda: https://wiki.csswg.org/planning/paris-2017#topics, logs: https://logs.csswg.org/irc.w3.org/css/today 07:27:27 fantasai: Seems to me that making it block would make more sense 07:27:36 present+ 07:27:49 fremy: Wouldn't be Web-compatible 07:27:55 present+ 07:27:58 gregwhitworth: Any objection to resolve on Firefox's behvaior? 07:28:19 RESOLVED: All internal table displays on replaced elements to behave as 'inline'. 07:28:31 RESOLVED: table falls back to block, inline-table falls back to inline 07:29:02 tantek: Point about anonymous box construction, are there tests ? 07:29:10 gregwhitworth: I'm sure we have tests for it somewhere 07:29:46 tantek: ... 07:29:54 fantasai: What do you mean anonymous boxes don't get constructed? 07:30:22 dbaron: Do individual things create individual table cells, or group together into one cell 07:30:28 svillar has joined #css 07:30:41 dbaron: Do different things depending on row-group vs table-cel etc 07:31:03 tantek: Based on what dbaron said, maybe just copy what Firefox does 07:31:16 present+ 07:31:49 The resolution is specific about what the behavior is 07:31:50 fantasai: If it's defined as "behave as inline", then anonymous box construction is defined 07:31:58 dbaron: Could do anonymous box before, rather than after treating as inline 07:32:01 ... and it is not "just repeat what Firefox does" 07:32:07 fantasai: That would end up with improper table structures, which the spec does not allow 07:32:38 Topic: min-width and percentages on table cells 07:32:42 github: https://github.com/w3c/csswg-drafts/issues/607 07:32:49 fremy: Next issue is min-width and percentages 07:32:59 https://github.com/w3c/csswg-drafts/issues/607#issuecomment-317532741 07:33:17 fremy: width behaves as min-width on tables, so it's a bit redundant 07:33:43 fremy: Browser generally ignore min-width of percentage, except Firefox 07:33:45 present+ 07:33:57 fremy: Would like to ignore percentages 07:34:10 dbaron: Would like to explain why percentage on min-width overrides width 07:34:16 dbaron: That's the general behavior of tables 07:34:40 dbaron: If a column has cell that's a lenght and cell that's a percentage, it ignores the length instead of the percentage 07:34:51 fremy: We should go with the more interop solution 07:35:00 fantasai: What about fixed tables? 07:35:35 Rossen: What would be different? 07:35:53 fantasai: widths aren't "minimums" in fixed layout, they're honored and the content of the cell doesn't matter 07:36:02 fantasai: I would expect min-width and width to interact as for blocks in that case 07:36:16 Fixed layout for table cells is the same as in normal 07:36:40 the only difference is that the overall column sizing and distribution is based on the first row only 07:36:41 fremy: Our goal was to spec most interoperable behavior 07:36:57 fremy: So we should go with the non-Firefox behavior 07:38:08 fantasai: But what about fixed tables 07:38:22 Rossen: You do the layout based on the first row 07:38:52 fantasai: ... 07:39:05 dbaron: fantasai is saying that in fixed table layout, you honor the width even if the contents overflow 07:39:23 fremy: It's true content overflows even i nthe first row, but that's not the problem 07:41:31 fremy: But if you have a table and you set 300px on the table and 100px on the two columns, then you get 150px columns 07:41:39 fantasai: but we're talking about a different case 07:42:09 https://jsfiddle.net/gvco0t54/2/ 07:42:47 fremy: min-width % on fixed tables is ignore 07:42:55 glazou: Is your goal only interop? 07:43:23 fremy: Yes, all browsers except Firefox ignore the min-width 07:43:41 glazou: Yes, but you haven't considered the user's perspective. From the perspective of the Web author, why would you ignore min-width? 07:44:04 s/min-width/min-width percentage only on these elements/ 07:44:15 fremy: I don't think there's a strong reason, except this is what browsers do. 07:44:27 fremy: No good reason not to do it, except we have multiple impls 07:44:32 glazou: Web browsers can be wrong 07:44:46 glazou: It's not all browsers, there's at least one that implements it 07:45:06 astearns: It's been here for decades 07:45:19 glazou: It's been in Firefox for decades too 07:45:27 dbaron: We do get requests from authors to make these things work in tables 07:45:40 dbaron: e.g. we get requests for max-width to work, but that's a bit harder 07:46:35 dbaron: It's weird to try to honor web author requests for new features, but here where we have the feature they want, we decide not to have it because it only works in one browser not four 07:47:00 Florian: we have evidence that the Web doesn't break if you don't support min-width, but we also have evidence that it doesn't break if you support it 07:47:19 gregwhitworth: The only reason we're working on this spec is because we'll try to fix a bug and other sites will break 07:47:35 gregwhitworth: I guarantee you that there are websites that are broken if 3/4 browsers have interop 07:48:11 fantasai: ... 07:48:20 fremy: In tables widht works like min-width 07:48:31 fremy: The author doesn't lose anything here 07:48:49 fremy: I don't buy that we are bothering authors, if you want to use table you would learn to use width 07:49:01 fremy recites history of widths 07:49:05 and HTML 07:49:14 glazou: The problem is with "authors should learn CSS' 07:49:26 gregwhitworth: Your assertion is also that authors should test in Firefox, and we know they don't 07:49:42 gregwhitworth: We put opening in the spec, .. 07:49:52 gregwhitworth: 3 browsers are shipping this way, that's the de facto standard 07:50:56 fantasai: ... 07:51:17 fremy: ... doesn't work 07:51:51 fantasai^: You have to consider what browsers do but also what makes sense. 07:52:14 fremy: min-width and widht are just widths 07:52:18 fantasai: except in fixed tables 07:52:23 dbaron: please add tests to WPT 07:52:44 s/please/I guess I'm OK with this, but please/ 07:53:08 glazou: I can live with it, but I find it regrettable 07:53:23 Rossen: Proposed that min-width: % is ignored on table cells 07:53:33 RESOLVED: Ignore percentage min-widths on table cells 07:54:13 Topic: resolution of percentage heights on children of table cells 07:54:17 https://github.com/w3c/csswg-drafts/issues/474#issuecomment-317544515 07:55:03 fremy has joined #css 07:55:28 fremy: Bit of history 07:55:38 fremy: 1st issue is that Firefox for a long time had very different usage for height on table cells 07:55:50 fremy: Height on table cells was applied on table cell not on row 07:56:02 fremy: But earlier we resolved that height on table cells is applied to th row 07:56:06 fremy: That change was not made in Firefox 07:56:20 fremy: For that reason, firefox does very different resolution of % on table cells 07:56:25 fremy: All other browsers have similar behavior 07:56:39 fremy: Which is 1st computation of layout, cell doesn't have any size, so % is treated as auto 07:56:44 fremy: Then you do a 2nd layout pass 07:56:54 fremy: In this case, all browsers will apply the percentage based on size assigned to the row 07:57:03 fremy: Which is also assigned to all cells in the row 07:57:18 dbaron: Is it interoperable when you do the 2nd pass and when don't bother with 2nd pass 07:57:29 fremy: We always do 2nd pass when there's a % 07:57:32 dbaron: that's not what I found 07:57:41 fremy: Testcases we wrote gave identical results 07:57:46 fremy: One exception unfortunately 07:57:56 fremy: In Chrome, if you set overflow: scroll on an element 07:58:34 fremy: Rule in CSS, if size is auto and you're allowed to scroll, automatic size is smallest size possible such that you don't need to scroll 07:58:38 fremy: That's in general for CSS 07:58:42 fremy: This is what edge implements 07:58:48 fremy: But not web compatible, because this is not how it works 07:58:57 fremy: In that case, in the 1st pass the auto sie is considered 0px 07:59:04 fremy: So in 2nd pass you are going to have a scrollbar 07:59:16 fremy: The scroller will match the size of the rest of the cells in the row 07:59:38 fremy: In Firefox, because you resolve percentage based on the height set on the cell, you get exactly the same behavio 07:59:47 fremy: because 1st pass in Firefox, you already know your percentage 08:00:01 fremy: Edge is outlier, because we don't give the same behavior 08:00:12 fremy: So we propose that we match Chrome behavior, because Web interop requires it 08:00:18 fremy: Canonical example is ToS 08:00:54 fremy: People set height 100% on scrollabe ToS, and then button to accept in the next row 08:01:04 fremy: In Edge the 1st row blows up and gets as big as needed to contain entire ToS 08:01:32 fremy: So we would like to resolve on doing what Chrome is doing 08:01:41 fremy: If you're allowed to overflow, your automatic size will be 0px 08:01:49 fantasai: And that's for a table cell? 08:01:53 fremy: Percentage is set on the child 08:01:57 of the table cell 08:02:07 second testcase in https://dbaron.org/css/test/2006/percent-height-in-tables 08:02:10 dbaron: You claimed that you always do 2nd pass, so I loaded testcase and loaded in Chrome 08:02:26 dbaron: And I got as far as the 2nd testcase in the set before finding a contradition with your assertion 08:02:38 08:02:38 08:02:38 08:02:38

25% height div

text

08:02:49 fremy: % doesn't get applied 08:02:57 fremy: % inside auto container is ignored 08:03:02 dbaron: Except that's not how it works in tables 08:03:13 dbaron: there are things in tables that can make things non-auto height, that don't match that CSS rule 08:03:26 fremy: Rule in CSS is extended 08:03:42 fremy: You need at least one table element with a height defined 08:03:49 fremy: that isn't a percentage 08:04:25 dbaron: If you define height on table itself, then ... 08:05:09 s/extended/extended in css-tables-3/ 08:07:13 fremy: "It is appropriate to resolve percentage heights on direct children of a table cell if the cell is considerd to have its height specified xplicitly or the child is abspos, see CSS2. It is futher clarified that a cell is considered to have its height specified explicitly if the computed height of the cell or any of its table ancestors is a length or percenage and that length does not "bheave as auto"" 08:08:00 s/bheave/behave 08:08:57 fremy: Cases where we don't have interop are on tbody we don't all behave the same way 08:09:10 fremy: but agreed we'd behave the same way on tbody, so fixing that issue every browser should behave the same 08:09:26 Rossen: Interop with firefox? 08:09:31 fremy: Firefox has a different model 08:09:41 dbaron: We have tests if any cell in a row has a specified height 08:10:00 dbaron: The code that decides whether hegihts are definite looks at whether there's any cell in the row that has its height specified 08:10:09 dbaron: So I wouldn't blow that all off as having not implemented that decision 08:10:24 Rossen: So what is the proposed resolution to this issue? 08:10:32 fremy: the stuff I just quoted 08:11:23 fremy: "During first pass, percentages are resolved as auto, except if they are height-related and used on a scrollable box, in which case they resolve as 0px. Edge changes its behavior, as well as Firefox once it fix the other bug." 08:11:27 https://github.com/w3c/csswg-drafts/issues/474 08:11:44 fremy: To explain behavior in dbaron's testcase 08:11:47 fremy: ... 08:12:21 fremy: Like other places in CSS, you don't apply percentages if you're in auto height. For tables it's more complex, looks at table ancestors 08:12:31 dbaron: Is this also interoperable when tables are paginated for printing? 08:12:40 dbaron: Because I know that the behavior is dfiferent when tables are paginated. 08:12:49 fremy: I haven't tried printing tables... 08:13:03 fremy: Why would it be different? 08:13:07 dbaron: Shouldn't be but in Gecko it is 08:13:58 fantasai: Consideration for printing, maybe. When printing you can't scroll, so if you can size the item to show all its content that's better. 08:15:12 Rossen: So should we resolve? 08:15:20 dauwhe has joined #css 08:15:20 dbaron: I'm still trying to understand some of these cases... 08:15:58 dbaron: I'm okay with resolution for now, if I think it's wrong I'll reopen 08:16:10 Rossen: Objections? 08:16:19 RESOLVED: Accept proposed resolution for #474 08:17:02 dbaron: afaict, 1st testcase that I found a difference between FF and Chrome is where FF does what you say and Chrome doesn't 08:17:40

08:17:40 blah
08:17:40

hello

08:17:40

hello

08:17:41 blah
08:17:41 blah
08:17:41

08:17:49 dbaron: There's an outer table 08:17:54 dbaron: Inside of it there's two cells 08:18:03 dbaron: 2nd one is empty but has explicit height of 200px 08:18:10 dbaron: In your model means row has 200px definite height 08:18:26 dbaron: other cell has ... 08:18:36 dbaron: In Gecko, we honor the height 50% on the div 08:18:50 dbaron: and also on the table but the table overflows the cell (??????) 08:19:03 fremy: There is no reason for a table to behave differently from a block here 08:19:27 dbaron: So the thing we just resolved on is not what Chrome and Edge do 08:19:49 dbaron: matches Firefox better 08:19:53 dbaron: Which I'm okay with :) 08:20:17 dbaron: testcase is the 2nd one after the horizontal rule 08:20:55 ... 08:21:07 fremy: You look for a definite height on the ancestors 08:21:18 fremy: ? does not apply 08:21:44 dbaron: ... 08:21:48 dbaron: ok whatever 08:22:13 dbaron: Web will probably end up with one layout engine by the time we get around to fixing this... 08:23:20 Topic: excess width distribution in fixed layout 08:23:23 s/dbaron: Web will probably end up with one layout engine by the time we get around to fixing this...// 08:23:23 https://github.com/w3c/csswg-drafts/issues/484#issuecomment-317943064 08:23:41 gregwhitworth: Doign excess width distribution of space 08:23:54 gregwhitworth: Edge and Mozilla render the same 08:24:00 gregwhitworth: We do same distribution as non-fixed mode 08:24:07 gregwhitworth: We wanted an actual resolution 08:24:12 gregwhitworth: Chrome team said they're ok with the change 08:25:17 dgrogan: we're okay with caveat that we check web compat data 08:26:17 topic: visibility collapse: clip or not to club 08:26:21 s/club/clip 08:26:27 gregwhitworth: Talked about this at TPAC 08:26:31 gregwhitworth: Specified Edge behavior currently 08:26:37 gregwhitworth: To not get rid of data 08:26:45 gregwhitworth: But when author asks for visibility collapse on column or row 08:26:50 gregwhitworth: They've asked that row or column to be gone 08:27:23 gregwhitworth: If you have a spanning cell that goes into the collapsed column/row, then clipped to visible columns/rows 08:27:39 fantasai: I think that's what's in the spec. Not really that great 08:27:47 gregwhitworth: FF overflows the content 08:27:54 gregwhitworth: Behind a flag in Chrome 08:28:05 dgrogan: We also clip to border box. Behind a flag 08:28:27 fantasai: I thin there were two options we were considering here, and overflowing was definitely not one of them 08:29:52 fantasai: ... 08:30:12 dbaron: This would ... 08:30:26 https://jsfiddle.net/v23h0338/ 08:30:46 gregwhitworth explain the demo 08:31:21 dbaron: Suppose before collapsing ou have a cell here and it's part of 3 rows that are conceptually here 08:31:31 dbaron: cell has some content which overflows in theses various directions 08:31:36 dbaron: And then you collapse the middle one 08:31:44 dbaron: When it's not collapsed, these overflow visibly 08:31:54 dbaron: Are you saying when its collapsed, we only draw... 08:31:58 dbaron: I'm collapsing the middle row 08:32:09 gregwhitworth: You only draw what's in the first / third cells 08:32:24 [drawing on whiteboard, behind Bert, can't be captured for minutes] 08:33:22 fremy: If you're clipping the middle row, do you draw the content in the 1st and 3rd rows, or do you show the 1st and 2nd rows and clip out the end 08:33:52 dbaron: Once you collapse the middle row, you're clip everything that overflows the top and you're clip out stuff [over there, over there nobody is telling me what that means and I can't see it] 08:33:59 gregwhitworth: This is an edge case 08:34:23 gregwhitworth: Haven't seen people hiding rows/cols except in data grids, and ... 08:34:33 gregwhitworth: What you're proposing is complicated 08:34:41 dbaron: If it's not a use case why clip anything? 08:34:45 Rossen: That is the use case 08:34:59 Rossen: Your primary purpose was to have a layout 08:35:07 Rossen: We go to extreme lengths to avoid overflow 08:35:13 Rossen: To make sure that all content is displayed inall cells 08:35:27 Rossen: Then you have user facing behavior that allow ppl to collapse things away, purposefully make things appear or disappear 08:35:48 Rossen: When they explictily aske for something to disapear, and you continue to show them what disappeared, weird no? 08:35:55 dbaron: I just meant don't clip this cell 08:36:20 gregwhitworth: In dbaron's example ... 08:36:32 https://jsfiddle.net/dgrogan/9uduq99L/3/ 08:37:14 gregwhitworth: If you collapse 08:37:27 gregwhitworth: we end up clipping in both axes 08:37:50 gregwhitworth: My statement ot dbaron is, he forcefully asked for no wraps which will overflow 08:38:01 gregwhitworth: I don't see circumstances where it isn't primariy the excel-based scenario 08:38:16 gregwhitworth: this is the most performant way to accomplish, which is clipping to bounding box 08:38:20 gregwhitworth: weird side effect 08:38:33 dbaron: Proposal is that if you have a cell that spans some collapsed rows or columns 08:38:42 dbaron: that cell clips its content to its resulting bounds 08:38:43 gregwhitworth: yes 08:39:48 RESOLVED: cells spanning collapsed rows/columns are clipped to their resulting bounds 08:39:52 (in both axes) 08:40:12 Rossen: Goal of work on this spec is to minimize interop pain 08:40:16 Rossen: not trying to rewrite history 08:40:30 Rossen: issues aren't introduced, we're trying to write out the path of least resistance 08:44:09 https://lists.w3.org/Archives/Public/www-style/2016Nov/0069.html 08:44:11 bdc has joined #css 08:50:24 svillar has joined #css 08:51:45 nigel has joined #css 08:56:43 rachelandrew has joined #css 08:59:20 ScribeNick: eae 08:59:26 bdc has joined #css 08:59:29 Topic: Automating Test Coverage 08:59:53 gregwhitworth: I was planning to have this discussion with Geoffrey and Tab at some point. 09:00:18 gregwhitworth: When we were working through table tests I was going through all anchor tags to get an idea of test coverage. 09:00:31 Gecko bugs on implementing the results of our previous discussion on tables: https://bugzilla.mozilla.org/buglist.cgi?bug_id=1386981%2C1386982%2C1386983%2C1386985&list_id=13708350 . If it's not in that list, I don't know about it. 09:00:31 gregwhitworth: It was pointed out to me that I can't depend on the anchor tags as they change for various reasons 09:00:49 gregwhitworth: Basically from what I could see there is a fundamental problem, we're waiting until CR until doing a review of all tests 09:01:01 gregwhitworth: We need to keep these things up to date as we go 09:01:24 gregwhitworth: We could add an automatic solution, maybe in bikeshed. 09:01:34 gregwhitworth: We could either anchor any line or sub anchors. 09:01:44 gregwhitworth: Espeically for things like MUST and SHOULD 09:02:07 gregwhitworth: We need to resolve normative changes that have corresponding tests. 09:02:21 gregwhitworth: Would slow down the process. 09:03:01 gregwhitworth: When you make a change include a test collateral. Two action items: 1) For normative changes to coincide with test collateral. 2) some kind of work to bikeshed to aid in this. 09:03:28 gregwhitworth: To prune as we go. Additionally worth considering that all specs would have a test QA editor 09:03:45 gregwhitworth: We've seen the benefit of this at Microsoft. 09:04:04 astearns: When you went through the flexbox tests manually did you find that the anchor tags where not sufficient 09:04:25 gregwhitworth: Too broad. Requires reverse engineering to find the right section. 09:05:00 astearns: For prior art, in terms of more specific anchor. You might want to take a look at the WOF spec. Has anchors for all. 09:05:10 s/WOF/WOFF/ 09:05:19 TabAtkins: Very easy to do in BS. Wrap everything in an assert tag. 09:06:14 fantasai: Specs do change and the individual sentences that are associated with a particular test isn't stable. Automated association will result in broken links. 09:06:24 TabAtkins: Manually associating isn't practical either 09:06:56 astearns: If automated we cna show that this anshor change, anything associated with it must change. Automation can give us a checklist that is a subset rather than a full set. 09:07:09 dbaron: The actual assertion often brings in other defintions. 09:07:38 gregwhitworth: I agree, you cannot fully depend on this to solve our tesitng needs. We need to resolve that when you make normaitve changes there is also a test change. 09:07:54 gregwhitworth: I want to be able to run the test suite to know what changed. 09:08:39 astearns: You claimed this would slow down the process. I don't think this is true. You had to manaully do this for flexbox, if we can automate it it might be faster. Would speed up feedback for changes if it came with tests. 09:09:01 q? 09:09:06 Florian: Not sure this is true, it takes at the very least many months to get anyone to take review. 09:09:18 Florian: For mutlicol for instance it might take years for the review. 09:09:22 q+ 09:09:38 Florian^: Maybe for high-priority specs like grid or flex, you get the review quickly, but 09:10:20 Rossen: The problem is from what I have observed, a spec goes through an idea phase, someone is excited. A lot of people are talking about it then disucssion starts in the domain. Veyr few people are participating in topic. Then we get to bikeshedidng names, everyone is involved. This is the best part. Then we're in a no-mans land where we want to start implementing but there are no tests. 09:10:40 Rossen: This is the part where no body wants to participate. 09:10:41 Rossen: Then we have someone who starts implementation. 09:10:55 s/no body/nobody 09:11:17 Rossen: If there are no tests that are there to verify the asusmptions. Then we start making up our own assumptions. Then when the next implemtor comes along there are a lot of interop issues. 09:11:50 Rossen: Then we find ourselves here a few years later wondeirng about min-width for table cells, for instance. This happens when the test was written as a part of the implemtation. 09:11:50 s/implemtor/implementor 09:11:53 q? 09:12:11 Florian: I want tests. I like tests. I write a lot of them. And I harass people to review them. 09:12:17 q+ 09:12:52 Florian: People *should* write tests with spec chnages, yes. I agree. Requiering tests for all changes, maybe not so much. Would slow down process *a lot*. 09:12:59 Florian: I wrote a bunch of UI tests, fantasai finally reviewed them a year later after I ambushed her after dinner last night. 09:13:43 ack ericwilligers 09:13:57 ack dbaron 09:14:23 dbaron: A bunch of specs at the whatwg, about 3-6 mo ago tried to do more test driven. Feedback form that is that they're moving faster than before. 09:14:26 ack gregwhitworth 09:14:56 gregwhitworth: Florian, I think that is a valid point. Important that when we sign up for a spec we're not only signing up for the spec, you are also signing up for tests as well. 09:15:13 gregwhitworth: If no-one wants to sign up for QA then that is a problem. 09:15:43 gregwhitworth: It's fun to work on spec. Not as fun to review test changes or star writing tests. 09:15:54 q? 09:15:55 gregwhitworth: Important that the QA people are here as well. 09:16:12 q? 09:16:47 fantasai: One advantage of QA not being here is is that if the spec is not clear then the QA person cannot infer from discussion. Validates that the spec is clear. 09:17:02 Florian: We should assign people to be in charge of the test suite. Hard to find volunteers. 09:17:24 Florian: If we're explicit about ownership we'll see spec that lack a QA owner 09:17:36 (That said, i'm all for having more QA involvement in this process. We've historically had that back when Opera and Mozilla had dedicated QA persons, and we've lost that along the way.) 09:18:08 Rossen: We started three months ago to move a nch of specs that we belive as a working group to be close to rec. Fonts, for example, was one awesome example of a spec that got a lot of attention. A bunch of tests added to it. Reviewed. This spec is now moving very quikcly compared to other. 09:18:34 Rossen: On the other hand, we have background and borders, needs tests from mozilla.. Cascade-3 needs tests from mozilla. 09:19:30 Rossen: Two more specs where we are waiting for tests. Specs that have been in the works for years. Specs that are already implemented and have been for years. Holding us back. We're missing tests. We don't even have the data to start the discussion around whether we're interopable. Holds up the process. 09:19:47 q+ 09:19:50 Rossen: Those specs, that could have been recs, arguably years ago. Will not be rec for years to come due to lack of tests. 09:20:02 fantasai: We need more dedicated QA. We've had that in the distant past. 09:20:05 q? 09:20:33 fantasai: We don't really have that as much as we need. We have Greg, wokring on some stuff, Florian is working on some tests. Japan doing it for writing mode. Only a little bit here and there. 09:21:02 fantasai: Having we and Tab and I having QA ownership for everything is not scalable nur reasonable. Need more people involved. 09:21:04 q+ 09:21:05 Rossen: This is correct. 09:21:24 Rossen: You (Tab + fantasi) are not the only ones who should be doing this 09:21:30 ack glazou 09:22:03 glazou: This is a really old problem/. We're all implementros here. Some people do not consider it as rewarding. We've always had this problem where we've relied on the work of ???. 09:22:20 fantasai: We've not always had this problem. Years ago we had people that were interested in this. 09:22:31 q+ 09:22:33 Tab: We should make daniel the QA owner for all specs :) 09:23:24 Any decision made here relies on the commitment from corporate members of this group. 09:23:26 +1 to glazou 09:23:33 s/Any/glazou: Any/ 09:23:52 s/group/group to commit resources for testing to this group, not just send people to work on specs and implementations/ 09:23:54 Rossen: I agree this is an old problem. Not the easiest to solve. I think most implementors companies have solved this problem years ago. 09:23:58 glazou: Internally. 09:24:30 Rossen: Internally. The spec writer knows how this is supposed to work. Commit your spec to an repo without review. 09:24:35 fantasai: that is what editors draft is for 09:24:44 q? 09:24:46 s/of this group/of this group to dedicate participating engineers' time to write tests FOR THE WG, which they don't atm/ 09:24:48 (ED = repo without review) 09:25:02 Florian: If we have a resolution. We have a spec change, where am I allowed to commit that. 09:25:15 q+ 09:25:21 Rossen: As soon as someone starts implementing your working draft they will stare review your tests. 09:25:37