/irc-logs / w3c / #css / 2012-07-04 / end

Options:

# Session Start: Wed Jul 04 00:00:00 2012
# Session Ident: #css
# [00:10] * Joins: arno (arnog@76.76.241.47)
# [00:33] * Joins: jet (jet@206.15.76.122)
# [01:18] * Joins: miketayl_r (miketaylr@70.112.101.224)
# [01:18] * Quits: miketaylr (miketaylr@70.112.101.224) (Connection reset by peer)
# [01:27] * Quits: drublic (drublic@95.115.7.147) (Client exited)
# [01:27] * Joins: drublic (drublic@95.115.7.147)
# [01:30] * Quits: drublic (drublic@95.115.7.147) (Ping timeout)
# [01:33] * heycam|away is now known as heycam
# [01:38] * Quits: arno (arnog@76.76.241.47) (Quit: Leaving.)
# [02:36] * Quits: dbaron (dbaron@206.15.76.122) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [02:59] * Quits: tantek (tantek@76.115.51.221) (Quit: tantek)
# [03:07] * Quits: jet (jet@206.15.76.122) (Quit: jet)
# [03:17] * Joins: jdaggett (jdaggett@202.221.217.73)
# [03:17] <jdaggett> fantasai: ping
# [03:30] <fantasai> jdaggett: pong
# [03:30] <jdaggett> so i've finally grokked what's going on with mongolian/phags-pa
# [03:31] <jdaggett> this is really a short-sighted hack that we shouldn't propogate into unicode
# [03:31] <jdaggett> if i was being unkind, i'd say this is standard microsoft behavior
# [03:31] <jdaggett> hack the present, neuter the future
# [03:32] <jdaggett> mongolian/phags-pa, despite being *vertical* scripts, are only defined with horizontal metrics
# [03:32] <jdaggett> (looking at the win8 font examples)
# [03:33] <jdaggett> but this sucks for implementing good vertical layout
# [03:34] <jdaggett> because it will eliminate the chance to kern properly
# [03:34] <jdaggett> 'kern' is the horizontal kerning feature, 'vkrn' the one for vertical
# [03:34] <jdaggett> if text run A and B use different orientation, the ability to kern across those boundaries is lost
# [03:35] <jdaggett> but with correct vertical glyphs and metrics, the correct kerning could be applied
# [03:36] <jdaggett> it's obviously more efficient to store vertical glyphs in horizontal forms and let the layout engine rotate them in
# [03:36] <jdaggett> but that breaks the larger model
# [03:37] <jdaggett> this is something opentype should fix
# [03:37] <jdaggett> by either allowing a transform on a glyph or setting a flag that identified this type of font
# [03:38] <jdaggett> regardless, it's not something that's an intrinsic property of the character
# [03:38] <jdaggett> it's just an expediency used in current implementations
# [03:40] <fantasai> ok
# [03:40] <fantasai> you need more than just vertical kerning, though, you need all the contextual shaping / ligature stuff
# [03:40] <fantasai> that you said was broken atm
# [03:40] <fantasai> anyway, it's not being propagated into Unicode, thanks to the HO property
# [03:40] <fantasai> it's just in our spec right now
# [03:41] <jdaggett> well, it's not broken because they are applying in on horizontal runs
# [03:41] <fantasai> ?
# [03:41] * Liam suspects a different meaning of the word "broken" being used here
# [03:42] <jdaggett> shaping for intra-Mongolian will work
# [03:42] <Liam> expedient-but-not-right vs not-working
# [03:42] <jdaggett> shaping between runs with U vs. R will not
# [03:42] <fantasai> right
# [03:42] <fantasai> but those don't shape anyway
# [03:43] <fantasai> it's the same as end-of-run
# [03:43] <fantasai> We have a general problem with kerning in vertical runs regardless
# [03:43] <jdaggett> no, opentype allows arbitrary substitutions and positionings
# [03:43] <fantasai> due to no cross-run kerning
# [03:43] <fantasai> and there's a lot of U/R boundaries
# [03:44] <fantasai> I don't think it's a problem we can solve atm, it involves the font being able to rotate or not rotate arbitrary punctuation and symbols...
# [03:44] <jdaggett> another way to put this is that the current way that mongolian/phags-pa fonts are implemented is just one way to implement them
# [03:44] <fantasai> yes
# [03:44] <jdaggett> and we should avoid pushing implementation details like this back into a unicode property
# [03:44] <fantasai> the WM spec is written for current fonts
# [03:45] <fantasai> the current Unicode spec is written independent of that
# [03:45] <jdaggett> WM == ?
# [03:45] <fantasai> Writing Modes
# [03:45] <fantasai> Writing Modes combines the HO data with the MVO/SVO data to get at the typeset orientation
# [03:46] <fantasai> but the Unicode spec doesn't do that -- HO is an independent thing
# [03:46] <fantasai> and is tied to the code charts
# [03:46] <jdaggett> um, there's no need for HO data in the current WM spec
# [03:46] <fantasai> there is if we're using existing Mongolian fonts :)
# [03:46] <jdaggett> MVO/SVO = R for Mongolian/Phags-pa
# [03:46] <fantasai> No, it's U
# [03:47] <jdaggett> in tr50-5
# [03:47] <fantasai> It's U
# [03:47] <fantasai> look at 1800 block
# [03:47] <fantasai> SVO=MVO=U
# [03:47] <fantasai> http://www.unicode.org/reports/tr50/tr50-5.Orientation.html
# [03:47] <jdaggett> ah, i was looking at Phags-pa which is U R R
# [03:48] <fantasai> heh
# [03:48] <fantasai> That's an error
# [03:48] <jdaggett> you're right, mongolian is L U U
# [03:48] <fantasai> It was corrected I believe
# [03:48] <fantasai> in one of the telecons
# [03:48] <fantasai> hasn't been propagated out to UTR50 yet
# [03:48] <jdaggett> right
# [03:49] <fantasai> We can't publish WM pointing at such broken data, is the problem.
# [03:49] <fantasai> If we can't publish with fixes, then we can't publish at all
# [03:49] <fantasai> So we have to wait
# [03:50] <jdaggett> well, you know my opinion here: just refer to utr50 and fix utr50
# [03:50] <jdaggett> but i think the underlying layout model that ms is using for mongolian/phags-pa is wrong
# [03:52] <jdaggett> they need to fix the opentype model so that both the model used in existing fonts and one that's more appropriate for good vertical layout
# [03:52] <jdaggett> can be used
# [03:52] * fantasai has no disagreement there
# [03:53] <fantasai> The model for Mongolian that MS has is considerably less broken than previous software, btw.
# [03:53] <fantasai> Apparently some software the glyphs are all mirrored so that you can typeset it and then mirror the result
# [03:53] <fantasai> and fun things like that :)
# [03:54] <jdaggett> yeah
# [03:54] <fantasai> But I guess now that you know Mongolian is U
# [03:54] <fantasai> you can understand why we need to combine the data with HO :)
# [03:54] <fantasai> Putting Mongolian U was to keep the Unicode data independent of font implementations
# [03:55] <jdaggett> but using the HO data is locking in the existing model
# [03:55] <jdaggett> so that's a bad idea
# [03:55] <fantasai> That's a consideration for our spec, not for UTR50
# [03:55] <jdaggett> better to simply describe the situation in a note advising implementations
# [03:56] <jdaggett> sure
# [03:56] <jdaggett> but we shouldn't lock in this model or treat this model as the "only" way
# [03:56] <fantasai> I'm happy to say there are other ways, but not happy to make this behavior non-normative if it's the only one that will work correctly in the current situation
# [03:57] <fantasai> It's a similar issue to brackets. They're fundamentally R by Unicode perspective
# [03:57] <fantasai> but we typeset them upright with vert
# [03:57] <fantasai> Because OpenType fonts are written to that assumption
# [03:58] <fantasai> It seems to me OpenType isn't really set up to handle typesetter-chosen orientations
# [03:58] <fantasai> very well
# [03:58] <fantasai> but it's not something I can fix right now.
# [03:59] <jdaggett> i think we first need to get peter constable on board
# [03:59] <jdaggett> with the notion that this isn't the ideal way to do layout for these scripts
# [04:00] <fantasai> Even so, we still have to handle the present
# [04:00] <jdaggett> then we can talk about the appropriate way to address the problem in opentype
# [04:00] <fantasai> We can't write the spec to only handle the far future
# [04:01] <fantasai> Handling both the future and the present is good
# [04:01] <jdaggett> well, you can still use the hacky heuristic
# [04:01] <fantasai> ?
# [04:01] <jdaggett> if only hmetrics, font contains an internal rotation
# [04:01] <jdaggett> else it's the transform is assumed to be the identity transform
# [04:01] <jdaggett> for the mongolian/phags-pa cases
# [04:02] <jdaggett> this deals with existing behavior but allows for the "right" behavior in the future
# [04:03] <fantasai> ok
# [04:03] <fantasai> um
# [04:03] <fantasai> can you write me a handful of spec sentences? :)
# [04:03] <jdaggett> yeah
# [04:03] * fantasai will try to incorporate them into the spec
# [04:03] <jdaggett> but like i say, we'll need to get buy-in from the ms folks
# [04:03] <fantasai> doesn't have to be perfect, just to give me a better idea of what we're aiming at
# [04:04] <jdaggett> ok
# [04:04] <fantasai> IIRC there was ligatures problem, too, for vertical text and OpenType?
# [04:04] <fantasai> I think all those kinds of problems need to be solved before we can get Mongolian to work as upright
# [04:05] <jdaggett> the question is what are the set of default features for vertical runs (i.e. U runs)
# [04:05] <jdaggett> there's nothing that clearly defines this
# [04:05] <jdaggett> one can infer that kern is not but vkrn is
# [04:05] <jdaggett> but that's not actually documented anywhere
# [04:06] <jdaggett> in the horizontal case 'liga' (common ligatures) is on by default
# [04:06] <jdaggett> the question is what happens in the vertical case
# [04:07] <jdaggett> I think the thinking of Eric/Peter C/Behdad was that features should have flags on them
# [04:07] <jdaggett> to indicate vertical-only, horizontal-only
# [04:07] <jdaggett> which would allow different mappings for the vertical/horizontal cases
# [04:09] <glenn> glad 2 see u guys r fixing OT and Unicode both :)
# [04:09] <jdaggett> my head hurts...
# [04:09] <jdaggett> ;)
# [04:10] <fantasai> is there not a vlig feature?
# [04:10] <fantasai> or something like that?
# [04:10] <fantasai> oh
# [04:10] <fantasai> right
# [04:10] <jdaggett> nope
# [04:10] <fantasai> there's lots of different ligature things...
# [04:10] <jdaggett> that's a different way to approach the problem
# [04:10] <fantasai> you'd have to make up v-names for all of them :P
# [04:10] <jdaggett> yup, that's exactly the problem with that approach
# [04:10] <jdaggett> the flags solution is cleaner in that respect
# [04:11] <glenn> i like the idea of having H and V flags on OT lookup tables, similar to how there is already RightToLeft flag (not that this particular flag has ever been used)
# [04:12] <jdaggett> yes, that was exactly the pattern this idea came from
# [04:12] <glenn> of course, the Ignore{BaseGlyphs,Marks} are certainly used
# [04:13] <jdaggett> there was a discussion of this on the OT list a few months ago
# [04:13] <glenn> maybe we can call them IgnoreHorizontal and IgnoreVertical, meaning don't apply in those contexts
# [04:13] <jdaggett> that sounds right
# [04:13] <glenn> as opposed to a flag that says enable in some context (like RightToLeft flat)
# [04:14] <glenn> s/flat/flag/
# [04:14] <jdaggett> existing apps would take all of them but meh...
# [04:17] <jdaggett> fantasai: so i'll try up a description of what i see as problematic
# [04:17] <jdaggett> fantasai: with pictures
# [04:18] <jdaggett> and post to the opentype group about the problems with the underlying model
# [04:20] <fantasai> jdaggett: I understand that kerning's an issue across runs, if that's what you're worried about :)
# [04:21] <jdaggett> well, kerning is the simplest to explain
# [04:23] * Quits: dstorey (Adium@144.189.101.1) (Quit: Leaving.)
# [04:24] <jdaggett> but other substitution or positioning features wouldn't work either
# [04:25] <jdaggett> e.g. adjusting punctuation when it's preceded by a given punctuation character
# [04:27] <jdaggett> er, adjusting punctuation surrounding specific mongolian characters
# [04:31] <fantasai> jdaggett: it seems to me that half the punctuation is rotated and half of it is upright
# [04:32] <fantasai> jdaggett: so it's not clear that setting mongolian upright vs rotated would be a win
# [04:32] <fantasai> jdaggett: it depends on whether your mixing it more with Chinese or Cyrillic
# [04:32] * fantasai notes that Mongolian is alternately written in Cyrillic
# [04:33] <fantasai> jdaggett: you need a solution to breaking runs, generally, to solve this problem well
# [04:34] * Quits: miketayl_r (miketaylr@70.112.101.224) (Quit: dflk;adfslkj;alsiekfj;laiskdf)
# [04:35] * heycam is now known as heycam|away
# [04:36] * Joins: miketaylr (miketaylr@70.112.101.224)
# [04:40] <jdaggett> i'm not pretending to know much about patterns of mongolian usage
# [04:40] <jdaggett> i just think the model needs to be kept clean and not sullied with hacks that ripple out into all sorts of places
# [04:42] <fantasai> It's probably about as much of a hack as rotating Latin is right now :)
# [04:43] <fantasai> That has the same problems.
# [04:44] <jdaggett> you're thinking of alignment?
# [04:44] <fantasai> and kerning
# [04:44] <fantasai> and everything else
# [04:44] <jdaggett> true
# [04:44] <jdaggett> which is why the vrt2 model is the ideal one
# [04:45] <fantasai> the problem with that is that the font decides which characters to rotate and which not
# [04:45] <fantasai> which might be something you want as an option
# [04:45] <jdaggett> yup
# [04:45] <fantasai> but other people want to decide the rotation explicitly
# [04:45] <fantasai> so you want vrt2 with per-glyph feature tweaking somehow... to say "no, I want this upright " or "no, I want this sideways"
# [04:46] * fantasai doesn't know if that's possible
# [04:46] <fantasai> does changing OpenType features break a run?
# [04:47] <jdaggett> yes but you still have context available (or you should, not saying our implementation is 100% correct)
# [04:47] <fantasai> ok
# [04:48] <jdaggett> fonts have a max context field
# [04:48] <jdaggett> which let's the implementation know how far back a lookup might be needed
# [04:49] <fantasai> nice
# [04:58] * heycam|away is now known as heycam
# [05:32] * Joins: dstorey (Adium@67.180.84.179)
# [05:46] * Joins: tantek (tantek@173.164.85.85)
# [06:10] * Joins: jet (jet@24.5.42.61)
# [06:24] * Quits: jet (jet@24.5.42.61) (Quit: jet)
# [06:59] * Quits: tantek (tantek@173.164.85.85) (Quit: tantek)
# [07:01] * Quits: miketaylr (miketaylr@70.112.101.224) (Quit: dflk;adfslkj;alsiekfj;laiskdf)
# [07:32] * Joins: tantek (tantek@76.115.51.221)
# [09:48] * Joins: florianr (florianr@91.203.97.251)
# [10:08] * Joins: drublic (drublic@95.115.33.68)
# [10:11] * Quits: drublic (drublic@95.115.33.68) (Ping timeout)
# [10:24] * Quits: tantek (tantek@76.115.51.221) (Quit: tantek)
# [10:45] * Joins: drublic (drublic@93.132.252.175)
# [10:58] * Quits: dstorey (Adium@67.180.84.179) (Quit: Leaving.)
# [11:06] * Quits: glenn (gadams@174.29.112.73) (Client exited)
# [11:08] * Joins: glenn (gadams@174.29.112.73)
# [11:08] * Quits: glenn (gadams@174.29.112.73) (Client exited)
# [11:14] * Joins: Ms2ger (Ms2ger@91.181.79.187)
# [11:19] * heycam is now known as heycam|away
# Session Close: Wed Jul 04 14:32:19 2012
#
# Session Start: Wed Jul 04 14:32:19 2012
# Session Ident: #css
# [14:32] * Disconnected
# [14:34] * Attempting to rejoin channel #css
# [14:34] * Rejoined channel #css
# [16:58] * Joins: glenn (gadams@174.29.112.73)
# [17:54] * Joins: jet (jet@67.169.43.128)
# [17:56] * Quits: jet (jet@67.169.43.128) (Quit: jet)
# [17:59] <fantasai> HEY EVERYONE I just updated the DoCs for css3-values and css3-flexbox
# [17:59] <fantasai> http://dev.w3.org/csswg/css3-flexbox/issues-lc-2012
# [17:59] <fantasai> http://dev.w3.org/csswg/css3-values/issues-lc-2012
# [17:59] <fantasai> last issue added to values,
# [17:59] <fantasai> issues 8-12 added to flexbox
# [17:59] * sylvaing_away is now known as sylvaing
# [17:59] * fantasai waves to sylvaing
# [18:00] * fantasai will be back in 12 minutes or so, please find some other minute taker today since I'll be talking?
# [18:00] * sylvaing waves back
# [18:01] * Joins: jet (jet@67.169.43.128)
# [18:03] * Quits: jet (jet@67.169.43.128) (Quit: jet)
# [18:04] * Joins: dstorey (Adium@67.180.84.179)
# [18:05] * Joins: oyvind (oyvinds@91.203.97.251)
# [18:06] * Joins: florian (florianr@91.203.96.240)
# [18:07] * Joins: antonp (50ae8432@109.169.29.95)
# [18:07] * Joins: koji (koji@222.158.227.129)
# [18:08] * Joins: Zakim (rrs-bridgg@128.30.52.169)
# [18:08] * Joins: smfr (smfr@173.228.90.242)
# [18:08] <Ms2ger> fantasai, the legend for the color coding isn't consistent :)
# [18:08] * Joins: RRSAgent (rrs-loggee@128.30.52.169)
# [18:08] <RRSAgent> logging to http://www.w3.org/2012/07/04-css-irc
# [18:08] <plinss> zakim, this is style
# [18:08] <Zakim> ok, plinss; that matches Style_CSS FP()12:00PM
# [18:08] * Joins: CesarAcebal (acebal@85.152.178.157)
# [18:08] <Zakim> +smfr
# [18:09] <Zakim> +??P9
# [18:09] <Zakim> + +47.23.69.aaaa
# [18:09] <florian> Zakim, I am aaaa
# [18:09] <Zakim> +florian; got it
# [18:09] <glenn> zakim, ??p9 is glenn
# [18:09] <Zakim> +glenn; got it
# [18:09] <Zakim> +??P5
# [18:09] * Joins: dbaron (dbaron@70.36.140.99)
# [18:09] <Zakim> + +34.60.940.aabb
# [18:10] <CesarAcebal> zakim, aabb is me
# [18:10] <Zakim> +CesarAcebal; got it
# [18:10] <Zakim> +dbaron
# [18:10] <Zakim> +antonp
# [18:13] * Joins: SteveZ (chatzilla@76.126.187.234)
# [18:13] <Zakim> + +1.415.285.aacc
# [18:13] <hober> Zakim, aacc is me
# [18:13] <Zakim> +hober; got it
# [18:14] <Zakim> +fantasai
# [18:14] <Zakim> +SteveZ
# [18:16] <smfr> scribenick: smfr
# [18:16] <Zakim> +[Microsoft]
# [18:17] <fantasai> http://dev.w3.org/csswg/css3-values/issues-lc-2012
# [18:17] <smfr> TOPIC: values and units issues
# [18:17] <smfr> fantasai: issue 18: defining an always invalid url
# [18:17] <smfr> fantasai: computed value of an attr with no default value is UA specific; need to choose something
# [18:17] <smfr> proposal: about:invalid
# [18:18] <smfr> http://dev.w3.org/csswg/css3-values/issues-lc-2012#issue-18
# [18:18] * Joins: Rossen (Rossen@98.225.38.50)
# [18:18] <smfr> fantasai: comments?
# [18:18] <smfr> florian: no strong opinion, but why not?
# [18:18] <fantasai> http://lists.w3.org/Archives/Public/www-style/2012Jun/0689.html
# [18:19] <smfr> dbaron: does the URL in question have to reparse correctly?
# [18:19] <dbaron> s/does/is it ok that/
# [18:19] <smfr> dbaron: so that it could be specified
# [18:19] <smfr> fantasai: i don't know
# [18:19] <fantasai> http://dev.w3.org/csswg/css3-values/#attr-notation
# [18:19] <smfr> fantasai: (reads from the spec)
# [18:20] <fantasai> attr(foo url)
# [18:20] <fantasai> what's the default if there's no foo attribute?
# [18:20] <fantasai> atm it's UA-defined
# [18:20] <fantasai> comment was to define something
# [18:20] <fantasai> we can either leave UA-defined or return 'about:invalid'
# [18:20] <smfr> dbaron: we return it in computed style for urls that failed the url parser
# [18:20] <smfr> dbaron: but we use a different url string
# [18:20] <smfr> dbaron: we're ok switching to this
# [18:21] <smfr> fantasai: any other comments?
# [18:21] <smfr> RESOLVED: use about:invalid as url as the default url in attr()
# [18:21] <fantasai> http://dev.w3.org/csswg/css3-values/issues-lc-2012#issue-25
# [18:22] <fantasai> http://dev.w3.org/csswg/css3-values/#limits
# [18:22] <smfr> florian: there was mailing list discussion
# [18:23] <smfr> dbaron: my feeling is that most of the prose is defining things that I suspect may not be correct
# [18:23] <smfr> dbaron: we are better of postponing this
# [18:23] <smfr> florian: i agree; the intent is good, but lots of trick edge cases
# [18:23] <smfr> florian: would require changes to engines
# [18:25] <smfr> smfr: we don't like the special "close to integer" behavior
# [18:25] <smfr> florian: i don't want to have to do math differently because of htis
# [18:25] <smfr> s/htis/this
# [18:25] <smfr> florian: i don't like the parsing but am willing to do it
# [18:26] <smfr> fantasai: do we want to defer the min/max, or just the prevision and rounding?
# [18:26] <smfr> sylvaing: rounding is controversial, rounding is less so
# [18:26] <smfr> florian: we're still at 25 bits, the intent was 24 bits
# [18:27] <smfr> fantasai: is the 17 correct?
# [18:27] <smfr> florian: for us it's fine
# [18:27] <sylvaing> correction: rounding is controversial but min/max isn't
# [18:28] <smfr> florian: min/max is the safest bit, fine with deferring the whole thing
# [18:28] <smfr> dbaron: ok with the table, would postpone the prose below
# [18:28] <smfr> sylvaing: postponing the whole thing is easiest
# [18:28] <dbaron> s/ok with the table, would/what I was arguing for earlier was to/
# [18:29] <smfr> smfr: do we still have prose about round-tripping values?
# [18:29] <smfr> florian: would still like responses even if it's postponed
# [18:30] <smfr> RESOLVED: defer Appendix A of Values and Units
# [18:30] <fantasai> http://dev.w3.org/csswg/css3-values/issues-lc-2012#issue-28
# [18:30] <fantasai> Proposed to defer to L4
# [18:30] <smfr> fantasai: are there any other proposals?
# [18:30] <smfr> dbaron: postponing is fine
# [18:31] <smfr> RESOLVED: defer issue 28
# [18:31] <fantasai> http://dev.w3.org/csswg/css3-values/issues-lc-2012#issue-29
# [18:31] <smfr> plinss: this may raise an objection from i18n
# [18:31] <fantasai> http://lists.w3.org/Archives/Public/www-style/2012May/0499.html
# [18:32] <smfr> fantasai: identifiers are case-insensitive, but author-defined counter styles are allowed
# [18:33] <smfr> fantasai: describes 3 options in http://lists.w3.org/Archives/Public/www-style/2012May/0499.html
# [18:34] <smfr> florian: option for 1 is to say that @counter-style name are case insensitive in ASCII range only
# [18:35] <smfr> fantasai: proposal to have two kinds of author-defined identifiers; case sensitive and ASCII-case insensitive
# [18:35] <smfr> plinss: don't like the inconsistency
# [18:35] <smfr> florian: we'll have an inconsistency somewhere
# [18:36] <smfr> fantasai: 4th proposal might be to have in css3 all user-defined idents are case-insensitive in the ASCII range
# [18:36] <smfr> probably web compatible but a change from CSS 2.1
# [18:37] <smfr> florian: how much web breakage?
# [18:37] <smfr> fantasai: not much
# [18:37] <smfr> florian: may break because of typos
# [18:37] <smfr> antonp: erring towards proposal 3
# [18:37] <smfr> fantasai: we will probably do this for some other properties like text-transform
# [18:38] <smfr> plinss: like the idea of making them all ASCII-range case insensitive
# [18:38] <smfr> florian: easier to fix now than later
# [18:38] <smfr> dbaron: could be confusing for authors
# [18:38] <dbaron> case-insensitive in the ascii range could be confusing for authors who use non-ascii characters
# [18:39] <smfr> plinss: option 3 sounds a bit hacky
# [18:40] <smfr> sylvaing: how base is unicode case-folding?
# [18:40] <smfr> fantasai: there's a generic version but it's a source of bugs (if UAs call locale-specific routines by mistake)
# [18:40] <sylvaing> s/base/bad
# [18:41] <plinss> zakim, who is noisy?
# [18:41] <smfr> fantasai: only css keywords will get case permutations
# [18:41] <Zakim> plinss, listening for 11 seconds I heard sound from the following: sylvaing (52%), SteveZ (21%)
# [18:41] <smfr> Zakim: mute SteveZ
# [18:42] <smfr> florian: we already have this code elsewhere
# [18:42] <smfr> fantasai: yes, for text-transform
# [18:42] <smfr> sylvaing: you're breaking up
# [18:42] <fantasai> 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
# [18:42] <smfr> dbaron: there's a performance cost
# [18:43] <smfr> florian: or you convert to lowercase
# [18:43] <smfr> fantasai: you say that the computed value is the case-folded value
# [18:43] <smfr> sylvaing: was asking if the complexity was worth the inconsistency
# [18:44] <smfr> florian: does anyone dislike this?
# [18:44] <smfr> dbaron: would want to go back and look at why we changed this for 2.1
# [18:45] <smfr> dbaron: there were things that were originally case-insensitive and we changed them to case sensitive
# [18:45] <smfr> fantasai: there are some things that would case-fold into the ascii range, and we didn't' want that
# [18:46] <smfr> florian: can we temporarily resolve?
# [18:46] <smfr> fantasai: we could defer author identifier types from level 3?
# [18:46] <smfr> florian: this would go in CR now?
# [18:46] <smfr> fantasai: author ident is not actually used anywhere
# [18:47] <smfr> smfr: aren't animation names author idents?
# [18:47] <smfr> fantasai: yes
# [18:47] <smfr> plinss: i think we should do this in level 3
# [18:47] <smfr> http://lists.w3.org/Archives/Public/www-style/2012May/0499.html
# [18:47] <fantasai> http://lists.w3.org/Archives/Public/www-style/2012May/0499.html
# [18:47] <smfr> dbaron: i would prefer one of the other options
# [18:48] <smfr> florian: we've been proposing 1a for all ...
# [18:48] <smfr> dbaron: i don't think we should reopen the whole case sensitivity discussion
# [18:48] <smfr> plinss: we'll have more places where authors can define things; will be a source of confusion
# [18:49] <smfr> dbaron: want text with references and citations if we go for one of the 1) options
# [18:49] <smfr> and a week to review
# [18:49] <fantasai> http://unicode.org/Public/UNIDATA/CaseFolding.txt
# [18:50] <smfr> fantasai: i can spec it but am concerned about computed values being lowercased
# [18:50] <smfr> fantasai: i will try to spec that
# [18:50] <smfr> dbaron: why didn't we choose this option for 2.1?
# [18:51] <smfr> fantasai: there were no places where author keywords and UA keywords were mixed up
# [18:52] * Parts: antonp (50ae8432@109.169.29.95)
# [18:52] <smfr> smfr: describes issue with animation names
# [18:52] <smfr> authors have to be able to do the same case-folding in JS to compare animation names
# [18:53] * Joins: antonp (50ae8432@109.169.29.95)
# [18:53] <smfr> keyword idents show up in animation events
# [18:53] * Quits: antonp (50ae8432@109.169.29.95) (Quit: http://www.mibbit.com ajax IRC Client)
# [18:53] <smfr> plinss: we'd need a JS function
# [18:53] * Joins: antonp (50ae8432@207.192.75.252)
# [18:53] <smfr> sylvaing: hard to introduce a new function for this
# [18:54] <smfr> dbaron: i don't think parse-time folding is web compatible, because we've never done that before
# [18:54] <smfr> florian: other options are 2 and 3
# [18:55] <smfr> fantasai: 2 is weird, 3 maybe makes more sense
# [18:56] <smfr> plinss: issues with option 1 are the same issues we've run into with unicode normalization
# [18:56] <smfr> plinss: we'll have to deal with that anyway
# [18:56] <SteveZ> does not 3 have all the string matching problems of 1 and 2.
# [18:57] <smfr> plinss: i don't think that case-folding at parse time is the right thing
# [18:57] <smfr> it should happen at comparison time
# [18:57] <smfr> florian: but that's an issue in JS
# [18:57] * fantasai is sad we spent the entire 4th of July telecon on casing :(
# [18:57] * sylvaing my bad...
# [18:57] <smfr> dbaron: authors aren't going to understand
# [18:57] <SteveZ> and not even shell casings!!
# [18:58] <smfr> plinss: would like to see a plan to resolve this
# [18:59] <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
# [18:59] <smfr> plinss: would dbaron be willing to review some new text defining option 1 with new stuff
# [18:59] <smfr> dbaron: i would
# [18:59] <fantasai> http://dev.w3.org/csswg/css3-values/issues-lc-2012#issue-35
# [18:59] <dbaron> s/i would/it's option 1 plus a lot of other things. But I would./
# [19:00] <fantasai> whether calc should make whitespace optional around + -
# [19:00] <smfr> fantasai: because - forms part of an ident
# [19:00] <smfr> rejected because it means you can't put keywords in calc in future
# [19:00] <fantasai> http://lists.w3.org/Archives/Public/www-style/2012May/0463.html
# [19:00] <Zakim> -antonp
# [19:01] <fantasai> proposal: no change, white space is required
# [19:01] <smfr> fantasai: saying no change to calc, whitespace is required around + and -
# [19:01] <smfr> hober: why not require it around / and * for consistency
# [19:01] <smfr> fantasai: they don't need it
# [19:01] <smfr> smfr: hard for authors to remember where to put whitespace
# [19:02] * antonp has a phone connectivity problem right now...
# [19:02] <fantasai> fantasai: just put white space everywhere
# [19:03] <fantasai> fantasai: */ bind tigheter than + and - , so the current requirements make sense
# [19:03] <smfr> dbaron: gecko implements what the spec says
# [19:03] * Quits: SteveZ (chatzilla@76.126.187.234) (Ping timeout)
# [19:04] <smfr> RESOLVED: accept the rejection of this issue
# [19:04] <smfr> plinss: do we want to require whitespace around / and *?
# [19:04] <smfr> dbaron/fantasai/florian: do not want
# [19:04] <oyvind> so the summary of issue 35 seems wrong - "should allow white space" should really say "shouldn't require white space" or something?
# [19:04] <fantasai> yeah, I'll fix it
# [19:05] <smfr> RESOLVED: leave the rest alone
# [19:05] <fantasai> http://dev.w3.org/csswg/css3-flexbox/issues-lc-2012
# [19:05] <smfr> fantasai: issue links are 404s: http://dev.w3.org/csswg/css3-flexbox/issue-11
# [19:05] * fantasai will fix
# [19:06] <dbaron> Issue 11 has a typo in the name of the commenter
# [19:06] <fantasai> http://lists.w3.org/Archives/Public/www-style/2012Jun/0668.html
# [19:06] <smfr> Issue 5: painting atomically: decided to reject
# [19:07] <smfr> dbaron: they should do what inline-block and inline-tables do
# [19:07] <smfr> fantasai: or should they do what table cells do?
# [19:07] <smfr> appendix E doesn't say what table cells do
# [19:08] <smfr> fantasai: how about we resolve to have them do what table cells do?
# [19:08] <smfr> dbaron: not confident that 2.1 Appendix E is correct for table cells
# [19:09] <smfr> ACTION: dbaron to review appendix E and table cells, in relation to flexbox
# [19:09] * trackbot noticed an ACTION. Trying to create it.
# [19:09] * RRSAgent records action 1
# [19:09] <trackbot> Created ACTION-482 - Review appendix E and table cells, in relation to flexbox [on David Baron - due 2012-07-11].
# [19:09] * sylvaing unicode casing and appendix E. is this july 4th or death wish day?
# [19:09] * hober hahahhaha
# [19:09] <smfr> issue 4: 'order' might be too generic a name
# [19:09] <antonp> Agree with dbaron, not at all sure Appendix E handles table stuff well
# [19:10] <antonp> Some bugs are open on that
# [19:10] <smfr> issue 3: does 'order' affect speech and tab order
# [19:10] <smfr> point of order is to change visual order, not order for speech etc.
# [19:10] <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%
# [19:10] <dbaron> 3C%2Ftable%3E shows 2.1 appendix E is actually correct for table cells
# [19:10] <smfr> fantasai: but if it's just paint order, should it have a more specific name
# [19:11] <dbaron> but I rather prefer the float/inline-block behavior
# [19:11] <smfr> plinss: makes sense to have a more specific name
# [19:11] <smfr> florian: we need to resolve issue 3 first
# [19:11] <fantasai> http://lists.w3.org/Archives/Public/www-style/2012Jul/0046.html
# [19:12] <smfr> florian: was john folio fine with the proposal?
# [19:12] <smfr> fantasai: he didn't have a strong opinion
# [19:13] <fantasai> Foliot's response: http://lists.w3.org/Archives/Public/www-style/2012Jun/0481.html
# [19:13] <smfr> s/folio/foliot
# [19:13] <fantasai> http://dev.w3.org/csswg/css3-flexbox/#overview
# [19:13] <fantasai> http://dev.w3.org/csswg/css3-flexbox/#order-property
# [19:13] <dbaron> also all the "#" links in the DoC are broken
# [19:14] * fantasai knows, will fix
# [19:14] <smfr> fantasai gives order examples
# [19:15] <smfr> RESOLVED: issue 3; order does not affect tab order or speech order
# [19:15] <smfr> plinss: should we change the name to display-order?
# [19:16] <fantasai> smfr: I agree with the name change
# [19:16] <smfr> RESOLVED: rename 'order' to something more specific
# [19:16] <smfr> fantasai: box-order or display-order
# [19:17] <smfr> florian: display-order looks like a longhand for display, don't like
# [19:17] <smfr> plinss: other option is flex-order
# [19:17] <smfr> florian: or visual-order
# [19:18] <smfr> dbaron: it sounds like z-order
# [19:18] <smfr> (which is z-index)
# [19:18] <Zakim> -smfr
# [19:18] <glenn> is visual order same as reading order?
# [19:18] <smfr> gah, call dropped
# [19:18] <fantasai> hober: paint-order?
# [19:18] <dbaron> fantasai: display-order implies affecting paint order too; I understand the longhand issue but I think we should go with that
# [19:18] <smfr> it must be past 10...
# [19:18] <fantasai> ScribeNick: fantasai
# [19:19] * smfr can't call back in
# [19:19] <fantasai> florian proposes straw-polling
# [19:19] * fantasai will minute for you
# [19:19] <fantasai> someone asks to move to next week
# [19:19] <dbaron> Rossen: Alex had an opinion, but not sure what it was
# [19:19] * Joins: SteveZ (chatzilla@76.126.187.234)
# [19:19] <fantasai> Meeting closed.
# [19:20] <dbaron> We might have 'order' committed to the tree by next week
# [19:20] <Zakim> -hober
# [19:20] <Zakim> -glenn
# [19:20] <Zakim> -florian
# [19:20] <Zakim> -plinss
# [19:20] * Quits: SteveZ (chatzilla@76.126.187.234) (Quit: ChatZilla 0.9.88.2 [Firefox 13.0.1/20120614114901])
# [19:20] <Zakim> -dbaron
# [19:20] <Zakim> -CesarAcebal
# [19:20] <Zakim> -[Microsoft]
# [19:20] <Zakim> -sylvaing
# [19:20] * Quits: smfr (smfr@173.228.90.242) (Quit: smfr)
# [19:20] * Parts: CesarAcebal (acebal@85.152.178.157)
# [19:20] <Zakim> -??P5
# [19:20] <Rossen> Zakim, [Microsoft] is me
# [19:20] <Zakim> sorry, Rossen, I do not recognize a party named '[Microsoft]'
# [19:22] <Zakim> -SteveZ
# [19:23] * Quits: koji (koji@222.158.227.129) (Quit: Leaving...)
# [19:27] <Zakim> disconnecting the lone participant, fantasai, in Style_CSS FP()12:00PM
# [19:27] <Zakim> Style_CSS FP()12:00PM has ended
# [19:27] <Zakim> Attendees were sylvaing, plinss, smfr, +47.23.69.aaaa, florian, glenn, +34.60.940.aabb, CesarAcebal, dbaron, antonp, +1.415.285.aacc, hober, fantasai, SteveZ, [Microsoft]
# [19:27] <fantasai> sylvaing: On the plus side, LC closed yesterday, so there will be no more issues
# [19:27] <fantasai> sylvaing: and therefore no more renaming :p
# [19:28] <fantasai> sylvaing: but still, >_____<;;;;;;
# [19:29] * fantasai DoCs are hard, lets make pretty diagrams~
# [19:29] * fantasai works on updating the DoC
# [19:32] * Quits: antonp (50ae8432@207.192.75.252) (Quit: http://www.mibbit.com ajax IRC Client)
# [19:39] * Parts: oyvind (oyvinds@91.203.97.251)
# [19:39] <dbaron> fantasai, mind if I fix some typos in the DoC's, or are you editing?
# [19:40] <fantasai> I'm editing values atm
# [19:41] <fantasai> but not flexbox, so go ahead
# [19:41] <fantasai> pull first, though :)
# [19:42] <dbaron> ok, done
# [19:42] <fantasai> thanks~
# [19:45] * Parts: florian (florianr@91.203.96.240)
# [19:47] <fantasai> ok, pushed out edits and DoC updates
# [19:47] * fantasai will deal with minutes later, kindof want breakfast
# [19:48] * Quits: Rossen (Rossen@98.225.38.50) (Quit: Rossen)
# [19:50] <dbaron> fantasai, ok, I pushed one typo fix to the values DoC now
# [20:12] * Quits: SimonSapin (simon@82.232.219.95) (Ping timeout)
# [20:20] * fantasai pulls
# [20:47] * Quits: drublic (drublic@93.132.252.175) (Client exited)
# [20:47] * Joins: drublic (drublic@93.132.252.175)
# [20:48] * Joins: drublic_ (drublic@93.132.252.175)
# [20:48] * Quits: drublic (drublic@93.132.252.175) (Connection reset by peer)
# [20:51] * Quits: drublic_ (drublic@93.132.252.175) (Ping timeout)
# [21:04] <fantasai> Ms2ger: fixed, if I understood correctly
# [21:05] <Ms2ger> You did
# [21:26] <fantasai> glenn: just caught your IRC question now
# [21:26] <fantasai> glenn: That depends on whether you're using a visual navigation or a logical one
# [21:27] <fantasai> glenn: but the expectation is that a document that is being read from start to finish
# [21:27] <fantasai> glenn: will follow logical order, i.e. the source order
# [21:34] * Zakim excuses himself; his presence no longer seems to be needed
# [21:34] * Parts: Zakim (rrs-bridgg@128.30.52.169)
# [22:05] * Quits: dstorey (Adium@67.180.84.179) (Quit: Leaving.)
# [22:16] * Quits: Ms2ger (Ms2ger@91.181.79.187) (Quit: nn)
# [22:21] * sylvaing is now known as sylvaing_away
# [22:46] * Joins: drublic (drublic@95.115.33.68)
# Session Close: Thu Jul 05 00:00:00 2012

The end :)