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>