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
Summary:

   - Discussed what to do when the test suite format (XHTML1.1) limits the
     ability to fully test CSS (e.g. attributes starting with digits).
       <http://lists.w3.org/Archives/Public/public-css-testsuite/2009Mar/0002.html>
     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 ======

Attendees:
   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

Agenda
------

   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
------------------------
   http://lists.w3.org/Archives/Public/public-css-testsuite/2009Mar/0002.html
   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
   s/lokking/looking
   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
----------------------

+SteveZ
   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

TPAC
----

   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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:18 GMT