/irc-logs / w3c / #css / 2013-02-04 / end

Options:

# Session Start: Mon Feb 04 00:00:00 2013
# Session Ident: #css
# [00:08] * Joins: dbaron (~dbaron@public.cloak)
# [00:38] * Quits: dbaron (~dbaron@public.cloak) (Ping timeout: 60 seconds)
# [01:56] * Joins: glenn (~gadams@public.cloak)
# [02:24] * Joins: isherman-book (~Adium@public.cloak)
# [02:27] * Joins: cabanier (~cabanier@public.cloak)
# [02:52] * Joins: lmclister (~lmclister@public.cloak)
# [03:15] * Quits: isherman-book (~Adium@public.cloak) ("Leaving.")
# [03:46] * Joins: isherman-book (~Adium@public.cloak)
# [03:54] * Quits: isherman-book (~Adium@public.cloak) (Ping timeout: 60 seconds)
# [04:09] * Quits: glenn (~gadams@public.cloak) (Client closed connection)
# [04:10] * Joins: glenn (~gadams@public.cloak)
# [04:15] * Joins: isherman-book (~Adium@public.cloak)
# [04:17] * Quits: lmclister (~lmclister@public.cloak) ("")
# [04:32] * Quits: isherman-book (~Adium@public.cloak) ("Leaving.")
# [04:55] * Joins: lmclister (~lmclister@public.cloak)
# [04:56] * Quits: lmclister (~lmclister@public.cloak) ("")
# [04:56] * Joins: dbaron (~dbaron@public.cloak)
# [05:05] * Quits: dbaron (~dbaron@public.cloak) (Ping timeout: 60 seconds)
# [05:18] * Joins: isherman-book (~Adium@public.cloak)
# [05:46] * Quits: isherman-book (~Adium@public.cloak) ("Leaving.")
# [06:06] * Joins: isherman-book (~Adium@public.cloak)
# [06:27] * Quits: isherman-book (~Adium@public.cloak) ("Leaving.")
# [06:32] * Quits: Bert (bbos@public.cloak) (Ping timeout: 60 seconds)
# [06:50] * Joins: Bert (bbos@public.cloak)
# [06:50] * Joins: dbaron (~dbaron@public.cloak)
# [06:57] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [07:05] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [07:34] * leaverou is now known as leaverou_away
# [07:37] * heycam is now known as heycam|away
# [07:37] * Quits: cabanier (~cabanier@public.cloak) ("Leaving.")
# [07:49] * Joins: SimonSapin (~simon@public.cloak)
# [07:49] <dbaron> fantasai: are some of you sending issues from the same place?
# [07:49] <dbaron> BTW, I could swear we resolved something about the floor() issue in css3-transitions, but I can't find it...
# [08:03] * Quits: SimonSapin (~simon@public.cloak) ("Leaving.")
# [08:21] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [08:36] * Quits: dbaron (~dbaron@public.cloak) (Ping timeout: 60 seconds)
# [08:38] * Joins: dbaron (~dbaron@public.cloak)
# [08:44] * Quits: dbaron (~dbaron@public.cloak) (Ping timeout: 60 seconds)
# [09:01] * Joins: isherman-book (~Adium@public.cloak)
# [09:30] * Joins: nvdbleek1 (~nvdbleek@public.cloak)
# [09:30] * Quits: nvdbleek (~nvdbleek@public.cloak) (Client closed connection)
# [09:52] * Quits: nvdbleek1 (~nvdbleek@public.cloak) ("Leaving.")
# [09:52] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [09:53] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [09:53] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [09:54] * Joins: Ms2ger (~Ms2ger@public.cloak)
# [09:56] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [09:56] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [09:58] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [09:58] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [10:00] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [10:00] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [10:01] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [10:01] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [10:03] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [10:03] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [10:05] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [10:05] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [10:06] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [10:06] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [10:08] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [10:08] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [10:26] * Quits: isherman-book (~Adium@public.cloak) ("Leaving.")
# [10:41] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [10:41] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [10:43] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [10:43] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [10:46] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [10:46] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [10:51] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [10:51] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [10:53] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [10:53] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [10:55] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [10:55] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [11:01] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [11:01] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [11:13] * leaverou_away is now known as leaverou
# [11:37] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [11:37] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [11:38] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [11:38] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [11:40] * leaverou is now known as leaverou_away
# [11:40] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [11:40] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [11:41] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [11:41] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [11:43] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [11:43] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [11:54] * Quits: rhauck1 (~Adium@public.cloak) (Client closed connection)
# [11:55] * Joins: rhauck (~Adium@public.cloak)
# [12:35] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [12:35] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [13:06] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [13:06] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [13:11] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [13:11] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [13:12] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [13:12] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [13:13] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [13:13] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [13:14] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [13:14] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [13:16] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [13:16] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [13:18] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [13:18] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [13:21] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [13:21] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [13:21] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [13:21] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [13:23] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [13:23] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [13:25] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [13:25] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [13:26] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [13:26] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [14:33] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [14:33] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [14:42] * Joins: logbot (~logbot@public.cloak)
# [14:46] * Quits: logbot (~logbot@public.cloak) (Client closed connection)
# [14:46] * Joins: logbot (~logbot@public.cloak)
# [14:56] * Joins: tmpsantos (~tmpsantos@public.cloak)
# [15:09] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [15:09] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [15:12] * leaverou_away is now known as leaverou
# [15:36] * Joins: SimonSapin (~simon@public.cloak)
# [15:36] * Quits: glenn (~gadams@public.cloak) (Client closed connection)
# [15:56] * Quits: SimonSapin (~simon@public.cloak) ("Leaving.")
# [15:56] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [15:56] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [16:10] * Joins: franremy (~franremy@public.cloak)
# [16:23] * Joins: dbaron (~dbaron@public.cloak)
# [16:31] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [16:31] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [16:33] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [16:33] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [16:36] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [16:36] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [16:40] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [16:40] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [16:41] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [16:41] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [16:43] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [16:43] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [16:44] * Quits: dbaron (~dbaron@public.cloak) (Ping timeout: 60 seconds)
# [16:46] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [16:46] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [16:51] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [16:51] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [16:54] * Joins: teoli (~teoli@public.cloak)
# [17:10] * Joins: glazou (~glazou@public.cloak)
# [17:10] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [17:10] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [17:10] * Joins: SimonSapin (~SimonSapin@public.cloak)
# [17:10] * Joins: molly (~molly@public.cloak)
# [17:11] * Quits: SimonSapin (~SimonSapin@public.cloak) ("")
# [17:11] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [17:11] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [17:11] * Joins: SimonSapin (~SimonSapin@public.cloak)
# [17:11] * Joins: rhauck1 (~Adium@public.cloak)
# [17:11] * Joins: glenn (~glenn@public.cloak)
# [17:13] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [17:13] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [17:14] * Quits: rhauck (~Adium@public.cloak) (Ping timeout: 60 seconds)
# [17:14] * Quits: rhauck1 (~Adium@public.cloak) (Client closed connection)
# [17:16] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [17:16] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [17:17] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [17:17] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [17:22] * Joins: tmpsantos__ (~tmpsantos@public.cloak)
# [17:22] * Quits: tmpsantos (~tmpsantos@public.cloak) (Ping timeout: 60 seconds)
# [17:22] * Quits: tmpsantos__ (~tmpsantos@public.cloak) (Client closed connection)
# [17:23] * Joins: lmclister (~lmclister@public.cloak)
# [17:30] <glazou> we have major connecting to the network, stay tuned
# [17:30] <glazou> major issues
# [17:30] * Joins: TabAtkins_ (~TabAtkins@public.cloak)
# [17:32] <TabAtkins_> ScribeNick: TabAtkins_
# [17:32] * Joins: tantek (~tantek@public.cloak)
# [17:33] * Joins: Rossen (~Rossen@public.cloak)
# [17:33] * Joins: jdaggett (~jdaggett@public.cloak)
# [17:33] * jdaggett wow neat!
# [17:34] * Joins: dbaron (~dbaron@public.cloak)
# [17:34] * Joins: smfr (~smfr@public.cloak)
# [17:35] <TabAtkins_> [discussing agenda]
# [17:35] * dbaron set up a SOCKS proxy on an ssh connection and configured XChat to use it
# [17:36] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [17:36] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [17:37] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [17:37] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [17:39] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [17:39] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [17:39] <Ms2ger> nvdbleek, your connection doesn't seem to be working all that well either :)
# [17:43] * nvdbleek ;)
# [17:44] * nvdbleek now I'll be going down for longer (going home)
# [17:44] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [17:44] <TabAtkins_> Topic: Case Sensitivity
# [17:45] <TabAtkins_> jdaggett: I think we had a rough consensus on the mailing list, but Tab didn't agree with it.
# [17:45] <TabAtkins_> TabAtkins_: I'm okay with the consensus now.
# [17:45] <TabAtkins_> jdaggett: the specific issue in question is the case-sensitivity of user identifiers.
# [17:45] <Ms2ger> What is the consensus?
# [17:46] <TabAtkins_> jdaggett: They show up in counter names, @font-feature-values, etc.
# [17:46] * Joins: koji (~koji@public.cloak)
# [17:46] * TabAtkins_ We'll get to it, ms2ger.
# [17:46] <TabAtkins_> jdaggett: Of those, the counter styles spec is the one that's the stickiest situation, because you have a mix of predefined (CSS-defined) and user-defined counter styles.
# [17:46] <TabAtkins_> jdaggett: Depending on the CS matching rules, the two groups might match differently.
# [17:47] <TabAtkins_> jdaggett: We got a recommendation from i18nWG that CS matching made sense.
# [17:47] <TabAtkins_> jdaggett: But if we're really set of doing a form of CI, we should do the unicode-aware type that they describe.
# [17:47] <TabAtkins_> jdaggett: One caveat - if we're matching keywords, we're generally using ASCII CI, so only alphabetic characters.
# [17:48] <TabAtkins_> jdaggett: Otherwise there are weird cases, like the Kelvin character matching "k".
# [17:48] <TabAtkins_> jdaggett: So I think we should follow i18n's recommendation: use CS matching for user idents, and ASCII CI matching for CSS-defined idents.
# [17:48] * Joins: smfr_ (~smfr@public.cloak)
# [17:48] * Quits: smfr (~smfr@public.cloak) ("Page closed")
# [17:48] * smfr_ is now known as smfr
# [17:49] <TabAtkins_> jdaggett: Only difference is font-family matching - if I put "arial", it'll match the "Arial" font.
# [17:49] <TabAtkins_> glenn: I think you mean that the platform has a font-name matching algo that was unspecified, and it looks to be CI in some cases.
# [17:49] <TabAtkins_> jdaggett: Let me put it more clearly - browsers match fonts CI. But they can have localized names.
# [17:50] <TabAtkins_> jdaggett: And so for font names specifically, I think we should use unicode-aware CI matching. We can't rely on the platform's mapping.
# [17:50] <TabAtkins_> glenn: Are you saying that we should define the whole font-matching algorithm?
# [17:50] <TabAtkins_> jdaggett: It's a name.
# [17:50] <TabAtkins_> glenn: Right now, how the name maps to the font has been platform-specific, and under the covers.
# [17:50] <TabAtkins_> glenn: I'm wondering if what you're suggesting is bitying off a larger prbolem than we can solve here.
# [17:51] <TabAtkins_> jdaggett: I think you're getting at that font -name matching is platform dependent?
# [17:51] <TabAtkins_> jdaggett: Right now it's not - it's CI, with an edge case for localized names.
# [17:51] <TabAtkins_> glenn: What I mean is that they're unspecified - if they have similar behavior, it's due to reverse engineering, not a spec.
# [17:51] * Joins: kawabata (~kawabata@public.cloak)
# [17:52] <TabAtkins_> jdaggett: CSS3 Fonts has a specific line that says you must match against the localized name. But until now it used the locale of the OS, which introduced inconsistencies.
# [17:52] <TabAtkins_> jdaggett: We need to clarify what the CI matching rules are for font-family names, where font-family names on a platform can include localized names.
# [17:52] * dbaron plinss, is it ok to edit the agenda wiki (to add a link) now?
# [17:53] <TabAtkins_> glenn: Where's the font matching rules? 2.1?
# [17:53] <TabAtkins_> jdaggett: Fonts 3. 2.1 just says "case insensitive".
# [17:53] * Joins: Kazutaka (~Kazutaka@public.cloak)
# [17:53] <TabAtkins_> jdaggett: So are people okay with this?
# [17:53] <TabAtkins_> [general agreement]
# [17:53] <TabAtkins_> plinss: Aren't counter names CI?
# [17:54] <TabAtkins_> jdaggett: No, CS on all browsers.
# [17:54] <TabAtkins_> fantasai: It's counter *styles* that are the issue - currently they're all CSS-defined, but we're going to be adding user-defined ones.
# [17:54] <TabAtkins_> fantasai: So anything in the former set is going to have to be case-folded into ASCII lowercase.
# [17:55] <TabAtkins_> jdaggett: So when we're matching CSS-defined things, it's ASCII CI. When we're matching user idents, it's CS.
# [17:55] <TabAtkins_> jdaggett: When matching font-family names, it looks like we have to specify unicode caseless matching. The parameters are that we use the C+F casing rules.
# [17:56] <TabAtkins_> jdaggett: No normalization, no tailoring.
# [17:56] <TabAtkins_> TabAtkins_: And that's what the i18nWG recommended.
# [17:56] <fantasai> It's not just that we're adding user-defiend ones, we're redefining the CSS-defined keywords to be author-defined keywords whose @-rules are given in the UA style sheet.
# [17:57] <fantasai> That is why this issue exists; otherwise it's the same as counter-reset
# [17:57] <TabAtkins_> glenn: We should word it so that it's extensible.
# [17:57] <TabAtkins_> glenn: So that we dont' lock ourselves in later.
# [17:57] <TabAtkins_> TabAtkins_: We can override ourselves later if necessary. We can just be clear with a general rule now.
# [17:58] <TabAtkins_> jdaggett: We need to make it clear to develoeprs that special exceptions for Turkish or Greek aren't a part of this. That's important.
# [18:01] * Quits: liam (liam@public.cloak) ("travel to xquery f2f and thence to workshop and toc")
# [18:01] <TabAtkins_> TabAtkins_: So the font-face matching rules are more complicated due to legacy?
# [18:01] <TabAtkins_> [missed minutes, but more or less yes]
# [18:02] <TabAtkins_> fantasai: I'm curious why we're using C+F rather than C+S.
# [18:02] <TabAtkins_> TabAtkins_: That's what i18nWG said to do.
# [18:03] * Joins: rhauck (~Adium@public.cloak)
# [18:04] <TabAtkins_> Bert: I'm not sure I like matching two different ways. We should be case-insensitive everywhere.
# [18:04] <TabAtkins_> TabAtkins_: You can't. CSS already has a mix of CI and CS.
# [18:06] <glazou> that sounds soooooo 1997...
# [18:06] <TabAtkins_> jdaggett: The general rule on the platform right now is that anything the author creates (class names, ids, counter names, etc.) are CS.
# [18:06] <TabAtkins_> tantek: That matches all other modern languages.
# [18:09] <TabAtkins_> RESOLVED: CSS-defined things are matched ASCII CI. User-defined things are matching CS. Font-family names, for "legacy" reasons, are matched Unicode CI (C+F casing rules, per i18n recommendation).
# [18:10] <TabAtkins_> [discussion about variables]
# [18:10] <dbaron> discussion that in 'var-foo', the "var" is CI and the "foo" is CS
# [18:10] <TabAtkins_> fantasai: There's an issue about CSSOM serialization. The APIs return the lowercase form. That should be clearly specified.
# [18:11] <TabAtkins_> molly: [question about class names being CS]
# [18:12] <TabAtkins_> fantasai: The interesting thing about counter styles is that if you do @counter-style for a predefined type, it will be matched ASCII CI.
# [18:14] <TabAtkins_> [more kvetching about what "unicode case folding" means]
# [18:17] <dbaron> jdaggett: the resolution also needs to say there's no normalization and no language-specific tailorings
# [18:17] <TabAtkins_> RESOLVED: (appending to the previous resolution) Font matching is done without normalization, without language-specific tailorings.
# [18:18] * fantasai proposes we resolve that CSS will not introduce keywords that include bicameral letters outside the ASCII range, to satisfy Bert's concern about future caseless keyword matchings
# [18:18] <TabAtkins_> Bert: Is font-matching up for us to define? Is it for the system?
# [18:18] <TabAtkins_> jdaggett: it's possible to say it's for the UA, but...
# [18:19] <TabAtkins_> jdaggett: Nobody implements a caseless matching that you can point at specified anywhere. They're all ad-hoc.
# [18:19] * Joins: plinss_ (~plinss_@public.cloak)
# [18:19] <TabAtkins_> jdaggett: HTML5 has one case where they say "use this type of caseless matching, for legacy reasons". They're basing it off of unicode, but the way they're doing it (based on how IE matches radio group names) has oddities regarding diacritics.
# [18:20] <TabAtkins_> Bert: I have a problem font-matching sometimes, but it's about which font name the browser is using.
# [18:20] <TabAtkins_> jdaggett: I think that's a Windows-specific issue that'll be less of ap roblem going forward.
# [18:20] * Quits: smfr (~smfr@public.cloak) (Ping timeout: 60 seconds)
# [18:21] * Ms2ger notes that it's not actually clear if that unicode caseless match is required
# [18:21] <fantasai> Bert: I want to ensure that we don't have any cases in the spec where some letters in a word are case-insensitively matched, but others are.
# [18:21] <TabAtkins_> Bert: I don't like the word "ASCII case-insensitive". That word should die.
# [18:21] <dbaron> Bert: The words "ASCII case-insensitive" should never appear in our specifications.
# [18:22] <TabAtkins_> jdaggett: If you say "it's matched as unicode case-insensitive, but we'll only use ASCII chars", that is *actually different*. And it makes testing earlier.
# [18:22] <fantasai> http://www.w3.org/TR/CSS21/syndata.html#characters
# [18:22] <fantasai> All CSS syntax is case-insensitive within the ASCII range (i.e., [a-z] and [A-Z] are equivalent)
# [18:23] * Joins: smfr (~smfr@public.cloak)
# [18:23] * Ms2ger ... and that's a spec Bert edits
# [18:24] * glazou Ms2ger chhhttttt :-)
# [18:24] * dbaron dbaron { VİSİBİLİTY: hıdden }
# [18:24] <tantek> dbaron lol
# [18:24] * Joins: isherman-book (~Adium@public.cloak)
# [18:25] * Ms2ger does for ASCII case-insensitive, can still see dbaron :)
# [18:25] <dbaron> Peter: There's no point in the CSS WG resolving that the CSS WG can't do something in the future, since we can just change that resolution in the future.
# [18:25] <TabAtkins_> Bert: I just dont' want us to suggest that sometimes in the future we'll have a CSS-defined thing with unicode letters.
# [18:26] <TabAtkins_> jdaggett: HTML has actually gone through and extinguished a lot of places that were ASCII CI.
# [18:26] <TabAtkins_> jdaggett: New things, and old things they coudl get away with, are all CS now. That's a wonder.
# [18:26] <TabAtkins_> jdaggett: What we're doing today, what we're resolving on, is compatible with what they're doing.
# [18:29] <TabAtkins_> Bert: I just want to make sure that nobody ever considers that in the future, if we introduce an ident that has uicode chars, it's still done ASCII CI.
# [18:29] * Joins: dino (~dino@public.cloak)
# [18:30] <fantasai> Proposed resolution: CSS-defined identifiers will always be ASCII-only
# [18:31] <dbaron> "Proposed resolution: The current intent of the working group is that future CSS identifiers will be ASCII-only" ?
# [18:31] * tantek aggress with both fantasai and dbaron
# [18:31] <dbaron> I'm fine with dropping the issue too, but I'd rather either resolve or not resolve, and move on.
# [18:32] <TabAtkins_> glazou: We shouldn't make resolutions against future things.
# [18:32] <tantek> strawpoll?
# [18:33] <Bert> (There are two intentions that merit being recorded: properties are case-insensitive and properties are expected to be ASCII-only.)
# [18:35] * Quits: plinss_ (~plinss_@public.cloak) (Ping timeout: 60 seconds)
# [18:37] * Joins: plinss_ (~plinss_@public.cloak)
# [18:41] * Quits: arronei (~arronei@public.cloak) ("")
# [18:45] * Quits: smfr (~smfr@public.cloak) (Ping timeout: 60 seconds)
# [18:49] * Joins: arronei (~arronei@public.cloak)
# [18:56] <fantasai> ScribeNick: fantasai
# [18:56] <fantasai> Topic: css3-syntax
# [18:56] <glazou> http://lists.w3.org/Archives/Public/www-style/2013Feb/0040.html
# [18:56] <SimonSapin> http://lists.w3.org/Archives/Public/www-style/2013Feb/0040.html
# [18:56] <fantasai> TabAtkins: Simon raised an objection to this on the mailing list
# [18:56] <fantasai> TabAtkins: Syntax spec has slighly different handling of syntax errors depending on where they occur
# [18:57] <SimonSapin> @media ], all {…}
# [18:57] <fantasai> TabAtkins: This type of syntax error, where there is an unmatched square bracket...
# [18:57] <fantasai> TabAtkins: The way I have it written already, syntax throws out the block entirely immediately
# [18:57] <fantasai> TabAtkins: Other types of syntax errors continue, and then @media (e.g.) would do its own error-handling
# [18:58] <fantasai> TabAtkins: In this case, the entire rule would be dropped because syntax catches it as a generic syntax error
# [18:58] <fantasai> TabAtkins: A different type of error, e.g @media foo, all { ... }
# [18:58] <fantasai> TabAtkins: Syntax considers it valid, and @media will drop that part of the media query
# [18:59] <fantasai> dbaron: Why are there two layers of processing?
# [18:59] <fantasai> TabAtkins: Not necessary, but seemed to make sense to me
# [18:59] <fantasai> TabAtkins: Just seemed like a good idea
# [18:59] <fantasai> fantasai: In CSS2.1, we consider something like this to just be an invalid token in the context it appears.
# [19:00] <fantasai> dbaron: Agree with fantasai. Would rather not do the multi-level thing.
# [19:00] <fantasai> TabAtkins: Wanted to do that because a } in a top-level rule would show up that way
# [19:00] <fantasai> TabAtkins: Whereas in a nested rule would close the outer rule. It has different behavior there
# [19:01] <fantasai> fantasai: That's the way it works currently, no? Shouldn't it just continue to do that then.
# [19:01] <fantasai> dbaron: Even with this change, the behavior is still dramatically different
# [19:01] <fantasai> dbaron: you start up in different places
# [19:01] <fantasai> TabAtkins: The consistency is that you drop the entire rule both times
# [19:02] <fantasai> dbaron: Don't think it's worth adding an extra layer of invalidation for this.
# [19:02] <dbaron> s/invalidation/validation/
# [19:02] <fantasai> Glenn: Given history of flex etc...
# [19:02] <fantasai> Glenn: WebKit still uses Bison for parsing
# [19:02] <fantasai> Glenn: Want to make sure that whatever behavior we prescribe can be represented in Bison
# [19:03] <fantasai> TabAtkins: Several things I'm trying to resolve in this area didn't match CSS2.1 grammar
# [19:03] <fantasai> SimonSapin: Another option, instead of having various kinds of invalid tokens, just have one
# [19:03] * Joins: smfr (~smfr@public.cloak)
# [19:04] <fantasai> Discussion of handling closing brackets at parsing vs. scanner
# [19:04] <fantasai> TabAtkins: Simon is suggesting we spit out "invalid token" token
# [19:04] <fantasai> dbaron: You're proposing an intermediate stage?
# [19:04] <fantasai> SimonSapin [ explains this ]
# [19:05] <fantasai> SimonSapin: Component values are similar to tokens.
# [19:05] <fantasai> dbaron: I'll need to read it again to remember what's going on.
# [19:05] <TabAtkins_> component values are tokens, except functions and blocks are put together.
# [19:06] <fantasai> RESOLVED: Closing brackets in the wrong places are just invalid tokens in the context they're in; they don't get special handling.
# [19:08] <fantasai> Bert: In general, when you're parsing, assuming a top-down LTR parser, you encounter a symbol you don't expect, e.g. closing square bracket, you can do 2 things
# [19:08] <fantasai> Bert: You have to get back to continue parsing
# [19:08] <fantasai> Bert: You can start inserting symbols until your invalid token is valid, e.g. inserting curly brace, opening square bracket, then closing square bracket becomes valid. Then throw it away b/c not valid
# [19:09] <fantasai> Bert: Alternatively you start throwing things away until you find something that is valid.
# [19:09] <fantasai> Bert: Which of those two methods you use are kindof hard to define because depends on which parser you're using.
# [19:09] <fantasai> Bert: if you're using Bison-gnerated parsing, it has a built-in way of deciding between throwing away vs. inserting
# [19:10] <fantasai> Bert: So, do you want to specify all that in detail, which makes it hard to use certain kinds of parsers?
# [19:10] <fantasai> TabAtkins: I would like to specify in sufficient detail that the author-visible behavior is defined.
# [19:10] <fantasai> TabAtkins: Other than that, can do anything. Just have to produce the same output.
# [19:10] <fantasai> Bert: I'm afraid we're specifying too much, so lockingout certain implementations.
# [19:10] * Quits: teoli (~teoli@public.cloak) (Client closed connection)
# [19:11] <fantasai> TabAtkins: I'm much more concerned with making sure authors have consistent behavior
# [19:11] <fantasai> Bert: Somewhat concerned that we don't report CSS errors to the author
# [19:11] * Joins: liam (liam@public.cloak)
# [19:11] <fantasai> TabAtkins: Reported to the console
# [19:11] <fantasai> Bert: If you're treating parens different from other invalid tokens, that makes me uncomfortable.
# [19:11] <fantasai> TabAtkins: Just resolved not to
# [19:12] <fantasai> TabAtkins: One more questions. What do I need to do to make people sufficiently happy that we can publish WD and start referencing this draft elsewhere?
# [19:12] <fantasai> dbaron: I would like a chance to review it in sufficient detail when it's not changing constantly
# [19:12] <fantasai> TabAtkins: I approach asymptotic stability.
# [19:13] <fantasai> fantasai: I think once SimonSapin has verified that it matches his understanding of CSS2.1 and Kozea's implementation, then it's probably stable enough for dbaron to review
# [19:14] <fantasai> fantasai: At which point it will probably become less stable again :)
# [19:14] <dbaron> Bert: but there's no grammar!
# [19:14] <fantasai> SimonSapin: I think the only remaining issues are in the an+b notation
# [19:15] <fantasai> TabAtkins: CSS2.1's grammar was incomplete. It didn't specify handling of every byte stream.
# [19:15] <fantasai> TabAtkins: We can provide any possible byte stream as a style sheet: should get consistent results out of implementations.
# [19:15] <fantasai> Bert^: Grammar is much easier to see what the language looks like.
# [19:16] <fantasai> SimonSapin: Want to avoid having a grammar-based parser, and then an additional thing that does correct error-recovery.
# [19:16] <fantasai> fantasai: I think it's a valid concern to want a grammar that shows what the valid syntax look like, just to help people grok the language.
# [19:17] <fantasai> SimonSapin^: We should define error recovery.
# [19:17] <TabAtkins_> For grokkability, I have token diagrams: http://dev.w3.org/csswg/css3-syntax/#token-diagrams
# [19:17] <fantasai> s/SimonSapin: Want to avoid having a grammar-based parser, and then an additional thing that does correct error-recovery.
# [19:17] <fantasai> / /
# [19:18] <fantasai> TabAtkins: The tree structure is described as well.
# [19:18] <fantasai> TabAtkins: CSS tree is quite trivial. Think spec handles grokkability from author's perspective.
# [19:19] * Quits: rhauck (~Adium@public.cloak) ("Leaving.")
# [19:19] <fantasai> TabAtkins: I can provide railroad diagrams for parser constructions
# [19:19] <fantasai> Bert: It's nice, but not copy-pasteable.
# [19:20] <fantasai> TabAtkins: Grammar in CSS2.1 doesn't handle error-handling. Making it do so would make it unreadable.
# [19:21] <fantasai> fantasai: Totally agree that having a grammar that tries to handle error-recovery would be unusuable.
# [19:21] <fantasai> fantasai: Might be nice to have a grammar that defines only what is valid, informatively.
# [19:22] <fantasai> Bert: If someone is writing a module, and adding syntax e.g. media queries
# [19:22] <fantasai> TabAtkins: Plan is to switch those from using token-based grammar to use the property grammar syntax
# [19:22] <fantasai> TabAtkins: This lets you omit spacing details, etc. and has greater expressivity.
# [19:22] <fantasai> TabAtkins: Going to define grammar productions here to make that easier.
# [19:22] <glenn> expressivity?
# [19:22] <fantasai> TabAtkins: Would show e.g. how to do @supports rule using property grammar
# [19:23] <fantasai> TabAtkins: This way don't have to worry about getting spacing issues correct: all taken care of by property grammar.
# [19:23] * Joins: rhauck (~Adium@public.cloak)
# [19:25] <dbaron> fantasai: For @supports, we require spaces around the 'and' and 'or'; we might not have noticed that issue if we were writing it at a property grammar issue.
# [19:26] <fantasai> s/issue/level/
# [19:26] <fantasai> [ some meta conversation ]
# [19:26] <fantasai> TabAtkins: My plan is to move towards using the property grammar.
# [19:26] * Quits: tantek (~tantek@public.cloak) (Ping timeout: 60 seconds)
# [19:27] <fantasai> TabAtkins: This means that some details of those valid grammars would change.
# [19:27] <fantasai> dbaron: Or we can find a way to represent that.
# [19:27] <dbaron> SimonSapin: Just have a way to write in the property grammar for @supports that whitespace is required at a certain point.
# [19:27] <dbaron> TabAtkins: ok, that works
# [19:28] <fantasai> TabAtkins: Ok, so syntax is blocked waiting for dbaron's review, and I need to figure out upgrading grammars
# [19:28] <fantasai> Bert is still parsing Tab's sentence
# [19:28] * Ms2ger Sounds like someone needs to write a parser for Tab's sentences...
# [19:29] <fantasai> smfr: Your railroad diagrams have abbreviations that are not described in the spec
# [19:31] <fantasai> [discussion of what to discuss next; a lot of topics are required on later days for various reasons]
# [19:31] <Ms2ger> CSS 2.1 issues?
# [19:31] * fantasai thinks we should discuss publishing a CSS2.1 editor's draft, personally
# [19:31] <fantasai> [contemplating some animations issues]
# [19:32] <fantasai> dbaron: Part of the problem is that nobody understands what WebKit does.
# [19:32] * Ms2ger thinks you guys should just publish it...
# [19:32] <fantasai> smfr: Webkit just does animations last
# [19:32] <fantasai> dbaron: But we resolved we wanted other htings last
# [19:32] <fantasai> dbaron: Worth scheduling this as a separate item.
# [19:33] <fantasai> dbaron: Have a bunch of transitions things we could go through before lunch
# [19:33] <fantasai> [scheduling]
# [19:34] <dbaron> http://lists.w3.org/Archives/Public/www-style/2013Feb/0124.html
# [19:35] <fantasai> Topic: Transitions
# [19:35] <fantasai> dbaron: Email I just pasted is list of the 9 issues currently listed in spec and what I think we should do with them.
# [19:35] <fantasai> dbaron: For issue one, keypath syntax, propose to defer
# [19:35] <fantasai> RESOLVED: Defer keypath syntax to next level of Transitions
# [19:36] <fantasai> dbaron: Next is proposal wrt transition shorthand, using a slash to separate duration and delay
# [19:36] <fantasai> dbaron: Might have been nice, but seems too late for that
# [19:36] <fantasai> plinss: What would the slash buy you?
# [19:36] * Joins: jarek (~jarek@public.cloak)
# [19:37] <fantasai> fantasai: I think we only use slash where it's needed for disambiguation
# [19:37] <fantasai> fantasai: Seems like both it's not needed, and too late. So answer is no.
# [19:38] <fantasai> plinss: Is serialization order specified to be the less confusing one?
# [19:38] <fantasai> Serialization is not specified.
# [19:38] <fantasai> RESOLVED: No slash in transition shorthand
# [19:38] <fantasai> dbaron: Issue 3 is waiting for Tab to write a JS simulation.
# [19:38] <fantasai> dbaron: Issue 4 is wrt new events having init*Event methods.
# [19:38] <fantasai> dbaron: I think we resolved this for Animations, propose to copy whatever we resolved there.
# [19:39] <fantasai> TabAtkins: Define a constructor instead. Just copy-paste Animations.
# [19:39] <fantasai> RESOLVED: Do whatever we did for Animations for Transitions wrt init*Event methods.
# [19:39] <fantasai> dbaron: This causes issue 5 to magically disappear.
# [19:39] <fantasai> dbaron: Fun next set of issues is 6 & 7
# [19:39] <fantasai> dbaron: Thought we had resolved these, but couldn't find any record of it.
# [19:39] <fantasai> dbaron: roundign vs. flooring of integer animations.
# [19:40] <fantasai> dbaron: We had a discussion in March, where we created the issues. Thought we discussed at TPAC, but couldn't find in minutes
# [19:40] <fantasai> [various thought we resolved on rounding]
# [19:40] <fantasai> TabAtkins: Required to match up with non-animatable properties, which flip over halfway , no?
# [19:41] * Joins: teoli (~teoli@public.cloak)
# [19:41] <fantasai> dbaron: let's come back to this
# [19:41] <fantasai> dbaron: Issues wrt long list of properties.
# [19:42] <fantasai> dbaron: I propose making these list to be properties in CSS2.0, plus opacity
# [19:42] <fantasai> dbaron: maybe not marker-offset
# [19:42] <fantasai> dbaron: And push everything else to the various modules
# [19:42] <fantasai> dbaron: This will require edits to multi-col and UI
# [19:42] <fantasai> dbaron: css3-background already has this info
# [19:42] <fantasai> dbaron: And require edits to Fonts
# [19:42] <fantasai> jdaggett: Just tell me what you think needs to happen
# [19:44] <fantasai> [discussion of process/publication]
# [19:44] <fantasai> RESOLVED: Do that.
# [19:45] <fantasai> dbaron: Other issue I think we can resolve straightforwardly is proposal I sent to list for transitions with multiple backgrounds
# [19:45] <dbaron> http://lists.w3.org/Archives/Public/www-style/2013Feb/0129.html
# [19:46] <fantasai> dbaron: If the list lengths mismatch for the various background properties, we use the length from background-image.
# [19:46] <fantasai> dbaron: And we either truncate or repeat the values in other lists
# [19:47] <fantasai> dbaron: There were authors who were upset when lists of different lengths for no-image properties prevented an animation
# [19:47] * Quits: liam (liam@public.cloak) (Ping timeout: 60 seconds)
# [19:47] <fantasai> dbaron: Right now have definition of animating lists, where lists must match in length.
# [19:47] <fantasai> dbaron: Propose adding a second concept of repeateable list, which is a list that can be repeated arbitrarily without change in semantics
# [19:48] <fantasai> dbaron: useful in some cases, like background properties, and stroke-array
# [19:48] <fantasai> dbaron: The interpolated value is the least common multiple of the other two list lengths.
# [19:48] <fantasai> dbaron: This is how you smoothly interpolate between them.
# [19:49] * Quits: teoli (~teoli@public.cloak) (Ping timeout: 60 seconds)
# [19:49] <fantasai> dbaron: Animating background-origin, don't know how many images you have. No matter how many images you have, this rule always works.
# [19:49] * fantasai thinks this makes sense
# [19:50] <fantasai> dbaron: Truncation of these lists happen after computed value.
# [19:50] <fantasai> [dbaron explains why you need least common multiple, rather than max]
# [19:50] <fantasai> [deriving this is left as an exercise to the reader]
# [19:51] <fantasai> glazou: This is to avoid figuring out how many images you have?
# [19:51] <fantasai> dbaron: Some weird cases, e.g. if you inherit to ca hcild
# [19:51] <fantasai> glazou: So if you have 2 bg images, but 3-4 origins. It's truncated, but in the style sheet
# [19:52] * sylvaing hopes authors don't need to figure out least common multiples to understand how something works...
# [19:52] <fantasai> glazou: It's worth the extra work?
# [19:52] <fantasai> dbaron: Yes, and relatively general rule that works for a whole bunch of things
# [19:52] <fantasai> TabAtkins: There are cases where you have a repeatable list where there is not a master list
# [19:53] <fantasai> [...]
# [19:53] <fantasai> TabAtkins: If you're inheriting the value, you can't do an early truncation.
# [19:53] * fantasai thinks we should have gone with pre-filling the bg properties rather than repeating, but wasn't able to convince Tantek that this is more useful. :)
# [19:54] * fantasai glad at least we have bg-image as a master list, rather than repeating that, too...
# [19:55] <fantasai> dbaron: The normal cases here are going to be lists of the same length, or a single value animating to a list.
# [19:55] <fantasai> dbaron: The 2 vs. 3 case is going to be very unusual
# [19:55] <fantasai> dbaron: So in almost all cases, wouldn't increase size of list.
# [19:56] <fantasai> [dbaron gives an example of interpolating two lists and why this behavior is needed]
# [19:57] <TabAtkins_> @keyframes foo { from { background-position: 0px, 2px; } to { background-position: 10px, 20px, 30px; } }
# [19:57] * Joins: cabanier (~cabanier@public.cloak)
# [19:57] <TabAtkins_> ^^^ computed value of background-position during the animation is a six-element list, animating between "0px, 2px, 0px, 2px, 0px, 2px" and "10px, 20px, 30px, 10px, 20px, 30px"
# [19:57] <fantasai> RESOLVED: Do what dbaron says.
# [19:57] <dbaron> http://lists.w3.org/Archives/Public/www-style/2013Feb/0129.html
# [19:58] <fantasai> smfr: Would be nice if spec gave justification for why it is this way, e.g. showing inherit case.
# [19:58] <fantasai> dbaron: Should we try to go back to floor vs. round stuff?
# [19:59] <fantasai> dbaron: We all think we resolved it before. What do we all think we resolved it to?
# [19:59] <fantasai> Bert, Tab: switched from floor to round
# [20:02] <fantasai> http://lists.w3.org/Archives/Public/www-style/2012Mar/0655.html
# [20:02] <fantasai> RESOLVED: Round rather than floor for interpolating integers
# [20:03] <fantasai> dbaron: That leaves cascading (action on Dean) and reversing (action on Tab)
# [20:03] <fantasai> dbaron: Other things are deferring to other specs
# [20:03] <dbaron> dbaron: Though there are a few more issues I need to go through
# [20:04] <dino> I never did my action on cascading. But Simon could talk to it now if he wanted to.
# [20:05] <fantasai> Nope, you don't get off the hook! We're switching topics so you have time to do it :D
# [20:05] <fantasai> Topic: F2F scheduling
# [20:05] <dbaron> dbaron: discuss TPAC first
# [20:05] <dbaron> TPAC in mid/late November in Shenzhen, China
# [20:05] <fantasai> Discussion of problems with Shenzhen
# [20:05] <fantasai> Concerns about price, visa, hacking, etc.
# [20:06] * Quits: dino (~dino@public.cloak) (Client closed connection)
# [20:06] <fantasai> attendance
# [20:07] <fantasai> szilles: AB queried group chairs wrt attendance, and seemed like attendance wouldn't suffer
# [20:07] <fantasai> network connectivity
# [20:07] <fantasai> jdaggett: Behind Great Firewall. Randomly things won't work.
# [20:08] <fantasai> Rossen: Is there an alternative?
# [20:08] <fantasai> dbaron: Other option is to not meet at TPAC, schedule a normal other meeting
# [20:09] <fantasai> plinss: I'm personally going there whether or not we do
# [20:09] <fantasai> glazou: If we go to TPAC, that's 2 meetings in Asia this year.
# [20:11] <fantasai> jdaggett: Are there people who would attend / not attend depending on location?
# [20:11] <fantasai> Bert: Not sure I can travel twice.
# [20:11] <fantasai> plinss: Anyone who *will not* go to TPAC due to location?
# [20:11] <fantasai> tantek: me
# [20:11] <fantasai> tantek: on principle
# [20:11] <dbaron> glazou: not sure yet
# [20:11] <fantasai> tantek: nyt hacking stuff unacceptable
# [20:11] * Joins: dino (~dino@public.cloak)
# [20:12] <dbaron> Chinese visa prices are http://www.china-embassy.org/eng/hzqz/zgqz/t84247.htm
# [20:13] <fantasai> fantasai: Could meet in Hong Kong, then people going to TPAC could get a single flight
# [20:14] <fantasai> Bert: 1.5hrs between them
# [20:14] <fantasai> Option A: Go to TPAC
# [20:14] <fantasai> Option B: Meet in Hong Kong right before TPAC
# [20:15] * Joins: teoli (~teoli@public.cloak)
# [20:18] * Joins: cabanier1 (~cabanier@public.cloak)
# [20:20] <fantasai> RESOLVED: Meet at TPAC, possibly TPAC-adjacent.
# [20:20] <fantasai> Discussing summer meeting
# [20:21] * Quits: cabanier (~cabanier@public.cloak) (Ping timeout: 60 seconds)
# [20:21] <dbaron> discussion of September 9-10-11
# [20:21] <dbaron> (or later???)
# [20:22] <fantasai> possibly at the Mozilla Paris office
# [20:23] <fantasai> possibly at Sophia-Antipolis
# [20:24] <fantasai> TabAtkins: Google might be able to host in Paris, Zurich, Brussels
# [20:24] <fantasai> September 2013
# [20:24] <fantasai> Su Mo Tu We Th Fr Sa
# [20:24] <fantasai> 1 2 3 4 5 6 7
# [20:24] <fantasai> 8 9 10 11 12 13 14
# [20:24] <fantasai> 15 16 17 18 19 20 21
# [20:24] <fantasai> 22 23 24 25 26 27 28
# [20:24] <fantasai> 29 30
# [20:24] * Quits: franremy (~franremy@public.cloak) (Ping timeout: 60 seconds)
# [20:24] * Quits: teoli (~teoli@public.cloak) (Ping timeout: 60 seconds)
# [20:25] <fantasai> RESOLVED: Summer meeting in Europe week of 9th September
# [20:26] <fantasai> Tentatively schedule for Mozilla in Paris, other options on the table
# [20:26] <fantasai> <br type="lunch>
# [20:26] * fantasai oops
# [20:26] <fantasai> s/"//
# [20:28] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [20:30] * Quits: plinss_ (~plinss_@public.cloak) (Ping timeout: 60 seconds)
# [20:32] * Quits: Rossen (~Rossen@public.cloak) (Ping timeout: 60 seconds)
# [20:35] * Quits: jarek (~jarek@public.cloak) (jarek)
# [20:38] * Joins: rhauck1 (~Adium@public.cloak)
# [20:41] * Quits: rhauck (~Adium@public.cloak) (Ping timeout: 60 seconds)
# [20:42] * Quits: rhauck1 (~Adium@public.cloak) (Ping timeout: 60 seconds)
# [20:47] * Quits: jdaggett (~jdaggett@public.cloak) (Ping timeout: 60 seconds)
# [20:49] * Joins: tantek (~tantek@public.cloak)
# [20:50] * Joins: liam (liam@public.cloak)
# [20:51] * Joins: franremy (~franremy@public.cloak)
# [20:51] * Joins: teoli (~teoli@public.cloak)
# [21:01] * Quits: teoli (~teoli@public.cloak) (Ping timeout: 60 seconds)
# [21:01] * Quits: cabanier1 (~cabanier@public.cloak) (Client closed connection)
# [21:03] * Joins: cabanier (~cabanier@public.cloak)
# [21:11] * Quits: smfr (~smfr@public.cloak) (Ping timeout: 60 seconds)
# [21:21] * Joins: jdaggett (~jdaggett@public.cloak)
# [21:28] * Joins: teoli (~teoli@public.cloak)
# [21:34] * Quits: isherman-book (~Adium@public.cloak) ("Leaving.")
# [21:38] * Quits: teoli (~teoli@public.cloak) (Ping timeout: 60 seconds)
# [21:44] * Quits: tantek (~tantek@public.cloak) (tantek)
# [21:48] * Quits: liam (liam@public.cloak) ("train")
# [21:53] * sylvaing is now known as sylvaing_away
# [21:55] * Quits: molly (~molly@public.cloak) (Ping timeout: 60 seconds)
# [21:55] <dbaron> ScribeNick: dbaron
# [21:55] <dbaron> Topic: text decoration
# [21:55] <dbaron> fantasai: I wanted to review status of various issues.
# [21:56] <fantasai> http://dev.w3.org/csswg/css-text-decor-3/issues-lc-2012
# [21:56] * Quits: leaverou (~leaverou@public.cloak) (Client closed connection)
# [21:56] * Quits: sylvaing_away (~sylvaing@public.cloak) (Client closed connection)
# [21:56] * Quits: shans (~shans@public.cloak) (Client closed connection)
# [21:56] * Quits: alexmog (~alexmog@public.cloak) (Client closed connection)
# [21:56] * Quits: csswg (~csswg@public.cloak) (Client closed connection)
# [21:56] * Quits: plinss (~plinss@public.cloak) (Client closed connection)
# [21:56] <dbaron> fantasai: we have 5 issues, the first is the trickiest
# [21:56] <dbaron> fantasai: ... and needs the WG's input
# [21:56] <fantasai> http://lists.w3.org/Archives/Public/www-style/2013Jan/0282.html
# [21:56] <dbaron> fantasai: Sebastian Zardner requested we remove text-underline-position and add an @-rule to generically create random text decorations using a variety of descriptors
# [21:57] * Joins: smfr (~smfr@public.cloak)
# [21:57] <fantasai> http://lists.w3.org/Archives/Public/www-style/2012Sep/0462.html
# [21:57] <dbaron> fantasai: this message includes some examples of what he was thinking
# [21:57] <dbaron> fantasai: Koji and I propose to request this request
# [21:57] <dbaron> glazou: for the time being or in general?
# [21:57] * Joins: antonp (~Thunderbird@public.cloak)
# [21:57] <dbaron> fantasai: in general; we think the text decoration features should be restricted to lines
# [21:57] <dbaron> fantasai: and this feature is needed for international text
# [21:58] <dbaron> fantasai: if we want to do something like this it should be a different feature
# [21:58] <dbaron> fantasai: text-underline-position is for handling something very specific; it should stay that way
# [21:58] * Joins: alexmog_away (~alexmog@public.cloak)
# [21:58] <dbaron> glazou: What about his complaint that it applies only to underline?
# [21:58] * alexmog_away is now known as alexmog
# [21:58] <dbaron> fantasai: It can in some cases affect the overline
# [21:59] <dbaron> fantasai: can distinguish alphabetic vs. below; can also distinguish between underline on left vs right in vertical text (which swaps the overline to the other side)
# [21:59] <dbaron> glenn: this proposal essentially asks for a way to group style properties and refererentially refer to them by name in other areas
# [21:59] <dbaron> fantasai: just about decorating text
# [21:59] * Joins: leaverou_away (~leaverou@public.cloak)
# [21:59] <dbaron> glenn: does it generalize to a way to group style properties?
# [21:59] * leaverou_away is now known as leaverou
# [21:59] <dbaron> fantasai: no
# [21:59] * Joins: plinss_away (~plinss@public.cloak)
# [22:00] <dbaron> [discussion between fantasai and glenn about whether this is macro-ing]
# [22:00] * plinss_away is now known as plinss
# [22:00] * Joins: shans_away (~shans@public.cloak)
# [22:00] <dbaron> fantasai: I don't think text-underline-position either prevents us from going in this direction or should be dropped.
# [22:00] * shans_away is now known as shans
# [22:01] * Joins: sylvaing_away (~sylvaing@public.cloak)
# [22:01] <dbaron> glenn: If this is something new, I don't think we should spec it out unless somebody's commited to implementing. Also seems like @-rules have a lot more overhead than properties.
# [22:01] * sylvaing_away is now known as sylvaing
# [22:01] <dbaron> SimonSapin: Can we see this as a way for images above the text and ??? images?
# [22:01] <dbaron> fantasai: There was some discussion on the list... proposal to duplicate background properties.
# [22:01] <dbaron> fantasai: text-decoration is about text and associated with where text is drawn
# [22:02] <dbaron> fantasai: foreground images would be referencing the box
# [22:02] <dbaron> smfr: what are the use cases for foreground images?
# [22:02] <dbaron> fantasai: a "new" banner across image, sparkles
# [22:02] <dbaron> TabAtkins: "ACTUAL SIZE"
# [22:02] <dbaron> fantasai: It's easy to spec.
# [22:03] <dbaron> smfr: painting order is tricky
# [22:03] <dbaron> fantasai: The proposal is to reject this comment and not drop text-underline-position.
# [22:03] <SimonSapin> s/??? images/generate procedural images/
# [22:03] <fantasai> dbaron: I have questions about some of the values of text-underline-position, but that's a separate thing.
# [22:03] <dbaron> dbaron: I have comments about some of the values of text-underline-position, but taht's separate.
# [22:04] <SimonSapin> maybe that’s just SVG
# [22:04] <dbaron> smfr: did we resolve we don't want to do the @-rule right now?
# [22:04] <dbaron> TabAtkins: I think @pattern should be something SVG invents and we *possibly* import; we shouldn't try to innovate with that in CSS first.
# [22:05] <dbaron> RESOLVED: don't drop text-underline-position
# [22:05] <dbaron> RESOLVED: not (currently at least) doing the @pattern proposal
# [22:06] <dbaron> fantasai: for reference there are 4 other issues on text-decoration
# [22:06] <dbaron> fantasai: LC period closed last week
# [22:06] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [22:06] <dbaron> fantasai: several of those are about combination of emphasis marks and ruby
# [22:06] <dbaron> fantasai: 2 are about text-decoration-skip
# [22:06] * Joins: csswg (~csswg@public.cloak)
# [22:07] <dbaron> fantasai: We'll bring those to i18n for the correct answers, then we'll bring back to this WG for comments.
# [22:07] <dbaron> fantasai: If anybody else has issues, please raise them this week.
# [22:07] <dbaron> SteveZ: implementation status?
# [22:07] <dbaron> fantasai: Mozilla has quite a few ; AntennaHouse probably nearly everything
# [22:07] <dbaron> Koji: WebKit has a good amount in progress
# [22:08] * Quits: Ms2ger (~Ms2ger@public.cloak) ("nn")
# [22:08] <dbaron> fantasai: That's it on text-decoration.
# [22:08] <dbaron> Topic: multicol
# [22:09] <dbaron> Bert: I'm trying to find the current status. Do we have any ideas when it might go to PR?
# [22:09] <dbaron> Bert: Are there ways to speed it up?
# [22:09] <dbaron> fantasai: The testing situation -- not enough tests to cover the spec.
# [22:09] <dbaron> fantasai: Also a handful of open issues, most notably one SimonSapin raised that we didn't resolve at last f2f.
# [22:09] <dbaron> fantasai: We need to get all the issues handled and publish a new CR, and get more tests.
# [22:10] <dbaron> fantasai: So I think there's a lot of work left to do.
# [22:10] <dbaron> Bert: And implementations?
# [22:10] <dbaron> fantasai: Mozilla's working on areas where we're not compliant; haven't unprefixed yet.
# [22:10] <dbaron> fantasai: Not a super-high priority; hopefully able to be unprefixed by end of year.
# [22:10] * Quits: lmclister (~lmclister@public.cloak) ("")
# [22:10] <dbaron> Bert: Does Mozilla have break-*?
# [22:10] <dbaron> fantasai: no
# [22:11] <dbaron> fantasai: If that's what's holding things up, we'll have fragmentation in CR, and can drop from multicol.
# [22:11] <dbaron> [something there about WebKit too]
# [22:11] * Joins: lmclister (~lmclister@public.cloak)
# [22:11] <dbaron> Bert: Prince doesn't do column-span: all; I think others do.
# [22:11] <dbaron> Rossen: We do, I think.
# [22:11] <dbaron> fantasai: Can IE submit tests?
# [22:11] <dbaron> Rossen: I can ask Arron to look into it.
# [22:12] * Quits: lmclister (~lmclister@public.cloak) ("")
# [22:12] <dbaron> Rossen: Last time I remember talking to Håkon, he said they had tests ready to submit.
# [22:12] <dbaron> fantasai: Håkon submitted tests, but pretty much useless.
# [22:12] * Joins: tantek (~tantek@public.cloak)
# [22:12] <dbaron> Peter: shepherd reports 129 tests for multicol
# [22:12] <dbaron> Bert: are you seeing the gaps?
# [22:12] <dbaron> fantasai: A lot of things
# [22:13] <dbaron> Peter: have tests across most of chapters, but would need to drill down
# [22:13] <dbaron> Bert: so I hear not this year... that's a pity
# [22:13] <dbaron> fantasai: Primarily gated on test, and a couple of spec issues.
# [22:14] <dbaron> Rossen: One issue about multicol I wanted to discuss.
# [22:14] * Joins: plinss_ (~plinss@public.cloak)
# [22:14] * Joins: Rossen (~Rossen@public.cloak)
# [22:14] <Rossen> http://lists.w3.org/Archives/Public/www-style/2013Jan/0251.html
# [22:14] <dbaron> [discussion of IRC bouncer]
# [22:15] <dbaron> Rossen: So there was an issue with column-rule rendering drawing order; didn't get much traction on the list (link above).
# [22:15] <dbaron> Rossen: So the current spec defines column rules to be rendered just above the background.
# [22:15] <dbaron> [reads spec text]
# [22:16] <dbaron> Rossen: I think it's a fairly reasonable behavior expectation that when you have scrollbars, the column rules should scroll along with the columns.
# [22:16] * Quits: glazou (~glazou@public.cloak) (Ping timeout: 60 seconds)
# [22:17] <dbaron> Rossen: The testcase in that link is an example of taking a fairly simple case... and I looked through all implementations supporting multicol at the moment... and most implementatios don't actually scroll the column rules because they treat them as part of the backgorund.
# [22:17] <dbaron> Rossen: If you also combine that with a case of z-index elements, some of the implementations appear to start working, but then don't... it's fairly messy.
# [22:17] <dbaron> Rossen: I think the current specification is fairly weak in its requiremen.
# [22:18] <dbaron> Rossen: For us, to implement something that would achieve scrolling with the content as well as being at the level of background (under z-index), that means we need a new layer
# [22:18] <dbaron> Rossen: It's going to be a hassle to make that work, for I'm not sure how much benefit.
# [22:18] <dbaron> Rossen: column rules are more of a design-time requirement (visual aid)
# [22:19] <dbaron> fantasai: I agree column rules should scroll with the columns; should stay between the columns.
# [22:19] <dbaron> fantasai: With regards to what level; I think it should be below the content (with no z-index); interesting question as to whether above or below borders; above borders might make more sense.
# [22:20] <dbaron> [smfr shows Rossen a JSFiddle]
# [22:20] <dbaron> fantasai: If that elements forms a stacking context, at which level does it paint?
# [22:20] <dbaron> fantasai: I'd say immediately before the text and text decorations (anonymous text), or immediately above the background. As long as it's below the text.
# [22:21] <dbaron> fantasai: I don't care about above or below negative z-index stuff.
# [22:21] <dbaron> smfr: I'd like to avoid a separate layer just for column rules.
# [22:21] <dbaron> Rossen: So just lift them up to the content layer... first in the content layer.
# [22:22] <dbaron> fantasai: so below anything with a z-index of 0 or auto
# [22:22] <fantasai> smfr: Paint all the rules, then the content of the columns
# [22:22] <fantasai> dbaron: Does multi-col form a pseudo-stacking context?
# [22:22] <fantasai> fantasai: Don't know that we thought that far..
# [22:23] <fantasai> dbaron: If multi-col doesn't establish a pseudo-stacking context, then floats from outside the multi-col propagate through the multi-col
# [22:23] <smfr> http://lists.w3.org/Archives/Public/www-style/2012Jul/0546.html
# [22:24] <fantasai> fantasai: guessing we want before Group A
# [22:24] <fantasai> dbaron: If a multi-col doesn't even establish an A-Group (pseudo-stacking context)
# [22:25] <fantasai> dbaron: then only way to put it before group A is to give it its own layer
# [22:25] <fantasai> dbaron: but probably it should establish a pseudo-stacking context
# [22:27] <fantasai> [investigation into what forms a pseudo-stacking context]
# [22:27] <dbaron> dbaron: I argued at one point that anything establishing a BFC should create a pseudo-stacking context, but I think I lost.
# [22:27] <dbaron> dbaron: Was that about tables or about flexbox?
# [22:27] * Quits: darktears_ (~darktears@public.cloak) (Ping timeout: 60 seconds)
# [22:28] <fantasai> tables don't form stacking contexts, for historical reasons
# [22:28] <fantasai> flexboxen don't either, see http://dev.w3.org/csswg/css3-flexbox/issues-lc-2012#issue-5
# [22:28] <fantasai> so multi-col shouldn't either
# [22:28] <dbaron> RESOLVED: column rules are painted in the inline content layer (as described in http://lists.w3.org/Archives/Public/www-style/2012Jul/0546.html), but below all inline content inside the multicol
# [22:28] <fantasai> so we're painting right below inline layer, in the middle of Group A
# [22:30] <dbaron> ACTION Rossen to ask Håkon to edit this resolution for column rule painting order
# [22:30] * trackbot is creating a new ACTION.
# [22:30] <trackbot> Created ACTION-530 - Ask Håkon to edit this resolution for column rule painting order [on Rossen Atanassov - due 2013-02-11].
# [22:30] * Quits: cabanier (~cabanier@public.cloak) ("Leaving.")
# [22:30] <dbaron> Peter: Should we consider adding Rossen as a co-editor of css3-multicol?
# [22:31] <dbaron> Peter: Anything we can do moving forward testing-wise?
# [22:31] <dbaron> fantasai: Gerard working on some of mozilla's tests
# [22:31] * Quits: glenn (~glenn@public.cloak) ("Page closed")
# [22:31] <dbaron> fantasai: for multicol specifically, and backgrounds and borders
# [22:31] <dbaron> Peter: Anything else on multicol?
# [22:31] <dbaron> fantasai: SimonSapin's issue
# [22:31] <dbaron> Bert: I want to talk to Simon before tonight.
# [22:32] <dbaron> Topic: Backgrounds and borders
# [22:32] <dbaron> Peter: where are we, and what do we need to do to move forward?
# [22:32] <dbaron> dbaron: Also need more tests?
# [22:33] <dbaron> fantasai: A handful of open issues.
# [22:33] <dbaron> fantasai: One is on clarifying how spread works
# [22:33] <dbaron> fantasai: I think mostly wording, but might be functionality once we figure out what's going on.
# [22:33] <fantasai> http://dev.w3.org/csswg/css3-background/#changes-2012
# [22:33] <dbaron> fantasai: There are changes since last CR that we resolved on.
# [22:33] <dbaron> fantasai: So we'll need to republish LC once last set of clarifications goes in
# [22:33] <dbaron> fantasai: I think that's maybe a day's work.
# [22:34] <dbaron> fantasai: I think we're waiting for edits.
# [22:34] <dbaron> fantasai: And yeah, we need more tests.
# [22:34] <dbaron> Peter: Will Mozilla tests give us good enough coverage.
# [22:34] <dbaron> dbaron: Probably not
# [22:34] <dbaron> fantasai: Should get test coverage report for June and see where things are missing.
# [22:35] <dbaron> fantasai: And get CR published for the June F2F.
# [22:35] <dbaron> fantasai: ... a good target.
# [22:36] <dbaron> fantasai: I think mainly a clarification about the spread radius. smfr, Bert and I will talk at one of the breaks.
# [22:36] <dbaron> Bert: So there will be some tests coming in the
# [22:36] <dbaron> Peter: ... the next month
# [22:36] <dbaron> Bert: ... but those still won't give complete coverage.
# [22:36] <dbaron> fantasai: That will probably get us to halfway on the test suite.
# [22:37] <dbaron> Peter: Do other vendors (IE, WebKit) have tests?
# [22:37] <dbaron> Rossen: [inaudible]
# [22:37] <dbaron> smfr: probably have some; don't know what state they're in. Some active implementation work on newer properties... maybe can get tests out of that.
# [22:37] <dbaron> fantasai: Can you get the tests in reftest format?
# [22:38] <dbaron> Bert: Apart from Opera, any implementations of background-repeat: spread | stretch ?
# [22:38] <dbaron> fantasai: there's a 'space' value
# [22:38] <dbaron> fantasai: If we want to be consistent with flexbox, it should be space-between
# [22:39] <dbaron> fantasai: Since flexbox led to 3 concepts of spacing (no space on ends, half-space on ends, full space on ends)
# [22:39] <dbaron> fantasai: so we had to come up with keywords to distinguish; ideally B&B would be consistent with that
# [22:39] <dbaron> Rossen: I don't think IE implements background-image: space
# [22:40] <dbaron> dbaron: I think Gecko implements border-image-repeat: space
# [22:40] <dbaron> fantasai: the option we should have put in spec for border-image is the one we didn't include in flexbox
# [22:41] <dbaron> fantasai (responding to dbaron): border-image-repeat: space is no space at ends, but should be full space at ends
# [22:41] <dbaron> Peter: do we want to change this?
# [22:41] <dbaron> fantasai: on the plus side, we don't need to rename anything, we can just add new values
# [22:42] <dbaron> Peter: If we're in CR, should we just drop and move to level 4?
# [22:42] <dbaron> dbaron: I'd be in favor of dropping
# [22:42] <dbaron> fantasai: I'd be in favor of dropping; then we can add all 3 spacing variants in level 4.
# [22:42] <dbaron> Peter: anything else to shift?
# [22:42] <dbaron> fantasai: Put box-decoration-break in fragmentation?
# [22:43] * Joins: florian (~florian@public.cloak)
# [22:43] <dbaron> dbaron: Level 4 could just be level 3 plus all the things we just took out of it.
# [22:44] <dbaron> fantasai: I don't think level 4 is that far away.
# [22:44] <dbaron> Peter: objections to removing?
# [22:44] <dbaron> dbaron: background-repeat or border-image-repeat?
# [22:45] <dbaron> dbaron: I think border-image-repeat: space probably interoperable
# [22:45] <dbaron> fantasai: I think if it's in border it should stay in background
# [22:45] <dbaron> dbaron: I don't see why.
# [22:45] <dbaron> smfr: I don't think WebKit has space for border-image-repeat
# [22:46] <dbaron> dbaron: Sorry, I was getting space and round mixed up
# [22:47] <dbaron> dbaron: So I'm ok with dropping space from both.
# [22:47] <dbaron> dbaron: We do stretch, repeat, and round for border-image-repeat.
# [22:47] * Quits: TabAtkins_ (~TabAtkins@public.cloak) (Ping timeout: 60 seconds)
# [22:48] <dbaron> RESOLVED: drop 'space' from background-repeat and border-image-repeat in level 3 of backgrounds and borders
# [22:49] <dbaron> fantasai: The next question is do we want to shift box-decoration-break to fragmentation?
# [22:49] <dbaron> Bert: already marked at-risk
# [22:49] * heycam|away is now known as heycam
# [22:49] <dbaron> RESOLVED: move box-decoration-break from css3-background to fragmentation
# [22:51] <dbaron> Topic: figuring out next topic
# [22:51] <dbaron> Peter: viewport units?
# [22:51] <dbaron> resolved last week
# [22:51] <dbaron> Peter: overflow?
# [22:51] <dbaron> dbaron: not ready
# [22:51] <dbaron> Peter: placeholder styling?
# [22:52] <fantasai> ScribeNick: fantasai
# [22:52] <dbaron> Topic: placeholder styling
# [22:54] * Disconnected
# [23:03] * Attempting to rejoin channel #css
# [23:03] * Rejoined channel #css
# [23:03] * Topic is 'http://lists.w3.org/Archives/Public/www-style/2013Jan/0557.html'
# [23:03] * Set by smfr on Wed Jan 30 18:08:51
# [23:03] <fantasai> smfr: So solution that uses pseudo-class to add fill-opacity doesn't seem quite right to me.
# [23:03] <fantasai> plinss: Are there arguments in favor of pseudo-class over just pseudo-element?
# [23:03] <fantasai> TabAtkins: pseudo-class is strictly more powerful
# [23:04] <fantasai> TabAtkins: Can do other styling based on whether placeholder text is present, styling of the input not just its placeholder text
# [23:04] <fantasai> SimonSapin: Can't use :empty because input is always empty in the DOM.
# [23:05] <fantasai> smfr: I'm imagining a UA that wants to show placeholder even while you are typing
# [23:05] <florian> From the bits I get via IRC, it seems to me that the combination of a pseudo class and ::value is good. generic and powerful.
# [23:05] <dbaron> my old pseudo-attributes proposal: http://lists.w3.org/Archives/Public/www-style/2008Oct/0144.html
# [23:06] <fantasai> fantasai: Might want to show it as a tooltip, even while you are typing a value
# [23:06] <dbaron> (in response to SimonSapin's comment about :empty)
# [23:06] <fantasai> fantasai: Seems to me that the pseudo-element better reflects the structure of what's going on
# [23:08] <tantek> fantasai: summarizing smfr: the UA may want to display placeholder text in some way (off to the side, tooltip, etc.) simultaneous with a partially user entered input text value
# [23:09] <fantasai> fantasai: In this case, you really don't want to be styling the input, you want to style specifically the placeholder text.
# [23:09] <fantasai> SimonSapin: So, do we want to have separate pseudo-elements for the value and for the placeholder?
# [23:09] <fantasai> ...
# [23:09] * Joins: plinss__ (~plinss@public.cloak)
# [23:10] <fantasai> dbaron: You wouldn't want the same style for a placeholder text displayed inline in the input vs. as a tooltip
# [23:11] <fantasai> tantek: Are there cases where the placeholder is shown together with the value?
# [23:11] <fantasai> fantasai: I think I might have seen cases where it's treated almost as a background image, you type over it as you type
# [23:12] <fantasai> fantasai: I can see that it would be very useful for things like dates, IP addresses, phone numbers, other formatted text where leaving the placeholder visible shows you exactly what you need to type next.
# [23:12] * Quits: plinss__ (~plinss@public.cloak) (plinss__)
# [23:12] <SimonSapin> HTML spec: "The placeholder attribute represents a short hint (a word or short phrase) intended to aid the user with data entry when the control has no value."
# [23:13] * Joins: smfr_ (~smfr@public.cloak)
# [23:13] * Quits: smfr (~smfr@public.cloak) ("Page closed")
# [23:13] * smfr_ is now known as smfr
# [23:13] * Joins: glenn (~gadams@public.cloak)
# [23:13] <florian> pseudo-class + ::value or pseudo-element alone both make sense to me. Pseudo-class + fill-opacity feels a bit contrieved. It would work, but doesn't sound like attacking the problem with orthogonal concepts that are likely to play well with future ideas.
# [23:13] <fantasai> SimonSapin, you could use it as a tooltip easily, and that would be reasonable per HTML spec. I also agree with dbaron that we shouldn't apply ::placeholder styling to it if it's rendered as a tooltip rather than a placeholder, though.
# [23:14] <SimonSapin> http://www.whatwg.org/specs/web-apps/current-work/multipage/common-input-element-attributes.html#the-placeholder-attribute
# [23:14] <fantasai> SimonSapin: "when the control has no value"
# [23:14] <fantasai> Tantek: I think that's why ::value would make sense
# [23:15] * Joins: cabanier (~cabanier@public.cloak)
# [23:15] <fantasai> Tantek: But I also see author wanting to clearly target one (::value) or the other (::placeholder)
# [23:15] <fantasai> smfr agrees with this logic
# [23:15] <fantasai> dbaron: I'm fine with that, though might want to change pseudo-class to something more complicated, like e.g. :has-placeholder
# [23:16] * smfr suggests :placeholding
# [23:16] <fantasai> fantasai: could we call it :blank?
# [23:16] <dbaron> I think the "I'm fine with that" is in reference to something not minuted.
# [23:16] * Joins: SteveZ (~chatzilla@public.cloak)
# [23:17] <dbaron> Tantek (above): we could have both a pseudo-element and a pseudo-class for placeholders
# [23:17] <dbaron> discussion led to :placeholder and ::placeholder-text
# [23:17] <dbaron> then I suggested that maybe it should be ::placeholder with the pseudo-class having another name
# [23:18] <dbaron> fantasai: Should we have :blank in general for form controls
# [23:18] <dbaron> Tantek: object to :blank, too close to :empty
# [23:18] <dbaron> fantasai, Tab: :empty is useless
# [23:19] <dbaron> my old pseudo-attributes proposal (again :-): http://lists.w3.org/Archives/Public/www-style/2008Oct/0144.html
# [23:19] <dbaron> dbaron: UA's exact conditions for when it shows a placeholder may vary a bit
# [23:19] <dbaron> fantasai: why would you want to style the input as a function of when there's a placholder?
# [23:19] <dbaron> Tantek: maybe styling a background?
# [23:19] <dbaron> smfr: maybe UA wants to show placeholder only before the user has interacted with a field
# [23:20] <dbaron> Tantek: we talked about "dirtied"
# [23:20] <dbaron> dbaron: Along these lines, :valid and :invalid turned out useless, we needed our own variants
# [23:20] <dbaron> Tab: now in the spec, :user-error
# [23:21] <dbaron> Tab: so probably good to tie definition to actual UA semantics; otherwise things will turn useless again
# [23:21] <dbaron> Tantek: resist the temptation to abstract things into a different concept
# [23:21] <dbaron> smfr: also an area where UAs might want to innovate
# [23:21] <dbaron> fantasai: :placeholding and ::placeholder?
# [23:21] <dbaron> smfr: I like ::placeholder, maybe :showing-placeholder?
# [23:22] <dbaron> Bert: Can't we use ::value?
# [23:22] <dbaron> Bert: never shown at the same time
# [23:22] <dbaron> Tantek: easier for authors to understand styling just the placeholder text rather than jumping through :placeholder::value abstraction
# [23:23] <dbaron> Tantek: less powerful but easier to use
# [23:23] <florian> I like :showing-placehoder::value
# [23:23] <dbaron> Bert: how would I go about suppressing the placeholder as a user?
# [23:23] <dbaron> various: ::placeholder { opacity: 0 }
# [23:24] <dbaron> Peter, Tab: should support 'content' in addition to the ::first-line properties to support content: attr(placeholder)
# [23:25] <dbaron> Tantek: I think we have rough consensus on ::placeholder and an unnamed pseudo-class
# [23:25] <fantasai> dbaron: To some degree I'm still with Bert, not convinced we shouldn't use ::value
# [23:26] <fantasai> plinss: If your placeholder is opacity 50%, and it goes to 0, you want it to transition over 1s, so that they could be displayed at the same time over a transitional period
# [23:27] * Bert pondering input[placeholder]::placeholder {display: tooltip}
# [23:27] <florian> Do we plan to add ::value later and for other reasons? because if yes, I wonder what the difference would be between ::placeholder and :placeholding::value. would they conflict? do different things?
# [23:27] <fantasai> tantek: Liked :has-placeholder
# [23:27] <fantasai> dbaron: That's ambiguous, might mean "would show a placeholder if empty"
# [23:27] <fantasai> plinss: It's :can-haz-placeholder
# [23:27] <dbaron> s/It's/That's/
# [23:28] <fantasai> RESOLVED: Add ::placeholder pseudo-element
# [23:29] <fantasai> RESOLVED: Add a :is-showing-a-placeholder pseudo-class with a better name?
# [23:29] * sylvaing browsers who also have a ::value pseudo are screwed
# [23:29] <fantasai> szilles: When you use the a pseudo-class are the properties that would be used when the placeholder is shown
# [23:29] <tantek> http://wiki.csswg.org/spec/css4-ui#more-selectors
# [23:30] <tantek> ":placeholder pseudo-class for when an input element is in the state of showing its placeholder text"
# [23:30] <sylvaing> I don't understand the use-case for a pseudo-element
# [23:30] <florian> I agree with sylvain, and would like an explanation on how that interacts with ::value for browsers that have it.
# [23:30] <tantek> sylvaing - opacity
# [23:30] * fantasai is still not convinced the pseudo-class is necessary given the pseudo-class
# [23:31] <sylvaing> tantek, opacity is not an argument at all. we've been over this
# [23:31] <fantasai> florian, ::value styles the actual value. ::value does not apply to the placeholder text.
# [23:31] * dbaron is convinced fantasai had a typo
# [23:31] <sylvaing> you don't add pseudo-elements to work around a property
# [23:31] <florian> fantasai, so what does :placeholding::value style? nothing?
# [23:32] <fantasai> right
# [23:32] <tantek> So it makes more sense to put the longer name on the pseudo-element
# [23:32] <dbaron> Tantek: I think we should give the good name to the pseudo-class.
# [23:32] <tantek> e.g. ::placeholder-value
# [23:32] * fantasai disagrees
# [23:32] <dbaron> Tantek: So :placeholder and ::placeholder-value
# [23:32] <sylvaing> we can't have ::value and ::placeholder. they are the same thing in a different state.
# [23:32] <fantasai> sylvaing, we're arguing that they're not
# [23:32] <tantek> and reserve the more generic name for the state of showing the placeholder
# [23:32] <tantek> :placeholder
# [23:32] <tantek> sylvaing - you missed the reason plinss gave above
# [23:32] <tantek> you may want to transition them separately
# [23:32] <fantasai> sylvaing, that in some cases it could make sense to show both simultaneously
# [23:33] * stearns notes there's a placeholder attribute in HTML, which makes me think ::placeholder is better than ::value for this case
# [23:33] <sylvaing> that is a use-case; but it implies other things e.g. these things always have the same size/position by default
# [23:33] <sylvaing> you don't want authors to have to position/size two things every time they want a nice fade
# [23:34] <dbaron> fantasai: So the reason I don't think the pseudo-class should be placeholder, and that the pseudo-element should be placeholder, is that the placeholder is a bunch of text; the input element is showing a placeholder but it is not a placeholder.
# [23:34] <dbaron> Tab: I think that's overthinking the issue.
# [23:34] <dbaron> Tantek: I think if you want to look at the name options in context.
# [23:35] <dbaron> Tantek: I think :placeholder and ::placeholder-value is the least bad naming option.
# [23:35] <dbaron> SteveZ: I think we need a set of name candidates, but shouldn't bikeshed here.
# [23:35] <dbaron> Tantek: I think we just need to pick a set of names.
# [23:36] <dbaron> Tab: I'd like to pick names today.
# [23:36] <florian> I am with fantasai, placeholder to me can only be the name of the pseudo element
# [23:36] <dbaron> fantasai: I don't want people to be confused into thinking that they're styling the placeholder when styling the input element.
# [23:36] <dbaron> fantasai: ::placeholder and :showing-placeholder
# [23:37] <florian> a bit verbose, but otherwise I like that
# [23:37] <dbaron> Tantek: we also have :autofill that Mozilla and WebKit have both implemented
# [23:37] <dbaron> Tantek: I think we have direction of simpler, shorter, thing being the pseudo class
# [23:37] <dbaron> dbaron: Gecko has no auto-fill pseudo class
# [23:38] <dbaron> Bert: If I use attr() function, take value of attribute, and put it somewher, would the input element be in its showing-placeholdre state?
# [23:38] * fantasai thinks we should break the topic and come back to it later when people have had some time to think
# [23:38] <sylvaing> i think this is a poor decision. this shouldn't be designed in a one-hour meeting.
# [23:38] <tantek> sorry - I misspoke - I assumed the bugs had been fixed/implemented
# [23:38] <dbaron> dbaron: no, only if it's showing the placeholder as a function of its rules for showing placeholders
# [23:38] <tantek> https://bugzilla.mozilla.org/show_bug.cgi?id=740979 and https://bugs.webkit.org/show_bug.cgi?id=66032
# [23:38] <tantek> (re: autofill )
# [23:39] <dbaron> Tab: could do ... yourself using the styling
# [23:39] * fantasai ponders the situation of showing both value and placeholder simultaneously -- would :placeholder give appropriate styling then?
# [23:39] <dbaron> Bert: assuming we generalize content property on pseudo-element to be empty, woudld it then be showing placehloder text?
# [23:40] <dbaron> fantasai: I think we need distinguish between placeholder attribute and idea of displaying placeholder text.
# [23:40] <tantek> re: showing both simultaneously - that's an effect of a transition, not a state overlap
# [23:40] <SimonSapin> glazou: ::placeholder and :placeholding
# [23:40] <dbaron> fantasai: So the UA is capable of doing thing where it shows some kind of Ghost text where it helps user figure out what to type
# [23:40] <dbaron> ScribeNick: dbaron
# [23:40] <tantek> "placeholding" sounds awkward as a state
# [23:40] <dbaron> fantasai: placeholder attribute is one thing intended to be used in this way
# [23:40] <dbaron> Tantek: I disagree on basis of HTML spec
# [23:41] <dbaron> fantasai: but if you display in some other way it wouldn't be triggering placeholder pseudo-element... might trigger tooltip pseudo-element, but would be placeholder attribute's value showing up in some other pseudo-element
# [23:41] <dbaron> SteveZ: Wouldn't that give me the way to do what smfr and I want to do by leving the text there and abs posing it so it wouldn't disappear?
# [23:41] <dbaron> Tantek: I think you're making up a new feature.
# [23:41] <dbaron> Tantek: As defined in HTML, what you're describing is not that.
# [23:42] <dbaron> fantasai: Dosen't require it to show up in the ..., says it's a hint.
# [23:42] <dbaron> fantasai: Doesn't say it has to be shown inside
# [23:42] <dbaron> Tantek: overlap case of showing up when you're typing is outside bounds of html definition
# [23:42] <dbaron> Tantek: html definition reflects exiusting interpoerable practice and we should make that work before doing other stuff
# [23:42] <dbaron> SimonSapin: Steve, you can always use data-* attributes and select on them
# [23:43] * florian is not too sure about how transition works, but wonders why a transition on :placeholding::value {opacity:0} wouldn't allow the crossfade as well as the pseudo element
# [23:43] <dbaron> dbaron: do we need to update the resolution?
# [23:44] <dbaron> Tantek: I object to the resolution from 15 minutes ago.
# [23:45] <dbaron> RESOLUTION: previous resolution-pair possibly retracted, discussion to be continued tomorrow
# [23:45] <dbaron> Tab: Tomorrow want to get something somebody can *implement*
# [23:45] <dbaron> Peter: break until 4pm
# [23:45] <sylvaing> well, we've already implemented something....:)
# [23:46] * florian wishes he was in Tucson
# [23:49] * Quits: SteveZ (~chatzilla@public.cloak) (Ping timeout: 60 seconds)
# [23:50] <SimonSapin> Tab: (continued) … can implement, and then not mess with it anymore
# [23:51] * sylvaing Because discussions driven by arbitrary deadlines never need re-visiting?
# [23:52] * Quits: plinss_ (~plinss@public.cloak) (Ping timeout: 60 seconds)
# [23:55] * florian thinks it is worth having a concrete proposal on the table, even if it is not set it stone, so that we can go home and think carefully whether it works, rather than go home and invent 12 different alternative ways to solve the same problem, and then try to figure out which one to keep
# [23:57] * plinss is now known as plinss_away
# Session Close: Tue Feb 05 00:00:00 2013

The end :)