[CSSWG] Minutes and Resolutions 2012-07-04

[Note: Please do not reply to the minutes thread unless you are correcting the minutes.]


   - RESOLVED: use about:invalid as url as the default url in attr()
   - RESOLVED: defer Appendix A of Values and Units to L4
   - RESOLVED: defer issue 28 (normalization of <custom-ident>) to L4
   - RESOLVED: No change to calc() white space rules; they are required
               around + and -, and optional around / and *.
   - RESOLVED: Flexbox order property does not affect tab order or speech
   - RESOLVED: rename 'order' to something more specific so it doesn't
               imply that non-visual orders (e.g. tab order or speech order)
               are affected

====== Full minutes below ======

   CÚsar Acebal
   Glenn Adams
   Rossen Atanassov
   David Baron
   Elika Etemad
   Simon Fraser
   Peter Linss
   Edward O'Connor
   Anton Prowse
   Florian Rivoal
   Steve Zilles

<RRSAgent> logging to http://www.w3.org/2012/07/04-css-irc
Scribe: smfr

Values and units issues

   <fantasai> http://dev.w3.org/csswg/css3-values/issues-lc-2012

   fantasai: issue 18: defining an always invalid url
   fantasai: computed value of an attr with no default value is UA specific;
             we are asked to choose something
   proposal: use "about:invalid"
   fantasai: comments?
   florian: no strong opinion, but why not?
   <fantasai> http://lists.w3.org/Archives/Public/www-style/2012Jun/0689.html
   dbaron: is it ok that the URL in question has to reparse correctly?
   dbaron: so that it could be specified
   fantasai: i don't know
   <fantasai> http://dev.w3.org/csswg/css3-values/#attr-notation
   fantasai: (reads from the spec)
   <fantasai> attr(foo url)
   <fantasai> what's the default if there's no foo attribute?
   <fantasai> atm it's UA-defined
   <fantasai> comment was to define something
   <fantasai> we can either leave UA-defined or return 'about:invalid'
   dbaron: we return it in computed style for urls that failed the url parser
   dbaron: but we use a different url string
   dbaron: we're ok switching to this
   fantasai: any other comments?
   RESOLVED: use about:invalid as url as the default url in attr()

   florian: there was mailing list discussion
   dbaron: my feeling is that most of the prose is defining things that I
           suspect may not be correct
   dbaron: we are better of postponing this
   florian: i agree; the intent is good, but lots of trick edge cases
   florian: would require changes to engines
   smfr: we don't like the special "close to integer" behavior
   florian: i don't want to have to do math differently because of this
   florian: i don't like the parsing but am willing to do it
   fantasai: do we want to defer the min/max, or just the prevision and rounding?
   sylvaing: rounding is controversial, but min/max isn't
   florian: we're still at 25 bits, the intent was 24 bits
   fantasai: is the 17 correct?
   florian: for us it's fine
   florian: min/max is the safest bit, fine with deferring the whole thing
   dbaron: what I was arguing for earlier was to postpone the prose below
   sylvaing: postponing the whole thing is easiest
   smfr: do we still have prose about round-tripping values?
   fantasai isn't sure what that prose was
   florian: would still like responses even if it's postponed
   fantasai: yep, will handle for L4
   RESOLVED: defer Appendix A of Values and Units

   <fantasai> http://dev.w3.org/csswg/css3-values/issues-lc-2012#issue-28
   <fantasai> Proposed to defer to L4
   fantasai: are there any other proposals?
   dbaron: postponing is fine
   RESOLVED: defer issue 28
   plinss: this may raise an objection from i18n

   <fantasai> http://dev.w3.org/csswg/css3-values/issues-lc-2012#issue-29
   <fantasai> http://lists.w3.org/Archives/Public/www-style/2012May/0499.html
   fantasai: identifiers are case-insensitive, but author-defined counter
             styles are allowed
   fantasai: describes 3 options in
   florian: option for 1 is to say that @counter-style name are case
            insensitive in ASCII range only
   [some discussion]
   fantasai: proposal I hear is to have two kinds of author-defined identifiers;
             case sensitive and ASCII-case insensitive
   plinss: don't like the inconsistency
   florian: we'll have an inconsistency somewhere
   fantasai: 4th proposal might be to have in css3 all user-defined idents
             are case-insensitive in the ASCII range
   probably web compatible but a change from CSS 2.1
   florian: how much web breakage?
   fantasai: not much, mostly affects counters and only if they rely on
             case mismatches being different counters
   florian: may break because of typos
   antonp: erring towards proposal 3
   fantasai: we will probably do this for some other properties like text-transform
   plinss: like the idea of making them all ASCII-range case insensitive
   florian: easier to fix now than later
   dbaron: case-insensitive in the ascii range could be confusing for
           authors who use non-ascii characters
   plinss: option 3 sounds a bit hacky
   sylvaing: how bad is unicode case-folding?
   fantasai: there's a generic version but it's a source of bugs (e.g. if UAs call
             locale-specific routines by mistake)
   fantasai: only css keywords will get case permutations
   sylvaing: Are we looking at a situation where it'll take a few releases
             to get right and it affects lots of people, or it affects only
             a few people
   florian: we already have this code elsewhere
   fantasai: yes, for text-transform
   dbaron: there's a performance cost
   florian: or you convert to lowercase
   fantasai: you say that the computed value is the case-folded value
   sylvaing: was asking if the complexity was worth the inconsistency
   florian: does anyone dislike this?
   dbaron: would want to go back and look at why we changed this for 2.1
   dbaron: there were things that were originally case-insensitive and we
           changed them to case sensitive
   fantasai: there are some things that would case-fold into the ascii range,
             and we didn't want that
   florian: can we temporarily resolve?
   fantasai: we could defer author identifier types from level 3?
   florian: this would go in CR now?
   fantasai: author ident is not actually referenced anywhere, yet
   (since CSS2.1 is self-contained)
   smfr: aren't animation names author idents?
   fantasai: yes
   plinss: I think we should do this in level 3
   dbaron: i would prefer one of the other options
   florian: we've been proposing 1a for all ...
   dbaron: i don't think we should reopen the whole case sensitivity discussion
   plinss: we'll have more places where authors can define things; will be
           a source of confusion
   dbaron: want text with references and citations if we go for one of the
           1) options. And a week to review
   <fantasai> http://unicode.org/Public/UNIDATA/CaseFolding.txt
   fantasai: i can spec it but am concerned about computed values being
   fantasai: i will try to spec that
   dbaron: why didn't we choose this option for 2.1?
   fantasai: there were no places where author keywords and UA keywords
             were mixed up, and case-sensitive is easier
   smfr: describes issue with animation names
   Authors have to be able to do the same case-folding in JS to compare
     animation names.
   Keyword idents show up in animation events.
   plinss: we'd need a JS function
   sylvaing: hard to introduce a new function for this
   dbaron: i don't think parse-time folding is web compatible, because we've
           never done that before
   florian: other options are 2 and 3
   fantasai: 2 is weird, 3 maybe makes more sense
   plinss: issues with option 1 are the same issues we've run into with
           unicode normalization
   plinss: we'll have to deal with that anyway
   <SteveZ> does not 3 have all the string matching problems of 1 and 2.
   plinss: I don't think that case-folding at parse time is the right thing
   plinss: it should happen at comparison time
   florian: but that's an issue in JS
   dbaron: authors aren't going to understand
   plinss: would like to see a plan to resolve this
   <SteveZ> It seems to me that the issues are (a) string matching, both in
            CSS and in Javascript and (b) round tripping of Identifiers in
   plinss: would dbaron be willing to review some new text defining option 1
           with new stuff
   dbaron: it's option 1 plus a lot of other things.  But I would.
   ACTION: fantasai to write proposed wording for 1B

   <fantasai> http://dev.w3.org/csswg/css3-values/issues-lc-2012#issue-35
   <fantasai> whether calc should make whitespace optional around + -
   fantasai: because - forms part of an ident
   fantasai: rejected because it means you can't put keywords in calc in future
   <fantasai> http://lists.w3.org/Archives/Public/www-style/2012May/0463.html
   <fantasai> proposal: no change, white space is required
   fantasai: saying no change to calc, whitespace is required around + and -
   hober: why not require it around / and * for consistency
   fantasai: they don't need it
   smfr: hard for authors to remember where to put whitespace
   fantasai: just put white space everywhere
   fantasai: */ bind tigheter than + and - , so the current requirements
             make sense
   dbaron: gecko implements what the spec says
   RESOLVED: accept the rejection of this issue
   plinss: do we want to require whitespace around / and *?
   dbaron/fantasai/florian: do not want
   RESOLVED: leave the rest alone


   <fantasai> http://dev.w3.org/csswg/css3-flexbox/issues-lc-2012
   <fantasai> http://lists.w3.org/Archives/Public/www-style/2012Jun/0668.html
   Issue 5: painting atomically: we decided to reject
   dbaron: they should do what inline-block and inline-tables do
   fantasai: or should they do what table cells do?
   appendix E doesn't say what table cells do
   fantasai: how about we resolve to have them do what table cells do?
   dbaron: not confident that 2.1 Appendix E is correct for table cells
   ACTION: dbaron to review appendix E and table cells, in relation to flexbox
   <trackbot> Created ACTION-482
   <antonp> Agree with dbaron, not at all sure Appendix E handles table stuff well
   <antonp> Some bugs are open on that
   <dbaron> 3C%2Ftable%3E shows 2.1 appendix E is actually correct for table cells
   <dbaron> but I rather prefer the float/inline-block behavior

   Running out of time, so Florian jokingly proposes looking at a renaming issue.
   fantasai therefore directs the WG to Issue 4.

   issue 4: 'order' might be too generic a name
   fantasai: whether this issue is valid depends on...
   issue 3: does 'order' affect speech and tab order
   fantasai: The point of order property is to change visual order, without
             affecting order for speech etc.
   fantasai: but if it's just paint order, should it have a more specific name
   plinss: makes sense to have a more specific name
   florian: we need to resolve issue 3 first
   <fantasai> http://lists.w3.org/Archives/Public/www-style/2012Jul/0046.html
   florian: was john foliot fine with the proposal?
   fantasai: he didn't have a strong opinion afaict
   <fantasai> Foliot's response: http://lists.w3.org/Archives/Public/www-style/2012Jun/0481.html
   fantasai points to examples in the spec: pulling image above heading,
     placing sidebar on left of main content instead of right, etc.
     These are all cases where it's important that the speech order not
     be affected.
   <fantasai> http://dev.w3.org/csswg/css3-flexbox/#overview
   <fantasai> http://dev.w3.org/csswg/css3-flexbox/#order-property
   fantasai: If you want to reorder things logically, would reorder the source.
   fantasai: Felt it's important that non-CSS UAs and CSS-enabled speech UAs
             be consistent. Shouldn't need to understand Flexbox to get the
             speech order right.
   RESOLVED: issue 3; order does not affect tab order or speech order
   plinss: should we change the name to display-order?
   smfr: I agree with the name change
   RESOLVED: rename 'order' to something more specific
   florian: what are we renaming to?
   fantasai: box-order or display-order
   florian: display-order looks like a longhand for display, don't like
   plinss: other option is flex-order
   florian?: no, don't want to go back
   florian: maybe visual-order?
   dbaron: it sounds like z-order (which is 'z-index')
   fantasai: display-order implies affecting paint order too (which this
             property does); I understand the longhand issue but I think
             we should go with that
   <glenn> is visual order same as reading order?
   hober: paint-order?
   fantasai: that implies it doesn't affect layout order
   florian proposes straw-polling
   Rossen: Alex had an opinion, but not sure what it was
   Rossen: Should move to next week.

Meeting closed.

<dbaron> We might have 'order' committed to the tree by next week

Received on Wednesday, 4 July 2012 19:34:32 UTC