W3C home > Mailing lists > Public > www-style@w3.org > June 2009

Re: [CSSWG] Minutes, 01 April 2009 CSSWG telcon

From: fantasai <fantasai.lists@inkedblade.net>
Date: Mon, 08 Jun 2009 05:55:56 -0700
Message-ID: <4A2D0A5C.4030507@inkedblade.net>
To: www-style@w3.org

   - Discussed what to do when the test suite format (XHTML1.1) limits the
     ability to fully test CSS (e.g. attributes starting with digits).
     Concluded that some tests will be HTML5 and some assertions will
     remain untested

   - Discussed controls for page and column breaks, howcome and fantasai
     to propose solutions.

   - Discussed TPAC plans

====== Full minutes below ======

   César Acebal
   David Baron
   Arron Eicholz
   Elika Etemad
   Sylvain Galineau
   Daniel Glazman
   Melinda Grant
   Hĺkon Wium Lie
   Peter Linss
   Anne van Kesteren
   David Singer

<RRSAgent> logging to http://www.w3.org/2009/04/01-css-irc
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...
   <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...

test case selector issue
   plinss: had a chance to read the thread ?
   glazou: I did
   glazou: Bert summarized the issue, XML cannot make an attribute start
           with a digit
   anne: yes, impossible
   <sylvaing> invalid, even
   arronei: it's even invalid in html as well
   arronei: I totally agree the case is an invalid case but we have a
            problem where we cannot test invalid scenarios
   arronei: this has to be valid xhtml
   arronei: so how do you test invalid scenarios
   arronei: 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
   dbaron: 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
   dbaron: or don't worry about it
   arronei: test suite is xhtml
   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
   dbaron: we can test that it's an accepted selector with another valid
           selector in same rule
   dbaron: just like p:not(p), where you can't prove that it doesn't
           match anything
   arronei: but we cannot prove which selector matched
   arronei: no way to prove that
   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 in a rule and another with
         only one
   arronei: dependency issue
   arronei: we end up with a dependency chain
   dbaron: but that implementation doesn't remotely implement CSS
   anne: not a problem
   anne: at least with html5 you can have attribute with a leading dash
   anne: I think digits too
   arronei: that would handle the valid case
   arronei: the invalid has probably no good way of testing
   sylvaing: you never really select because it's alrady dropped
   sylvaing: spec says there is syntax error
   anne:  you can match using an escape
   plinss: perfectly valid css if you escape
   plinss: should still not match siince the attr is not in the DOM
   arronei: we need a markup language allowing that attribute
    * mollydotcom has delayed plane, in airport so can't phone in
   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
   anne: section 5 says the selector is dropped
   dbaron: chapter 5 says it should not match
   dbaron: the syntactic requirement sentence ?
   dbaron: yes
   dbaron:  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
   arronei: I'm ok with that
   arronei: the way I need to deal with this is with html5
   arronei: can we submit this as html5...
   anne: in this case it's a syntax-level requirement
   anne: 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
   arronei: if we fail that error case then according to ch5 you should
            not select either
   arronei: if you fail error case in ch4 then you have to create the case
            to see what failed ? because of P or attribute selector ?
   arronei: does it make sense to have in test suite ?
   fantasai: it's good to avoid dependencies on other chapters of the spec
   fantasai: ... if it's easy to do without going out of your way
   fantasai: here we are trying to capture a case related to another part of spec
   fantasai: why you failed is an implementor's job
   fantasai: I don't think we should really break things down this much
   fantasai: there's a limit to our efforts breaking things down
   fantasai: does not need to happen in the test suite
   arronei: I think for this case we're in agreement
   arronei: I was in disagreement before
   arronei: ok, I'll remove this test case
   arronei: I need to dig in we have other similar cases like that one
   arronei: 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
   arronei: that needs to happen, otherwise we're not done
   arronei: 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
   anne: limit yourselved to *ml markup because UA use that
   <sylvaing> 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
   arronei: 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
   anne: older than css
   arronei: a limited number of cases: 6 or 7
   arronei: 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
   fantasai: might have to index by hand
   fantasai: problem is automatic indexing
   fantasai: 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
   arronei: 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
   arronei: seems like a dtd bug
   howcome: url ?
   arronei: the version attr is valid for transitional
   anne: some other attrs ?
   arronei: wrt the attr() notation
   arronei:  the test fails
   arronei: I am testing all attrs in html4 spec
   arronei: 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"
   <glazou> 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 lokking with html wg if it's intentional
   arronei: these tests are marked html only
   melinda: xhtml as well ?
   arronei: deprecated attrs are html only
   arronei: odd case
   melinda: maybe not worth keeping it
   arronei: will ping html wg and we'll see
   arronei: the issue is external to us
   arronei: other issues with our tests ?
   anne: regarding the normalization thing, there would be a DOM
         problem too most likely
   anne: 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
   melinda: 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
   fantasai: I prefer keeping the template unchanged
   melinda: good answer
    * glazou has tired fingers, you speak all fast :)
    * fantasai is impressed at how well glazou has kept up
    * sylvaing ...against all odds....
   ACTION: fantasai add UTF-8 header to build scripts

