- From: Daniel Glazman <daniel.glazman@disruptive-innovations.com>
- Date: Wed, 01 Apr 2009 19:18:29 +0200
- To: "www-style@w3.org" <www-style@w3.org>
http://www.w3.org/2009/04/01-css-minutes.html Action items: ------------- howcome fantasai : come up with proposal for multicol wrt column and page breaking fantasai : add UTF-8 header to test suite build scripts Raw minutes: ------------ 01 Apr 2009 Attendees Present dsinger, plinss, fantasai, glazou, anne, arronei, sylvaing, David_Baron, CesarAcebal, Howcome, Melinda_Grant, SteveZ Regrets Bert, Tona, Molly Chair Peter Linss Scribe glazou Contents * Topics * Summary of Action Items <dsinger> Is this co-ed student services? fantasai, we have a lot of noise coming from your phone <fantasai> glazou, ok muted ScribeNick glazou <anne> scribe: glazou plinss: additions to agenda ? howcome I got your note ? <fantasai> http://www.bradclicks.com/cssplay/border-image/Thinking_Outside_The_Box.html fantasai: brad kemper's proposal for border-image <dsinger> Steve z and i reached agreement <dsinger> Later in call if time... agenda item 1 : test case selector issue http://lists.w3.org/Archives/Public/public-css-testsuite/2009Mar/0002.html <dbaron> I haven't read Brad Kemper's proposal yet; it didn't work very well when catching up on my email on the airplane... plinss: had a chance to read the thread ? glazou: I did ... Bert summarized the issue, XML cannot make an attribute start with a digit anne: yes, impossible <sylvaing> invalid, even anne: it's even invalid in html as well <arron> (that was arron) arron: I totally agree the case is an invalid case but we have a problem where we cannot test invalid scenarios ... this has to be valid xhtml arronei: so how do you test invalid scenarios ... how do you test an attribute starting with hyphen, valid scenario ? anne: you can't arronei: the spec needs to change to remove this restrictions or ... dbaron: the rule is testable ... you can test with another rule arronei: still, you can't test an attribute starting with an hyphen dbaron: find another language where it is allowed arronei: test suite is xhtml <fantasai> dbaron: or don't worry about it dbaron: we're looking in interoperable implems in languages applying to css arronei: I understand but how do you test that hyphen scenario ? which language ? dbaron: we don't test it, untestable requirement ... we can test that it's an accepted selector with another valid selector in same rule ... just like p, :not(p) arronei: but we cannot prove which selector matched <fantasai> dbaron: just like p:not(p), wher eyou can't prove that it doesn't match anything arronei: no way to prove that thx fantasai arronei: then you have an ambiguous testcase dbaron: in theory an implem could harcode the response and pass CSS test suite anne: 2 tests with one having two selectors ina rule and another with only one arronei: dependency issue ... we end up with a dependency chain <fantasai> dbaron: but that implementation doesn't remotely implement CSS anne: not a problem ... at least with html5 you can have attribute with a leading dash ... I think digits too arronei: that would handle the valid case ... the invalid has probably no good way of testing sylvaing: you never really select because it's alrady dropped ... spec says there is syntax error anne: you can match using an escape plinss: perfectly valid css if you escape ... should still not match siince the attr is not in the DOM arronei: we need a markup language allowing that attribute anne: two pbs : syntax error and limitations of markup arronei: with html5 we should be able to test anne: I was more objecting with the way it cannot start with a digit ... section 5 says the selector is dropped dbaron: chapter 5 says it should not match ... the syntactic requirement sentence ? ... yes ... not about matching arronei: the entire chapter is about that dbaron: and about the syntax of selectors arronei: syntax is in chapter 4 dbaron: not entirely arronei: I see ... I'm ok with that ... the way I need to deal with this is with html5 ... can we submit this as html5... anne: in this case it's a syntax-level requirement ... not required on same page yet arronei: error handling is important dbaron: then there's already one test you failed so we catched the issue arronei: I was discorrelating the chapters ... if we fail that error case then according to ch5 you should not select either ... if you fail error case in ch4 then you have to create the case to see what failed ? because of P or attribute selector ? ... does it make sense to have in test suite ? fantasai: it's good to avoid dependencies on other chapters of the spec ... here we are trying to capture a case related to another part of spec <dbaron> fantasai: ... if it's easy to do without going out of your way fantasai: why you failed is an implementor's job ... I don' think we should really break things down ... there's a limit to our efforts breaking things down ... does not need to happen in the test suite arronei: I think for this case we're in agreement ... I was in disagreement before ... ok, I'll remove this test case ... I need to dig in we have other similar cases like that one ... I'll see if html5 works for cases fantasai: we don't need to test cases that are not going to happen in real markup docs <dbaron> After "Attribute values must be identifiers or strings." we could add "(Otherwise, the selector is not valid CSS 2.1.)" arronei: I disagree with that glazou: I disagree too arronei: we need to test every single part of spec, period ... that needs to happen, otherwise we're not done ... we need to test everything in the spec or we miss coverage fantasai: in this case it'll be fine to note we were not able to test because of technology sylvaing: limit yourselved to *ml markup because UA use that <anne> that was anne arronei: there could be other UA fantasai: in that case the implem will need its own test suite arronei: it's trying to implement CSS with their own markup, they do not care fantasai: we don't need to worry about it, that's their problem, they can contribute their own format of the test suite arronei: but if we have a markup language that is compatible accross vendors, then I can test most of these scenarios ... if I can create tests in html5, is that a problem ? melinda, fantasai yes melinda: too early on anne: but the parsing rules are a decade old ... older than css arronei: a limited number of cases: 6 or 7 ... nothing in the 17,000 cases list melinda: I have a problem with that anne: most browsers do html5, not an issue fantasai: we can add them to the list of tests and see ... might have to index by hand Zakim: shhhhttttt fantasai: problem is automatic indexing ... we can have a hand process for these ones <anne> (there's only 10-20 tests or so that need special syntax) arronei: I think we have a solution here for the initial issue <anne> (which HTML5 allows) <sylvaing> naming convention for html5 testcases so the build scripts can handle them separately ? arronei: most issues related to chapters 4 and 5 howcome: so what's the solution arronei: remove the case ... pursue the html5 possibility howcome: sounds good <fantasai> I suggest a different file extension arronei: one other issue is a test suite issue <fantasai> that way the build scripts will ignore them, and we can tell the makefile to just copy it <sylvaing> if that's sufficient, that's great arronei: another invalid case with invalid markup because of invalid attr, the version attr on html ... seems like a dtd bug howcome: url ? arronei: the version attr is valid for transitional anne: some other attrs ? arronei: wrt the attr() notation ... the test fails ... I am testing all attrs in html4 spec ... because the dtd does not contain the version attr <dbaron> There's a version attribute? anne: drop it <anne> yeah melinda: html only case ? arronei: yes glazou: report to html WG <arronei> http://www.w3.org/TR/html401/struct/global.html#h-7.3 anne: they won't care arronei: not sure it's important anne: just drop the test <sylvaing> DTD -> "Don't Test DOCTYPES" LOL arronei: ok with dropping it but it's such a great area anne: well ok arronei: only known attrs defined in html anne: there are a bunch of invalid attrs too melinda: worth looking with html wg if it's intentional arronei: these tests are marked html only melinda: xhtml as well ? arronei: deprecated attrs are html only ... odd case melinda: maybe not worth keeping it arronei: will ping html wg and we'll see ... the issue is external to us ... other issues with our tests ? anne: regarding the normalization thing, there would be a DOM problem too most likely ... not sure it has to be tested in the css test suite arronei: I'll take a look at that, you have a pointer ? melinda: I noticed the validator throws a warning for not having encoding ... do we want to accept that ? fantasai: we can add to build script or rely on http headers melinda: the warning occurs even if the http header is here fantasai: ok, we can add to build script ... I prefer keeping the template unchanged melinda: good answer <fantasai> ACTION: fantasai add UTF-8 header to build scripts [recorded in http://www.w3.org/2009/04/01-css-minutes.html#action01] <trackbot> Created ACTION-136 - Add UTF-8 header to build scripts [on Elika Etemad - due 2009-04-08]. howcome: multicol issue ? I have to run plinss: yes ... new draft ? howcome: yes, what we decided at ftf to use page properties to force column breaks ... not elegant but will work w/o having to create new props ... also about margin collapsing but almost same spec ... draft since previous century ... we have 3 probably 4 implems so it's about time ... all comments have been resolved ... time to move to LC ... fantasai suggested long LC 8 weeks melinda: we don't have a way to contain content to a page, important concern to me howcome: uh ? melinda: page break avoid in column scenario, we don't have any control on that howcome: the spec does not say anything about that ... adds a new keyword on two new properties to force column break melinda: changes definitions of page-break-inside ? howcome: means both melinda: how ? howcome: this is an old change, a year ago ... not column break inside properties, reusing page break melinda: disagreed during last ftf fantasai: a column box cannot break across pages ... a block that cannot rbeak across columns cannot break across pages howcome: you never really have control on that melinda: but I want that control howcome: somebody, alex?, could not see use cases for that melinda: I responsed to that statement fantasai: the way to solve this is to create a new keyword that avoids breaking across pages melinda: fine ... feeling not ok with long LC without that howcome: no we did not discuss that melinda: that's in the logs howcome: we did not touch the draft in that area melinda: let's look at current page-break-inside:avoid howcome: paged media draft fantasai: we discussed it ... we chose to apply to both column and pages melinda: still disagreeing fantasai: I prefer authors think about it melinda: fine, but we don't have anecessary control here ... I understand but that's all we have howcome: you are right but we're not discussing the before after properties ... I was happy to put in column-break-inside as well ... that was the consensus ; happy to put it in again ... continue in LC period <fantasai> I don't want a separate property here. If we need to add a keyword, we should add a keyword melinda: we need as a WG to make one more change ... are we expecting two LCs on this howcome: no one ... one new kwd to represent that case ? melinda: wonderful <dbaron> page-break-inside: avoid-page ? melinda: I am saying there are multiple cases ... we need independant controls for the column and the page cases howcome: more comfortable well maybe not ... I'm ok with having avoid kwd apply to both melinda: as long as we have extra control, ok howcome: we can add two kwds fantasai: no use case for avoid column <sylvaing> if my recollection is right, alex was worried about possible contradictions in some scenarios i.e. column-break:avoid and page-break:auto howcome: yes we do fantasai: no we don't szilles: avoid column would necessarily avoid break pages howcome: right melinda: fine fantasai: fine szilles: property name ? ... confusion with page-break-inside ... I would say avoid says just page ... and column says column and page fantasai: discussion already happened howcome: when ? fantasai: ftf howcome: I'm getting old, my memory is bad ;-) ... put it in ? melinda: wonderful fantasai: ask molly if she has suggestion melinda: we can change name in LC period ... great to add functionailty plinss: mark at risk ? howcome: note we're not sure about the name of the kwd melinda: if we have also implems we can test both otherwise we'll have to remove the column breaking one szilles: another reason to use another name or the colimn breaking thing howcome: avoid-all ? melinda: it may or may not apply to table cells fantasai: avoid-page for now and call for suggestions howcome: another issue here ... things in addition to page plinss: we're running out of time ... we agreed to add functionnality back in ... agreement to move to LC ? szilles: if avoid does both column and page and column is at risk then avoid will disappear melinda: howcome and fantasai should come up with a proposal for next week ACTION howcome fantasai : come up with proposal for multicol <trackbot> Created ACTION-137 - Fantasai : come up with proposal for multicol [on Håkon Wium Lie - due 2009-04-08]. agenda item ARIA review <plinss> http://www.w3.org/TR/2009/WD-wai-aria-20090224/ <fantasai> My proposal is page-break-inside: auto | avoid | avoid-page-break plinss: deadline is april 17th ... please everyone with interest in it review it, do we want to discuss it a s a group ? glazou: depends on the reviews themselves plinss: yes ... mailing list for comments <plinss> send comments to: public-pfwg-comments@w3.org glazou: comments to css wg first or directly there ? plinss: no strong opinion fantasai: there cc wg plinss: fair enough ... I hope we don't enter controversy, please make sure you don't represent the WG agenda item TP plinss: we need to give an answer ... so ? <dsinger> we surely should meet. szilles: we discussed it, meet with SVG when they meet dbaron: what other WG said or Chris ? glazou: headr nothing from them plinss: SVG was not going to be there, I think szilles: yes ... a month earlier fantasai: HTML and Webapps at TPAC <dsinger> what does "tech plenary" mean when major techs like SVG, CSS, don't meet? szilles: nobody said that, I don't know ... ping them ? glazou: said yes on TPAC questionnaire for thu/fri ... to leave us the door open plinss: ok ... if html and webapps we will attend szilles: yes ... and a separate meeting with SVG glazou: not both ? <dsinger> we should encourage them to attend tpac in that case szilles: no ... the biggest bang for the buck <dsinger> We have a CSS f2f in Sophia Wed-Fri 24-26 June, right? I was starting on hotel and travel as that is peak season in the cote d'azur. I plan to arrive Wed. afternoon (from a 3G meeting in Sweden). 3-5 dsinger: sigh will probably not be able to do it </Daniel>
Received on Wednesday, 1 April 2009 17:19:11 UTC