css wg telcon -- 08 Apr 2009

<glazou> hi MikeSmith

<MikeSmith> glazou: konban wa

<fantasai> dsinger_: type /nick dsinger

<fantasai> dsinger_: type /nick dsinger into your IRC client

<fantasai> dsinger_: then Zakim will recognize you

<dsinger_> Can we discuss the sophia agenda briefly?

<dsinger_> T u

<glazou> np

<glazou> I only forgot to add it on the agenda but that was on the list

<glazou> ok emilyw

<dsinger_> Chris asks why agenda is member only but minutes are public

<dsinger_> Admin is member only, tech is public

<scribe> scribenick: chrisl

<scribe> scribe: chris

agenda - member or public

dg: chris suggests sending agenda to the public list

bb: why? no advantage

dd: agenda almost always public. any member -specific stuff is rare and can be discussed separately

<dsinger_> I think the current arr. Is odd but right

pl: can post the agenda minus the dial in numbers to the public list

db: publ;ic may have useful feedback

<fantasai> dg: no, not dial in numbers, just topics

mg: if agenda is early enough

bb: don't want to do this, writing for the public takes to much time. unecessary

sg: specific example?

bb: want to hide spelling mistakes

<fantasai> pl: how about we send the agenda to the members mailing list and send a synopsis to the public mailing list

<dsinger_> Has any public asked?

pl: how about a synopsis of agenda sent to public, plus fuller agenda to member list

cl: dave - no

<dsinger_> They see the minutes

db: how would they ask for it without knowing it exists

dg: minor issue, no consensus to move to public agenda.

<dsinger_> It is work to fix, and dpes not seem worth it

dg: could take more time to sort through public feedback before meeting

cl: ok, thanks for considering it

<fantasai> dg: we stay as we are for the time being

<glazou> http://lists.w3.org/Archives/Member/w3c-css-wg/2009JanMar/0212.html

CSS2.1 Issue followup

http://wiki.csswg.org/spec/css2.1#issue-24

Everyone had an action to read Bert's email and prepare for discussion

ee: made comments in email

<dbaron> the " apple][ {color: red}" is actually a lot more complicated than Bert said

<fantasai> no, actually, last week's minutes

<fantasai> fantasai: shouldn't this have been sent to the public mailing list?

ee: wasn't berts comment supposed to be sent to public list?

db: contents of email seem reasonable but i don't see a proposal
... two examples look a bit complex

<dbaron> complex in that they're more complicated than stated because of ()/[]/{}-matching

bb: my preference is to not do anything
... this is as far as I got

ee: it doesn't adress selectors. want it to cover at-rules and declaration blocks

<glazou> szilles: ?

ee: idea that you match brackets and quotes is clear enough without specific microparsong rules
... there is an error in the spec as we changed the wording and introduced a new issue
... proposal was that the part on malformed declarations was changed to stateents

<fantasai> http://www.w3.org/TR/CSS21/syndata.html#parsing-errors

<fantasai> There's a rule about malformed declarations

ee: should be "statements and declarations"

<fantasai> yea

bb: not sure you always know if you are in a statement or not

ee: in one if you are not in a declaration
... @rule is always a statement
... if you are in a decl skip to end of decl, else skip to end of that statement

bb: no statements inside an @media

<fantasai> bb: they look like statements, but they aren't according to the grammar

bb: hence the complex email, there are different types of @rules. @media and @page are different
... take last example in my email
... you are at the top level then you see an invalid string. have not started the first statement
... have to assume you are unless you are clearly not eg a comment
... would like it to be as simple as elika says but doubt it is that simple

ee: only unclear case is inside @page in css3
... so suggest dupllicating the malfored rule for stateents, then add more detail in css3 paged media

dg: good compromise. is it acceptable?

bb: imples an error inside an @rule causes whole @rule to be ignored?

ee: depends on where it occurs

<dbaron> I think in the long run we should have a single grammar that has "unexpected content" productions that match pretty much anything and which correspond to the pieces that get ignored

ee: not if the @rulke has declarations.
... trap points are stzatements and declarations

<glazou> dbaron: yes

sg: what are the chars that are matched?