Page and Column Breaks

   howcome: multicol issue ? I have to run
   plinss: yes
   plinss: new draft ?
   howcome: yes, what we decided at ftf to use page properties to force
            column breaks
   howcome: not elegant but will work w/o having to create new props
   howcome: also about margin collapsing but almost same spec
   howcome: draft since previous century
   howcome: we have 3 probably 4 implems so it's about time
   howcome: all comments have been resolved
   howcome: time to move to LC
   howcome: 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
   howcome: 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
   howcome: not column break inside properties, reusing page break
   melinda: disagreed during last ftf
   fantasai: a column box cannot break across pages
   fantasai: 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
   melinda: 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
   fantasai: 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
   melinda: I understand but that's all we have
   howcome: you are right but we're not discussing the before after properties
   howcome: I was happy to put in column-break-inside as well
   howcome: that was the consensus ; happy to put it in again
   howcome: 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
   melinda: are we expecting two LCs on this
   howcome:  no, one
    * glazou laughs
   howcome: one new kwd to represent that case ?
   melinda: wonderful
   <dbaron> page-break-inside: avoid-page ?
   melinda: I am saying there are multiple cases
   melinda: we need independant controls for the column and the page cases
   howcome: more comfortable well maybe not
   howcome: 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
    * glazou remembers the time howcome  did not want extra kwds because
             of mobile phones' memory
   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
  * anne has to go, bye!
  Zakim> -anne
   szilles: avoid column would necessarily avoid break pages
   howcome: right
   melinda: fine
   fantasai: fine
   szilles: property name ?
   szilles: confusion with page-break-inside
   szilles: I would say avoid says just page
   szilles: and column says column and page
   fantasai: discussion already happened
   howcome: when ?
   fantasai: ftf
   howcome: I'm getting old, my memory is bad ;-)
   howcome: put it in ?
   melinda: wonderful
    * sylvaing even sylvaing remembers that so it'd definitely true
   fantasai: ask molly if she has suggestion
   melinda: we can change name in LC period
   melinda: 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
   howcome: things in addition to page
   plinss: we're running out of time
   plinss: we agreed to add functionnality back in
   plinss: 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
   <fantasai> My proposal is page-break-inside: auto | avoid | avoid-page-break

ARIA review

   <plinss> http://www.w3.org/TR/2009/WD-wai-aria-20090224/
   plinss: deadline is april 17th
   plinss: 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
   plinss: 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
   plinss: I hope we don't enter controversy, please make sure you don't
           represent the WG


   plinss: we need to give an answer
   plinss: 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
   szilles:  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
    * glazou dsinger XHTML2 rulz !
   szilles: ping them ?
   glazou: said yes on TPAC questionnaire for thu/fri
   glazou: to leave us the door open
   plinss: ok
   plinss: if html and webapps we will attend
   szilles: yes
   szilles: and a separate meeting with SVG
   glazou: not both ?
   <dsinger> we should encourage them to attend tpac in that case
   szilles:  no
   szilles: 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).
   <glazou> 3-5
   dsinger: sigh will probably not be able to do it
   <dbaron> http://www.w3.org/Graphics/SVG/WG/wiki/Meetings#Upcoming_F2Fs
            doesn't have the SVG WG's plans
   <shepazu> dbaron, they aren't settled yet, but I will put up a page
             about SVG Open, and we could discuss it at tomorrow's SVG
             WG telcon if that would help

<RRSAgent> http://www.w3.org/2009/04/01-css-minutes.html
Received on Monday, 8 June 2009 18:58:11 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 11 February 2015 12:34:26 UTC