[CSSWG] Minutes, 01 April 2009 CSSWG telcon

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