- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Mon, 08 Jun 2009 05:55:56 -0700
- 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 UTC