{ ( "

<fantasai> ee: brackets and quotes

<glazou> ChrisL: that's sylvain galineau

<sylvaing> yeah so content:"}" does not cause havoc

<dbaron> also [

<fantasai> and '

<fantasai> :)

<sylvaing> ()/{}/[]/""/''

dg: any objections to elika's proposal

(none heard)

bb: ok lets try it

<fantasai> RESOLVED: duplicate malformed declarations rule for malformed statements (statements rule to come after declarations rule in the spec)

resolution: duplicate section on malformed declarations for malformed stateents

db: I think in the long run we should have a single grammar that has "unexpected content" productions that match pretty much anything and which correspond to the pieces that get ignored
... make the production that covers all things that get ignored
... this is a rather big project

dg: I agree in principle, on desirability and timeline

<glazou> http://lists.w3.org/Archives/Public/www-style/2009Feb/0299.html

Issues with CSS2.1 Grammar

http://lists.w3.org/Archives/Public/www-style/2009Feb/0538.html

dg: should a class be a name instead of an ident?

db: why?

ee: think he missed the point odf the section

dg: and why to escape the first digit

ee: comparing css1 and css2, think he is confused. can no longer do this

dg: agree, not an issue

resolved: non-issue

<dbaron> somebody should respond :-)

<glazou> http://lists.w3.org/Archives/Public/www-style/2009Feb/0538.html

<scribe> ACTION: daniel to respond to yves saying why ident is not an issue [recorded in http://www.w3.org/2009/04/08-css-minutes.html#action01]

<trackbot> Created ACTION-138 - Respond to yves saying why ident is not an issue [on Daniel Glazman - due 2009-04-15].

<sylvaing> http://lists.w3.org/Archives/Public/www-style/2009Feb/0538.html

bb: yes, the S token is ambiguous
... ok to change the grammar

dg: so remove s* from end of import?

bb: yes

bert's response http://lists.w3.org/Archives/Public/www-style/2009Feb/0619.html

<Bert> http://lists.w3.org/Archives/Public/www-style/2009Feb/0619.html

pl: agree

bb: yves says its easier if no non terminals can produce an empty string
... can accept that

dg: any objection?

(non heard)

dg: choices in berts email seem harmless
... and obvious

resolved: accept berts proposal on gramar

<scribe> ACTION: bert make the changes in http://lists.w3.org/Archives/Public/www-style/2009Feb/0619.html [recorded in http://www.w3.org/2009/04/08-css-minutes.html#action02]

<trackbot> Created ACTION-139 - Make the changes in http://lists.w3.org/Archives/Public/www-style/2009Feb/0619.html [on Bert Bos - due 2009-04-15].

sg: do we have any outstanding 2.1 issues before publication?

dg: no, so lets publish and update as soon as possible

ee: bert and I will check all the edits have been made

db: so i put an issue on the end of the list
... font-weight bolder and lighter, want to backport from css3 to css 2.1

<dbaron> issue 111

cl: is it simple to specify?

db: yes but no proposed text yet

bb: prefer to see actual text

(several) yes

db: fine to publish but there is more stuff to do

ee: boris has some pendingf issues on anonymous tales still to come

resolved: publish and update to css 2.1 asap

<fantasai> Bert, we should schedule a day to coordinate on 2.1

Fallback color on background-image

http://lists.w3.org/Archives/Public/www-style/2009Feb/0536.html

ee: at f2f we decided I would propose text so we don't need to discuss this now

<glazou> http://lists.w3.org/Archives/Public/www-style/2009Mar/0389.html

Fallback on border-image

<glazou> http://www.bradclicks.com/cssplay/border-image/Thinking_Outside_The_Box.html

dg: wh can summarise this?

ee: several open issues from discussions with dave hyatt, brad kempers proposal adresses all of them
... look at his pictures
... if image fails to load, layout jumps around. also layout changes depending on border-image support
... so want it to not affect border-width
... example with a jutting corner
... make sa lot of sense
... also says designers want an image where layout aligns with a given point of the image, wants to allow some overflow
... minor issues to discuss on mailing list, precise syntax, but we should adopt this

hyatt and roc in favour

dg: demoed boder image, people were scared by the nuber of arguments and this adds four more. its hard to remember

ee: maybe a shorthand with individual properties like border-image-offset
... more understandable at expense of adding more properties

dg: public wants it to be simpler and easier to understand. need to look at very carefully
... seems to meet web designer's wishes

bb: what if the corerr image is wider than the box itself?

ee: probably it gets clipped

db: there is some rule to explain how to handle this

ee: needs to be worked out in detsail

dg: any objection to moving forward on this proposal

hl: not studied in detail yet

dg: so, do we adopt this direction and develop it further?
... main issue is relayout which is a big issue

ee: hyatt raised this also

dg: does make sense
... any disagreement?

(none heard)

dg: several options, functional notation or shorthand

<fantasai> sg: I like the proposal, but usability of the syntax is a concern

resolved: adopt this direction to avoid relayout but make the syntax easier to understand

next f2f in sophia

<fantasai> http://wiki.csswg.org/planning/sophia-2009

dg: need agenda items to help people with travel planning

ee: pleae add topics to the wiki

ds: no specific ones to suggest but might be difficult getting apple dev there as right before out dev conference

<Bert> Currently known topics: test suites, and grid/matric/template layouts

sz: last day of japan f2f should have a list of topics

ee: will add them

ds: three day meeting all day?

dg: yes
... any other items?

hl: think ing on column break vs page break. any strong opinions?

ee: melinda and i discussing, no opinions yet

hl: want to bring back the column-break-{before, after, inside} rather than having this in the page properties

sz: then you have an interaction problem

hl: yes, needs to be defined

<melinda> I'm kinda leaning the same way... maybe with a shorthand to combine them...???

hl: yes, shorthand could be good. will propose text

adjourned

<Bert> Fantasai, for the CSS 2.1 issues, any day is fine starting next Tuesday.

- DRAFT -

css wg telcon

08 Apr 2009

Attendees

Contents