See also: IRC log
<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
<fantasai> Bert?
<dbaron> http://www.w3.org/Graphics/SVG/WG/wiki/Meetings#Upcoming_F2Fs doesn't have the SVG WG's plans
fantasai: you have a script to turn the IRC minutes into something readable ?
<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
hi shepazu
<shepazu> hi, glazou
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/anne/arron/ Succeeded: s/sylvaing/anne/ Succeeded: s/??/anne/ Succeeded: s/lokking/looking/ Succeeded: s/and/or/ Succeeded: s/there is a problem too/there would be a DOM problem too most likely/ Found Scribe: glazou Inferring ScribeNick: glazou WARNING: No "Topic:" lines found. Default Present: dsinger, plinss, fantasai, glazou, anne, arronei, sylvaing, David_Baron, CesarAcebal, Howcome, Melinda_Grant, SteveZ Present: dsinger plinss fantasai glazou anne arronei sylvaing David_Baron CesarAcebal Howcome Melinda_Grant SteveZ WARNING: No meeting title found! You should specify the meeting title like this: <dbooth> Meeting: Weekly Baking Club Meeting WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Got date from IRC log name: 01 Apr 2009 Guessing minutes URL: http://www.w3.org/2009/04/01-css-minutes.html People with action items: add fantasai header utf-8 WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option. WARNING: No "Topic: ..." lines found! Resulting HTML may have an empty (invalid) <ol>...</ol>. Explanation: "Topic: ..." lines are used to indicate the start of new discussion topics or agenda items, such as: <dbooth> Topic: Review of Amy's report[End of scribe.perl diagnostic output]