- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 04 Jul 2012 12:34:03 -0700
- To: "www-style@w3.org" <www-style@w3.org>
[Note: Please do not reply to the minutes thread unless you are correcting the minutes.]
Summary:
- 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
order
- 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 ======
Present:
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
http://dev.w3.org/csswg/css3-values/issues-lc-2012#issue-18
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()
http://dev.w3.org/csswg/css3-values/issues-lc-2012#issue-25
http://dev.w3.org/csswg/css3-values/#limits
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
http://lists.w3.org/Archives/Public/www-style/2012May/0499.html
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
http://lists.w3.org/Archives/Public/www-style/2012May/0499.html
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
lowercased
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
serialization
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
Flexbox
-------
<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>
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0A%23a%20div%20%7B%20background%3A%20aqua%3B%20color%3A%20blue%3B%20margin-right%3A%20-1em%20%7D%0A%23b%20div%20%7B%20background%3A%20yellow%3B%20color%3A%20brown%3B%20margin-left%3A%20-1em%20%7D%0A%3C%2Fstyle%3E%0A%3Ctable%3E%3Ctr%3E%0A%3Ctd%20id%3D%22a%22%3E%3Cdiv%3Ehello%3C%2Fdiv%3E%3C%2Ftd%3E%0A%3Ctd%20id%3D%22b%22%3E%3Cdiv%3Ehello%3C%2Fdiv%3E%3C%2Ftd%3E%0A%3C%2Ftr%3E%
<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.
http://dev.w3.org/csswg/css3-flexbox/issues-lc-2012#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