/irc-logs / w3c / #css / 2010-08-25 / end

Options:

# Session Start: Wed Aug 25 00:00:00 2010
# Session Ident: #css
# [00:29] * Quits: nimbupani (nimbupani@24.22.131.46) (Quit: nimbupani)
# [00:48] * Quits: lstorset (lstorset@84.215.115.49) (Ping timeout)
# [00:58] * Quits: Arron (arronei@84.208.66.187) (Ping timeout)
# [00:58] * Joins: lstorset (lstorset@84.215.115.49)
# [01:14] * Joins: nimbupani (nimbupani@24.22.131.46)
# [01:35] * Quits: lstorset (lstorset@84.215.115.49) (Ping timeout)
# [02:01] * Joins: dstorey (dstorey@213.236.208.22)
# [02:06] * Quits: nimbupani (nimbupani@24.22.131.46) (Quit: nimbupani)
# [02:47] * Joins: nimbupani (nimbupani@24.22.131.46)
# [02:49] * Quits: nimbupani (nimbupani@24.22.131.46) (Quit: nimbupani)
# [04:02] * Joins: anne5 (annevk@84.208.74.81)
# [04:13] * Joins: dstorey_ (dstorey@213.236.208.247)
# [04:14] * Quits: dstorey (dstorey@213.236.208.22) (Ping timeout)
# [04:21] * Quits: anne5 (annevk@84.208.74.81) (Client exited)
# [04:22] * Joins: anne5 (annevk@84.208.74.81)
# [04:29] * Joins: miketaylr (miketaylr@24.42.95.108)
# [04:32] * Joins: dstorey (dstorey@213.236.208.22)
# [04:33] * Quits: dstorey_ (dstorey@213.236.208.247) (Ping timeout)
# [04:37] * Joins: nimbupani (nimbupani@24.22.131.46)
# [04:58] * Quits: nimbupani (nimbupani@24.22.131.46) (Quit: nimbupani)
# [05:23] * Quits: dstorey (dstorey@213.236.208.22) (Quit: dstorey)
# [05:32] * Quits: anne5 (annevk@84.208.74.81) (Quit: anne5)
# [05:34] * Joins: dstorey (dstorey@84.215.178.67)
# [05:52] * Joins: dstorey_ (dstorey@84.215.166.113)
# [05:53] * Quits: dstorey (dstorey@84.215.178.67) (Ping timeout)
# [05:59] * Quits: dstorey_ (dstorey@84.215.166.113) (Quit: dstorey_)
# [06:04] * Joins: nimbupani (nimbupani@24.22.131.46)
# [06:05] * Quits: nimbupani (nimbupani@24.22.131.46) (Quit: nimbupani)
# [06:32] * Quits: miketaylr (miketaylr@24.42.95.108) (Client exited)
# [07:19] * Quits: Curt` (DorkeyDear@75.10.129.150) (Quit: Leaving)
# [07:27] * Joins: dbaron (dbaron@84.208.66.187)
# [07:36] * Joins: Arron (arronei@84.208.66.187)
# [07:44] * Quits: Arron (arronei@84.208.66.187) (Ping timeout)
# [07:47] * Joins: dsinger (dsinger@84.208.65.171)
# [08:07] * Joins: Arron (arronei@84.208.66.187)
# [08:22] * Quits: dsinger (dsinger@84.208.65.171) (Quit: dsinger)
# [08:27] * Disconnected
# [08:28] * Attempting to rejoin channel #css
# [08:28] * Rejoined channel #css
# [08:28] * Topic is 'CSS Working Group discussion'
# [08:28] * Set by fantasai on Mon Aug 02 00:49:50
# [08:29] * Quits: dbaron (dbaron@84.208.66.187) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [08:33] * Quits: Arron (arronei@84.208.66.187) (Ping timeout)
# [08:40] * Joins: dsinger (dsinger@84.208.66.187)
# [08:41] * Joins: dsinger_ (dsinger@84.208.66.187)
# [08:41] * Quits: dsinger (dsinger@84.208.66.187) (Connection reset by peer)
# [08:41] * dsinger_ is now known as dsinger
# [08:46] * Quits: tantek (tantek@84.208.66.187) (Quit: tantek)
# [08:47] * Quits: dsinger (dsinger@84.208.66.187) (Quit: dsinger)
# [08:51] * Joins: anne5 (annevk@213.236.208.247)
# [09:05] * Joins: davve (davve@83.218.67.122)
# [09:09] * Joins: glazou (glazou@213.236.208.247)
# [09:09] * Joins: Zakim (rrs-bridgg@128.30.52.169)
# [09:09] <glazou> RRSAgent, make logs public
# [09:09] <RRSAgent> I have made the request, glazou
# [09:13] * Joins: JohnJansen (qw3birc@128.30.52.28)
# [09:14] * Joins: dsinger (dsinger@213.236.208.247)
# [09:16] * Joins: TabAtkins_ (chatzilla@213.236.208.247)
# [09:16] * Joins: jdaggett (jdaggett@213.236.208.247)
# [09:17] * Joins: Arron (arronei@213.236.208.247)
# [09:18] <TabAtkins_> tantek: I'd like to talk about CSS3 UI again.
# [09:18] * Joins: dbaron (dbaron@213.236.208.247)
# [09:18] <TabAtkins_> dbaron: Vendor prefixes and whether we can remove it for calc().
# [09:18] <TabAtkins_> fantasai: CSS 2.1 margin collapsing.
# [09:18] <TabAtkins_> jdaggett: Test submission
# [09:19] * dbaron Zakim, remind us in 9 hours to go home
# [09:19] * Zakim ok, dbaron
# [09:19] <TabAtkins_> arronei: CSS 2.1 dates
# [09:19] * Joins: tantek (tantek@213.236.208.247)
# [09:21] <fantasai> ScribeNick: fantasai
# [09:23] <fantasai> Topic: Tests and PR
# [09:23] * Joins: CesarAcebal (acebal@213.236.208.247)
# [09:24] <jdaggett> http://blogs.msdn.com/b/ie/archive/2010/08/04/html5-modernized-fourth-ie9-platform-preview-available-for-developers.aspx
# [09:24] <fantasai> jdaggett: This is a blog post by the IE team, by Dean, talking about the platform preview.
# [09:25] <fantasai> jdaggett: There's a section where he's talking about tests, specifically this paragraph "With Platform Preview 4, we're contributing ... standards bodies..."
# [09:25] * Joins: myakura (d2e8220d@78.129.202.38)
# [09:25] <fantasai> jdaggett: He's got this list that's implying that IE9 is the most compatible browsers
# [09:25] <fantasai> jdaggett: The number of tests listed -- this is a really bad statement.
# [09:25] <fantasai> jdaggett: They were not submitted tests.
# [09:25] <fantasai> jdaggett: And the tests wouldn't even pass review at Microsoft
# [09:25] <fantasai> jdaggett: It's always good that have tests that pass in other browsers
# [09:26] <fantasai> jdaggett: but I think this just represents a bad faith effort on the part of the marketing dept at MS
# [09:26] <fantasai> jdaggett: This is just irresponsible.
# [09:26] <fantasai> jdaggett: If they want to say "we have this set of tests, and we pass, and they don't"
# [09:26] <fantasai> jdaggett: that's fine, but to imply that they have been blessed by the standards group
# [09:27] <fantasai> dbaron: If you're going to publish them this publicly, you should be more responsible about responding to error reports
# [09:27] <fantasai> glazou: When IE9 published a set of tests, there were 11 Selectors tests and 3-4 were wrong
# [09:28] <fantasai> glazou: And these tests were showing overwhelmingly better support in IE9
# [09:28] <fantasai> glazou: But because of these errors, it was actually the other way around
# [09:28] <fantasai> JohnJansen: There is a level of clarification that would make this better
# [09:28] <fantasai> JohnJansen: First, we're not unresponsive.
# [09:28] <fantasai> dbaron: When the blog post is getting a lot of PR, it's not getting a week later.
# [09:29] <fantasai> JohnJansen: I don't believe Iit's intentionally a bad faith efford. I think it's an error.
# [09:29] <fantasai> jdaggett: I understand that marketing wants to go out and say "we're the best"
# [09:29] <fantasai> jdaggett: Other people in the org should say, that's a fine thing to say, but you shouldn't say it in this way.
# [09:30] <fantasai> jdaggett: This is flagrantly inaccurate
# [09:30] <dbaron> jdaggett: tests were checked in, but no notice that they were submitted
# [09:30] <fantasai> anne: What John is saying that you haven't emailed public-css-testsuite with notice about the tests
# [09:31] <fantasai> anne: You've only checked them in. Nobody knows they're there
# [09:31] <fantasai> jdaggett: I don't want to have a nitpicky about what rule was or was not followed
# [09:31] <fantasai> jdaggett: I'm just saying that this is bad faith effort. Someone is trying to insinuate that these are official standards-body-blessed tests.
# [09:31] <fantasai> jdaggett: If you look at some of these tests, the quality is not there. These should have been reviewed before posting.
# [09:32] * Joins: Matthias (matthiasva@81.242.212.104)
# [09:32] <fantasai> JohnJansen: You're saying that we shouldn't submit tests that wouldn't pass our internal review process. I agree with you.
# [09:32] <fantasai> JohnJansen: But also the prose here is missing the clarification that the tests were not submitted.
# [09:33] <fantasai> dbaron: I don't want to see you block your submissions due to not having completed your internal review
# [09:33] <fantasai> dbaron: But don't publicize those tests.
# [09:33] <fantasai> dsinger: Publishing numbers on the other browsers before they've had a chance to run it is not very good
# [09:34] <fantasai> jdaggett: I think we all can sit down and write tests that will fail in other browsers. It's an exercise we can do.
# [09:34] <fantasai> jdaggett: But it doesn't help us as a group trying to promote CSS
# [09:34] <fantasai> jdaggett: Authors will think, oh, this feature is not stable, I cannot use this feature.
# [09:34] <fantasai> JohnJansen: I don't think these tests are intended to fail in other browsers -- they're just trying to test the features.
# [09:35] <dbaron> dsinger: we really do appreciate these tests
# [09:35] <fantasai> Tantek: I'd like to emphasize dbaron's point.
# [09:35] <fantasai> Tantek: The earlier and more open the review, the better.
# [09:35] <fantasai> Tantek: The key is not to connect that with soe kind of summary result
# [09:35] <fantasai> JohnJansen: Until they're reviewed.
# [09:36] <fantasai> Tantek: Having everyone able to review the tests is great. I'm a fan of the open review.
# [09:36] <fantasai> Tantek: There were two problems: The first one was the lack of notification. The second was publishing results on unreviewed tests.
# [09:37] <fantasai> jdaggett: Another problem is some of the tests will only work on Windows because of specific font dependencies
# [09:37] <fantasai> jdaggett: For a test that's a general browser tests, it has to be a different test.
# [09:37] <dbaron> jdaggett: I don't want to say you need to do specifically X, Y, and Z, but I want you to make a good faith effort.
# [09:38] <fantasai> Topic: Fonts
# [09:38] <fantasai> jdaggett: I wanted to talk about font features, review where we are, what's been fixed up, and then where we're going from here
# [09:39] <fantasai> ChrisL: It might be useful to note that this part of the spec was reviewed at TypeCon last week
# [09:39] <fantasai> jdaggett: Right.
# [09:39] <fantasai> jdaggett: Just to step back and review what we're talking about, we're extending font-variant to support OpenType features.
# [09:39] <jdaggett> http://dev.w3.org/csswg/css3-fonts/#font-rend-props
# [09:40] <fantasai> jdaggett: By that I mean many are features that are general to font formats, but we're looking at OpenType features especially
# [09:40] <fantasai> jdaggett: OpenType features affect not font selection, but glyph selection and position
# [09:40] <fantasai> jdaggett: It's sort of about layout, but in the context of text layout within a line
# [09:40] <fantasai> jdaggett: The idea is to extend font-variant
# [09:41] <fantasai> jdaggett: There's a whole list of these features. Some of these are only used by a shaping engine when rendering a particular language, etc.
# [09:41] <fantasai> jdaggett: The question is how dow we reduce the stress of creating new properties
# [09:41] <fantasai> jdaggett: We want to group these into logical sets of properties
# [09:41] * Joins: ChrisL (ChrisL@128.30.52.169)
# [09:41] <fantasai> jdaggett: As I said, it's about OpenType primarily -- we've given a mapping from these features to these OpenType features.
# [09:41] <fantasai> jdaggett: That way implementations know exactly what to do
# [09:42] <fantasai> jdaggett: For other font formats, it's not normatively defined,b ut you can use the OpenType mapping to determine what it would be.
# [09:42] <fantasai> jdaggett: For different scripts, the font will enable different features.
# [09:42] <fantasai> jdaggett: Fonts have default glyphs for each codepoint.
# [09:43] <fantasai> jdaggett: In general, the author can choose a special glyph, otherwise we use the default glyph
# [09:43] <fantasai> jdaggett: There are some features that are font-specific. E.g. you give it a number and it picks that glyph set
# [09:43] <fantasai> jdaggett: People have brought up the issue that they don't want fallback to bring in unintended alternates, so I've tweaked the spec to address that.
# [09:44] <fantasai> jdaggett: Another commment is that OpenType allows both script-specific and language-specific features.
# [09:44] <fantasai> jdaggett: The script is inferred from the codepoints
# [09:44] <fantasai> jdaggett: The language is given by the 'lang' attribute.
# [09:44] <fantasai> jdaggett: first part here is kerning
# [09:44] <fantasai> jdaggett: I originally had this as none or normal
# [09:45] <fantasai> jdaggett: But the WebKit guys didn't want to have kerning on by default, so we added an 'auto' value
# [09:45] <fantasai> jdaggett: Leaving it up to the UA whether to enable kerning or not
# [09:46] <fantasai> jdaggett: The feature allows authors to ensure kerning is on
# [09:46] <fantasai> howcome: Are there any other controls we should add here?
# [09:47] <fantasai> jdaggett: There was some confusion from the type community was they thought 'auto' meant optical kerning.
# [09:47] <fantasai> howcome: We could add an 'optical' keyword later
# [09:47] <fantasai> ChrisL: jdaggett explained what 'auto' means in CSS
# [09:47] <fantasai> jdaggett: font-variant-ligatures
# [09:48] <fantasai> Steve: 'normal' here seems to mean something different
# [09:48] <fantasai> jdaggett: In OpenType there are specific sets of features that are commonly enabled.
# [09:48] <fantasai> jdaggett: others are not
# [09:48] <fantasai> jdaggett: For example, common ligatures are typically enabled, and discretionary ligatures are not
# [09:48] <fantasai> jdaggett: by default
# [09:49] <fantasai> jdaggett: That's the default of the OpenType engine
# [09:49] <fantasai> Steve: So you're using 'normal' for the OpenType default
# [09:49] <fantasai> ChrisL asks about Arabic ligatures
# [09:51] <fantasai> jdaggett: We don't allow access to controlling required ligatures (needed to display the language correctly) through this property
# [09:51] <ChrisL> jdaggett mentioned adding text to say that hinting auto does not mean 'autohinting' in the typographic sense. That would be a useful addition
# [09:52] <fantasai> several discuss having a 'none' value
# [09:52] <fantasai> jdaggett thinks it's not necessary, not useful, and potentially confusing since it doesn't address required ligatures
# [09:52] <dbaron> Steve: sounds like the spec should say that this property doesn't influence required ligatures
# [09:52] <fantasai> Steve: It would be useful to note in the definition that required litagatures are not affected by this property
# [09:52] <fantasai> jdaggett: font-variant-alternates
# [09:53] <fantasai> jdaggett: You can set e.g. swash forms through this
# [09:53] <fantasai> jdaggett: And a font can have multiple swash sets, so it takes a number
# [09:54] <fantasai> jdaggett: There are no names for swash sets, you use numbers, e.g. swash(3)
# [09:55] <fantasai> jdaggett: So the numbers here are not selecting specific glyphs, but a set of glyphs identified in the font
# [09:55] <fantasai> jdaggett: A font can have a set of variations
# [09:56] <fantasai> jdaggett: In the case of character variants, you can pick specific variants for a particular glyph
# [09:56] <fantasai> jdaggett: E.g. people researching old Greek coins
# [09:56] <fantasai> jdaggett: can express exactly what was on the coins
# [09:56] <jdaggett> http://typography.com/fonts/font_documentation.php?docID=6&productLineID=100026#sets
# [09:56] * Joins: lstorset (lstorset@213.236.208.247)
# [09:56] <fantasai> jdaggett: This is a font by ? and Frere Jones
# [09:57] * Joins: alexmog (alexmog@213.236.208.247)
# [09:57] <fantasai> jdaggett: They did the Gotham font Obama used in his campaign
# [09:57] <fantasai> jdaggett: They're a very smart set of people, and they have brilliant documentation
# [09:57] <fantasai> jdaggett: They show the number, and then what it means
# [09:57] <fantasai> jdaggett: You can mix and match these
# [09:58] <fantasai> jdaggett: MS has provided support for style sets in Office 2010, but you can't select multiple sets
# [09:58] <fantasai> jdaggett: (except with Visual Basic)
# [09:59] <fantasai> Steve suggests having an at-rule to assign names to the numbers
# [09:59] <fantasai> jdaggett wants to hold off until later and stabilize the spec
# [09:59] <fantasai> jdaggett: Let's talk about fallback
# [10:00] <fantasai> jdaggett: Anything with a number is labeled as "font-specific"
# [10:00] <ChrisL> this feature helps keep the info in the style, rather than being in markup (or worse, images) to get this effect
# [10:01] <fantasai> jdaggett: They do not apply to generic font families or to the UA's ultimate fallback font
# [10:03] <fantasai> dsinger: suggests s/given font-family list/specified font-family list/
# [10:04] <fantasai> fantasai: I don't think this is really disconnecting the style set numbers from inappropriate fonts
# [10:05] <fantasai> fantasai: ...
# [10:05] * Quits: Lachy (Lachlan@84.215.59.50) (Quit: This computer has gone to sleep)
# [10:06] <fantasai> ChrisL: If you as a reader want to reset the font-family, you can also reset font-variant.
# [10:06] <fantasai> howcome: I think it should only apply to the first font in the font-family list
# [10:06] <fantasai> jdaggett doesn't agree
# [10:07] <fantasai> someone brings up selecting multipe fonts from different families to support multipe scripts
# [10:07] <fantasai> steve: Why didn't you allow assigning a family name along with the number?
# [10:07] <fantasai> jdaggett: what if you want the number to apply to all the fonts in your list?
# [10:08] <fantasai> dsinger and stevez suggest that it would be better to connect to the family name
# [10:08] <fantasai> because there are cases where the style set numbers don't match across fonts that you selected, and you know it already
# [10:09] <dsinger> well, it might be, especially if I am aware that two different platforms are likely to end up using two different fonts, and the variants I need in those fonts are differently numbered
# [10:09] <fantasai> steve: I accept that it's useful to have some kind of convenient way to trigger stylistic variations, and requiring the use of a separate font for each one is a burden
# [10:09] <fantasai> steve: but the third point is that I'm not convinced this gives enough power to make it worthwhile
# [10:09] <fantasai> steve: The issues about how fallback is handled become sufficiently complext that I'd almost rather you not do anything and have us come up with a better solution later
# [10:10] <fantasai> steve: his solution doesn't give me enough power to et consistent results
# [10:10] <fantasai> steve: Because there are enough ....
# [10:11] * Joins: szilles (chatzilla@213.236.208.247)
# [10:11] * Quits: CesarAcebal (acebal@213.236.208.247) (No route to host)
# [10:11] * Quits: jdaggett (jdaggett@213.236.208.247) (Connection reset by peer)
# [10:11] * Joins: dsinger_ (dsinger@213.236.208.247)
# [10:11] * Quits: tantek (tantek@213.236.208.247) (No route to host)
# [10:11] * Quits: dsinger (dsinger@213.236.208.247) (Connection reset by peer)
# [10:11] * Quits: glazou (glazou@213.236.208.247) (No route to host)
# [10:11] <fantasai> dsinger: How conssitently is the same feature labeled across fonts?
# [10:11] * Joins: CesarAcebal (acebal@213.236.208.247)
# [10:11] * Joins: tantek (tantek@213.236.208.247)
# [10:11] * dsinger_ is now known as dsinger
# [10:11] * Joins: jdaggett (jdaggett@213.236.208.247)
# [10:11] * Quits: TabAtkins_ (chatzilla@213.236.208.247) (No route to host)
# [10:11] * Joins: glazou (glazou@213.236.208.247)
# [10:11] * Joins: TabAtkins_ (chatzilla@213.236.208.247)
# [10:12] <dsinger> apparently, the answer is not very
# [10:12] <fantasai> dbaron: The point is that typically, the vast majjority of fonts don't have these features
# [10:12] * Joins: Doofl (mstensho@213.236.208.247)
# [10:12] <dbaron> dbaron: the point is that 99% of the fonts don't have these features, so the most common case will be a single downloadable font at the start of the font list being the only one that has these features
# [10:12] <fantasai> fantasai: ...
# [10:12] <fantasai> steve: The case that I'm concerned about is that Apple will ship a font with stylistic variants on their platform
# [10:13] <fantasai> steve: And Microsoft will do the same. They won't be the same font. They won't have the same stylistic numbers. ANd I will need to put both fonts in my list to get the local one that ships
# [10:13] * Joins: JohnJansen_ (qw3birc@128.30.52.28)
# [10:13] <fantasai> Steve: I see that as being almost 100% certain
# [10:13] <fantasai> dbaron: In that case you can use @font-face with src: local
# [10:13] * Quits: JohnJansen (qw3birc@128.30.52.28) (Ping timeout)
# [10:13] <fantasai> dbaron: You can have an @font-face with ArialFunnyK and HelveticalFunnyK and use those
# [10:14] * Quits: JohnJansen_ (qw3birc@128.30.52.28) (Quit: Page closed)
# [10:14] * Joins: JohnJansen (qw3birc@128.30.52.28)
# [10:14] <fantasai> steve: You're assuming in this design that there aren't going to be fonts with different stylistic variants in the same font-family list
# [10:15] <fantasai> steve: And I think you're completely wrong, that it's almost 100% certain that we'll get that case
# [10:16] <fantasai> Tantek: I have a dumb question. Was it considered to use strings instead of numbers in the fonts?
# [10:16] <fantasai> jdaggett: The font format has a way of assigning names to these. Most fonts don't use them.
# [10:17] <fantasai> jdaggett: Secondly, those names are localized. So what are you matching against?
# [10:17] * Quits: ChrisL (ChrisL@128.30.52.169) (Ping timeout)
# [10:18] <fantasai> Tantek: I'm concerned about the readability and maintainability of style sheets with these arbitrary numbers
# [10:18] <dbaron> ChrisL: have an @-rule that defines names for the swash numbers for a given family
# [10:18] <fantasai> ChrisL proposes syntax to map a keyword name to a number and a font
# [10:19] <fantasai> ChrisL: So you can define "swishes" for font X to be 3, and "swishes" for font Y to be 1
# [10:19] <fantasai> dsinger: How would I naively expect to be able to do this?
# [10:20] <fantasai> dsinger describes use that matches @font-face
# [10:20] <fantasai> Tantek: Have you talked with the TypeKit folks?
# [10:21] <fantasai> Steve: Adobe's customers want to use the Web.
# [10:21] <fantasai> licensing discussion
# [10:22] * dbaron thought we had this exact same discussion a few meetings back
# [10:25] * Joins: ChrisL (ChrisL@128.30.52.169)
# [10:26] <fantasai> fantasai: I still have strong concerns about the way numbers aren't tied to a specific font.
# [10:26] <fantasai> fantasai: I understand that you want a quick way for authors to enable features
# [10:27] <fantasai> fantasai: I'd be satisfied if the numbers were only assigned to the first font in the list, to limit damge from font fallback
# [10:27] <fantasai> fantasai: ...
# [10:27] <fantasai> dsinger: I can't imagine someone caring enough about fonts to select these specific features that wouldn't want to use an @font-face rule to get it exactly right.
# [10:28] <tantek> I tend to agree with dsinger.
# [10:28] <fantasai> steve: I agree with dsinger
# [10:28] <tantek> @font-face is the right place for this level of detail for fonts.
# [10:29] <fantasai> jdaggett: you keep talking about finding a more ideal way of doing this, ...
# [10:29] <fantasai> steve: we've already had two suggestions, Arron's to pair the number with a font-family name
# [10:29] <fantasai> steve: And Chris's to map numbers to names in a 3-way table
# [10:30] <fantasai> steve: These are both better ways of handling it than what you've got
# [10:30] <fantasai> jdaggett: font-variant-small-caps?
# [10:30] <fantasai> jdaggett: Simulation only for small-caps
# [10:31] <fantasai> jdaggett: Some people asked about all-small-caps and all-petite-caps and why not use small-caps + text-transform
# [10:31] <fantasai> jdaggett: The reason is that there are other glyphs that might be altered when the font designer knows they will be all small-caps, e.g. adjusting punctuation and currency signs
# [10:32] * Joins: Lachy (Lachlan@213.236.208.22)
# [10:32] * Quits: Lachy (Lachlan@213.236.208.22) (Client exited)
# [10:32] * Joins: Lachy (Lachlan@213.236.208.22)
# [10:33] <fantasai> fantasai: There was a suggestion that petite-caps should fall back to small-caps.
# [10:34] * Quits: anne5 (annevk@213.236.208.247) (Client exited)
# [10:34] * Joins: anne5 (annevk@213.236.208.247)
# [10:35] <fantasai> jdaggett: use a font that has petite-caps
# [10:36] <fantasai> fantasai: What if I don't care too much about what font is being used so I don't bother to give you a downloadable font
# [10:36] <fantasai> fantasai: But I prefer petite-caps to small-caps, but small-caps is closer to what I want than lowercase letters.
# [10:36] * Quits: lstorset (lstorset@213.236.208.247) (Ping timeout)
# [10:36] <fantasai> Tantek: How do I ask for petite-caps without naming a font?
# [10:37] <fantasai> Tantek: The Web is becoming more and more diverse wrt devices. You have less control about what font is being used
# [10:37] * dsinger example of small and petite here: http://www.aimwell.org/Fonts/fonts.html (about half-way down, by 'Garava')
# [10:38] <fantasai> jdaggett doesn't think this is a real problem because platform fonts dont' have petite-caps
# [10:38] * fantasai doesn't understand this argument
# [10:41] <fantasai> platform fonts are becoming more and more sophisticated over time
# [10:41] <fantasai> steve asks for fallback on style selection, e.g. font-variant-caps: petite-caps, small-caps
# [10:42] <fantasai> Tantek: Someone comes out with this ebook reader with a handful of super-amazing fonts
# [10:42] <fantasai> Tantek: as an author, I don't know the font names, because it hasn't been released yet
# [10:43] <fantasai> Tantek: but I want to use the features in these fonts.
# [10:45] <fantasai> ...
# [10:47] <ChrisL> http://typekit.com/fonts/p22-underground-petite-caps
# [10:47] <fantasai> Bert: say I want my heading names in petite caps. If you fall back to regular lowercase, then there is nothing to distinguish my headings from paragraph text.
# [10:48] <fantasai> Bert: I would rather fall back to small-caps, so the distinction is still there.
# [10:48] <fantasai> fantasai: small-caps is more similar to the intended effect
# [10:48] <fantasai> Steve: there are two ways to do fallbacks: one is hardwired, e.g. small-caps gets synthesized
# [10:49] <fantasai> Steve: the other is to have the author specify a fallback
# [10:49] <fantasai> ...
# [10:49] <fantasai> fantasai: nobody is arguing for synthesized petite-caps. We're suggesting it falls back to small-caps
# [10:51] <fantasai> ACTION: jdaggett Add this as an issue to the spec.
# [10:51] * trackbot noticed an ACTION. Trying to create it.
# [10:51] * RRSAgent records action 8
# [10:51] <trackbot> Created ACTION-262 - Add this as an issue to the spec. [on John Daggett - due 2010-09-01].
# [10:53] <fantasai> jdaggett: vertical-position .. not settled on the name -- superscripts/subscripts
# [10:53] * Joins: lstorset (lstorset@213.236.208.22)
# [10:53] <fantasai> jdaggett: We'd talked about the interaction between vertical-align and this feature.
# [10:53] <fantasai> jdaggett: I haven't put Steve's proposal is in the spec yet
# [10:54] <fantasai> jdaggett: Type community also has trouble with the way this is handled in fonts, because if the glyphs are not available it's not clear what to do
# [10:55] <fantasai> jdaggett: If you specify font-variant in an @font-face rule, that establishes the default.
# [10:56] <fantasai> fantasai: What happens if I assign the variantified font to a paragraph, and then assign font-variant: initial to it?
# [10:57] <fantasai> jdaggett: That resets the font to the OpenType defaults
# [10:57] <fantasai> fantasai: How do you distinguish that case from not setting font-variant on the paragraph?
# [10:57] <fantasai> jdaggett: Ah. Let's mark that as an issue.
# [10:58] <fantasai> jdaggett: Low-level feature settings
# [10:58] <fantasai> jdaggett: Right now the spec is defined as taking a string, which is a set of name-value pairs
# [10:59] <fantasai> jdaggett: This gives you very low-level control.
# [10:59] <fantasai> jdaggett: It gives people using unsual features the ability to trigger them.
# [10:59] <fantasai> jdaggett: Users can do stupid things with this, but it's an escape mechanism so that you can access all the features of the font system.
# [11:00] <fantasai> jdaggett gives an example of the syntax
# [11:00] <fantasai> jdaggett: I posted a new proposal that removes the stringiness of the proposal
# [11:00] <fantasai> jdaggett: My proposal is to simply give a list of idents, ident(<integer>)
# [11:01] <fantasai> jdaggett: where itent without the parens essentially implies ident(1)
# [11:01] <fantasai> jdaggett: A problem with that is that opentype feature names can e.g. start with a number
# [11:01] <fantasai> jdaggett: but in practice nobody do this
# [11:02] <fantasai> Bert: You can escape the number, then it's ok
# [11:02] <fantasai> jdaggett: One problem with this is that it's very OpenType specific
# [11:02] <fantasai> jdaggett: This syntax works well for OpenType
# [11:02] <fantasai> jdaggett: maybe not for other font systems
# [11:04] <fantasai> jdaggett: e.g. AAT uses long arbitrary strings
# [11:04] <fantasai> jdaggett: Graphite uses numeric identifiers
# [11:05] <fantasai> Steve: An implementor could map OpenType features to features in other fonts
# [11:06] <fantasai> jdaggett: Jonathan Kew mentioned that this new syntax makes it very opentype-specific
# [11:07] * Joins: howcome (howcome@213.236.208.247)
# [11:08] <fantasai> Bert: A note about syntax, if you have a functional notation name it could conflict with CSS functional notation names like attr() or rgba()
# [11:09] <fantasai> ChrisL: You could do ot-FUNC()
# [11:09] <fantasai> ChrisL: That deals with the OpenType-specificness by making it explicit
# [11:09] <Bert> (ot-hwid(1), or ot(hwid, 1)?)
# [11:09] <fantasai> former, I think :)
# [11:10] <fantasai> dbaron asks about error handling
# [11:11] <fantasai> dbaron: If I have a functional notation with two arguments, does that cause the entire declaration to be dropped, or do I just ignore that one thing
# [11:11] <fantasai> e.g. font-feature-settings: ot-hwid(1) gr-width(halfwidth, 1);
# [11:12] <fantasai> jdaggett prefers dropping the entire declaration
# [11:14] <fantasai> jdaggett reviews the "Rendering considerations" section, which defines which feature settings override which other ones
# [11:15] <fantasai> jdaggett shows an example of @font-face
# [11:15] <fantasai> that sets oldstyle-nums proportional-nums and a styleset
# [11:15] <fantasai> which is used for the body
# [11:16] <fantasai> but in tables, uses tabular-nums
# [11:17] <fantasai> jdaggett shows an example where font-feature-settings is used to obliquify only the latin text, not the cjk characters
# [11:17] <fantasai> jdaggett shows an example of font-feature-settings overriding font-variant-ligatures
# [11:18] <fantasai> jdaggett: this is an example of something being used in an un-CSS-like way
# [11:18] <fantasai> even though the font-variant-ligatures rule is more specific
# [11:19] * dbaron reminds ChrisL that it's a bug in the spec that it's using CSS for content rather than for presentation
# [11:21] <fantasai> jdaggett: OpenType allows you to have language-specific features
# [11:22] <fantasai> jdaggett: Some common ones are within Cyrillic, Bulgarian, Macedonian, and ? have their own glyphs for certain codepoints
# [11:22] <fantasai> jdaggett: OpenType allows you to use the same font across languages, and just tweak the font glyph selection to pick the right font for that language.
# [11:22] <fantasai> jdaggett: In general, you want to render in the content language
# [11:23] <fantasai> jdaggett: But in some cases, you want an override. This property is here to allow that.
# [11:23] * Quits: arronei (arronei@131.107.0.69) (Ping timeout)
# [11:24] <fantasai> jdaggett shows an example where the content language is automatically used to select the appropriate font features (this is the default behavior)
# [11:25] <fantasai> dsinger: This is OpenType specific codes
# [11:26] * Quits: ChrisL (ChrisL@128.30.52.169) (Ping timeout)
# [11:26] * Joins: ChrisL (ChrisL@128.30.52.169)
# [11:26] <fantasai> ChrisL: SVG does the same thing
# [11:26] <fantasai> dsinger: But these aren't the ISO codes
# [11:26] <dbaron> http://www.loc.gov/standards/iso639-2/php/code_list.php is the ISO codes
# [11:28] <fantasai> jdaggett: You could define a mapping from ISO lang codes to OpenType codes
# [11:28] <fantasai> jdaggett: But there are some cases where there isn't a mapping, e.g. having modern and classical typographic styles for a particular language
# [11:28] <ChrisL> s/the ISO/the ISO 3166/
# [11:29] * Joins: arronei (arronei@131.107.0.110)
# [11:29] <fantasai> dsinger: What if you want to use an SVG font? That would want an ISO code, right
# [11:30] <dbaron> 'There are 21 languages that have alternative codes for bibliographic or terminology purposes. In those cases, each is listed separately and they are designated as "B" (bibliographic) or "T" (terminology). '
# [11:30] <fantasai> fantasai: I understand why using OpenType lang codes makes sense here
# [11:30] <fantasai> fantasai: But maybe have two ways of indicating the language --
# [11:31] <fantasai> fantasai: use an identifier or a string, where the identifier is assumed to be an ISO lang code that you have to map
# [11:31] <Bert> (Make it ugly? ot-SRB, ot("SRB"))
# [11:31] <fantasai> fantasai: to the OpenType code
# [11:31] <fantasai> fantasai: (which you have to be able to do anyway, for the lang attribute)
# [11:31] <fantasai> fantasai: and if it's a string, take it as an OpenType code
# [11:33] <fantasai> howcome: Why do we set the language here in CSS?
# [11:33] <fantasai> jdaggett: It's an override. You should be using the content language in most cases (set by the lang attribute)
# [11:34] <fantasai> jdaggett: But in some cases you do need an override, because you want to render something that is in one language (and correctly tagged as so) using the typographic conventions of another language
# [11:35] <dbaron> fantasai: I think 'font-language-override' should give explanations of what it should be used for and also what it should not be used for
# [11:35] <dbaron> fantasai: so I think you should add more of what you've been explaining to us into the spec
# [11:35] <fantasai> RESOLVED: Publish css3-fonts WD
# [11:36] * Quits: glazou (glazou@213.236.208.247) (Quit: glazou)
# [11:36] <fantasai> <br type="lunch">
# [11:36] * Quits: jdaggett (jdaggett@213.236.208.247) (Quit: jdaggett)
# [11:38] * Quits: tantek (tantek@213.236.208.247) (Quit: tantek)
# [11:38] * Quits: Arron (arronei@213.236.208.247) (Ping timeout)
# [11:39] * Quits: szilles (chatzilla@213.236.208.247) (Ping timeout)
# [11:40] * Quits: dbaron (dbaron@213.236.208.247) (Ping timeout)
# [11:41] * Joins: dsinger_ (dsinger@213.236.208.247)
# [11:41] * Quits: dsinger (dsinger@213.236.208.247) (Connection reset by peer)
# [11:41] * Joins: CesarAcebal_ (acebal@213.236.208.247)
# [11:41] * dsinger_ is now known as dsinger
# [11:41] * Quits: CesarAcebal (acebal@213.236.208.247) (No route to host)
# [11:41] * CesarAcebal_ is now known as CesarAcebal
# [11:42] * Joins: mollydotcom (mollyh@213.236.208.22)
# [11:43] * Quits: JohnJansen (qw3birc@128.30.52.28) (Ping timeout)
# [11:43] * Quits: TabAtkins_ (chatzilla@213.236.208.247) (Ping timeout)
# [11:44] * mollydotcom wonders what's up
# [11:45] * gsnedders mollydotcom: OM NOM
# [11:45] * Quits: ChrisL (ChrisL@128.30.52.169) (Ping timeout)
# [11:46] <myakura> looks like css3-images is missing http://wiki.csswg.org/planning/charter-2010
# [11:46] <myakura> or is it out-of-scope?
# [11:50] * Parts: mollydotcom (mollyh@213.236.208.22)
# [11:53] * Quits: Matthias (matthiasva@81.242.212.104) (Quit: Matthias)
# [11:54] * Joins: dsinger_ (dsinger@213.236.208.247)
# [11:54] * Quits: CesarAcebal (acebal@213.236.208.247) (Connection reset by peer)
# [11:54] * Quits: dsinger (dsinger@213.236.208.247) (Connection reset by peer)
# [11:54] * dsinger_ is now known as dsinger
# [11:54] * Joins: CesarAcebal (acebal@213.236.208.247)
# [11:56] * Quits: howcome (howcome@213.236.208.247) (Ping timeout)
# [12:08] * Joins: dsinger_ (dsinger@213.236.208.247)
# [12:08] * Quits: dsinger (dsinger@213.236.208.247) (Connection reset by peer)
# [12:08] * Quits: CesarAcebal (acebal@213.236.208.247) (No route to host)
# [12:08] * dsinger_ is now known as dsinger
# [12:08] * Joins: CesarAcebal (acebal@213.236.208.247)
# [12:16] * Joins: dbaron (dbaron@213.236.208.247)
# [12:29] * Joins: tantek (tantek@213.236.208.247)
# [12:30] * Quits: tantek (tantek@213.236.208.247) (Quit: tantek)
# [12:32] * Quits: dbaron (dbaron@213.236.208.247) (Ping timeout)
# [12:33] * Joins: Arron (arronei@213.236.208.247)
# [12:33] * Joins: glazou (glazou@213.236.208.247)
# [12:33] * Joins: jdaggett (jdaggett@213.236.208.247)
# [12:34] * Joins: dbaron (dbaron@213.236.208.247)
# [12:35] * gsnedders will probably appear in a few minutes
# [12:37] * Joins: szilles (chatzilla@213.236.208.247)
# [12:37] <fantasai> </br>
# [12:37] * Joins: TabAtkins_ (chatzilla@213.236.208.247)
# [12:38] <TabAtkins_> ScribeNick: TabAtkins_
# [12:38] <fantasai> myakura, that page right now is only copied straight from 2008
# [12:39] <fantasai> myakura, it needs muhc updating
# [12:39] <fantasai> myakura, we're discussing css3-text-layout now
# [12:39] <jdaggett> http://dev.w3.org/csswg/css3-text-layout/
# [12:39] <TabAtkins_> jdaggett: There was significant hubbub a few months ago about proposals for adding logical properties.
# [12:41] <TabAtkins_> fantasai: We decided in a previous meeting that top/bottom/etc should be absolute.
# [12:41] <TabAtkins_> fantasai: So as soon as you write a page with lr switching or vertical text, everything breaks.
# [12:41] <TabAtkins_> jdaggett: So that's a compat problem with older user agent that don't suport vertical writing.
# [12:42] <TabAtkins_> fantasai: Another problem is that some documents that, for example, epub wants to publish, they want to allow the user to swap between vert and horiz text.
# [12:42] * Joins: dsinger_ (dsinger@213.236.208.247)
# [12:42] * Quits: jdaggett (jdaggett@213.236.208.247) (Connection reset by peer)
# [12:42] * Quits: glazou (glazou@213.236.208.247) (Connection reset by peer)
# [12:42] * Quits: dsinger (dsinger@213.236.208.247) (Connection reset by peer)
# [12:42] * Joins: JohnJansen (qw3birc@128.30.52.28)
# [12:42] * Quits: CesarAcebal (acebal@213.236.208.247) (No route to host)
# [12:42] * dsinger_ is now known as dsinger
# [12:42] * Joins: CesarAcebal (acebal@213.236.208.247)
# [12:43] * Joins: jdaggett (jdaggett@213.236.208.247)
# [12:43] * Joins: glazou (glazou@213.236.208.247)
# [12:43] * Quits: TabAtkins_ (chatzilla@213.236.208.247) (No route to host)
# [12:43] * Joins: TabAtkins__ (chatzilla@213.236.208.247)
# [12:43] <TabAtkins__> fantasai: Which, without logical properties, you have to write two separate stylesheets. Or rather, about 1.5, to deal with all the properties that are physical based.
# [12:43] * Joins: tantek (tantek@213.236.208.247)
# [12:43] <TabAtkins__> [gap in minutes due to my internet dropping for a sec]
# [12:44] <TabAtkins__> fantasai: So it makes translating to those languages particular difficult, because it's not just about tranlating, you have to deal with the template and stylesheet.
# [12:44] <TabAtkins__> fantasai: Also, UA stylesheet needs a margin for lists to account for bullets - ltr lists need it on the left side, rtl lists need it on the right side.
# [12:44] <TabAtkins__> jdaggett: So there are defaults on particular elements that are writing-mode dependent.
# [12:44] <TabAtkins__> fantasai: Right, and similar for a vertical-text list.
# [12:45] <TabAtkins__> fantasai: Your page shouln't break because you used the default layout for a vertical page.
# [12:45] <TabAtkins__> fantasai: So there are many cases where if you had logical properties you could get pretty far.
# [12:45] <TabAtkins__> fantasai: There are some things you'd want to tweak still, but most things would translate over fine and prevent the page from just utterly breaking when you go horiz to vert.
# [12:46] <TabAtkins__> jdaggett: I think that when you have images as part of your layout, those images aren't flipped, so your layout is going to have to change; it'll be affected in a non-directional way.
# [12:46] <TabAtkins__> jdaggett: Images aren't rotated, other content is, and that might not work.
# [12:46] <TabAtkins__> fantasai: Right. This won't solve all problems.
# [12:47] <TabAtkins__> howcome: We stand in a situation of independent properties to hundreds, plus a bunch of property values.
# [12:47] <fantasai> I'll note that images in the content (as opposed to in the styling) won't be rotated
# [12:48] <TabAtkins__> jdaggett: And what about like, B&B having to go back and change?
# [12:48] <TabAtkins__> fantasai: What exists won't change; we'd add new properties.
# [12:48] * Joins: ChrisL (ChrisL@128.30.52.169)
# [12:48] <fantasai> or values
# [12:48] <TabAtkins__> howcome: You'd have to cascade and inherit every new property.
# [12:49] <TabAtkins__> alexmog: You don't need to. At cascade time you know the writing-mode, so you can just send down the correct value.
# [12:49] <TabAtkins__> fantasai: We don't have time to go into deep details about all this right now.
# [12:49] <TabAtkins__> jdaggett: I'll assert that I think this whole thing is a rathole, and not really solving a larger set of problems with vertical text.
# [12:50] <TabAtkins__> fantasai: I don't dispute that. I explained the proposal, as requested. We can talk about why the proposal exists, but we don't have time for precise details right now.
# [12:50] <TabAtkins__> fantasai: What the WG needs to discuss is if this is a direction we do or don't have to do.
# [12:51] <TabAtkins__> szilles: I like that direction. Murakami-san listed 6 proposals for handling vertical text. I'd like to see which of those we want to pursue and see the details of, and which we can eliminate right now.
# [12:51] <TabAtkins__> szilles: The second nice thing that could and did come out would be to collect the requirements we're trying to satisfy.
# [12:51] * Joins: Ms2ger (Ms2ger@91.181.99.238)
# [12:52] <TabAtkins__> jdaggett: To me it seems like, if you're talking about epub, this proposal has a particular set of good and bad. But in HTML it's got a *different* set of good and bad.
# [12:52] <TabAtkins__> jdaggett: Like what about form controls? Does it make sense to have vertical form controls?
# [12:52] <TabAtkins__> fantasai: That's a different issue; it's unrelated to our proposals.
# [12:53] <TabAtkins__> szilles: That's something that anyone who does vertical text has to deal with, but it's not affected by how you specify.
# [12:53] <TabAtkins__> jdaggett: If form controls change, then it's a lot easier to talk about this. But if some change and some don't, it's a lot more difficult. For example, do pulldown menus rotate?
# [12:54] <TabAtkins__> jdaggett: This is going to have a big impact, and I think we need to avoid jumping directly into this.
# [12:54] <TabAtkins__> fantasai: Whether form elements rotate isn't something we're going to decide here. It's a UI designer issue.
# [12:54] <TabAtkins__> fantasai: We're going to do vertical text; that's not a question. I don't understand how whether form controls rotate or not are a useful solution.
# [12:55] <TabAtkins__> szilles: So it's a requirement for proposals to work with.
# [12:55] <TabAtkins__> anne5: Sizing and dimensions of form controls is a real interop problem. Someone has to answer this.
# [12:55] * myakura has been wondering whether the proposal can interact with CSSOM
# [12:55] * Quits: tantek (tantek@213.236.208.247) (Quit: tantek)
# [12:57] * Joins: tantek (tantek@213.236.208.247)
# [12:58] <Bert> http://nadita.com/murakami/epub-css/
# [12:58] * Joins: howcome (howcome@213.236.208.247)
# [12:58] <howcome> http://nadita.com/murakami/epub-css/
# [12:58] <szilles> http://nadita.com/murakami/epub-css/
# [12:58] <anne5> myakura, hey, don't make my life more complicated ;p
# [12:59] <TabAtkins__> [looking at the page]
# [13:00] <TabAtkins__> fantasai: Look at the Requirements section. It givs you a rought idea of what you're needing.
# [13:02] <TabAtkins__> szilles: Let's take one of the other examples; a stylesheet choice whether the page is vert or horiz.
# [13:02] <TabAtkins__> Bert: Right, so how do we ignore what it not meant for horizontal.
# [13:02] <TabAtkins__> fantasai: I want to get everyone on the same page for what the problem we're trying to solve here.
# [13:03] <Ms2ger> Hear, hear
# [13:03] <TabAtkins__> szilles: Ebooks will be posted to the web.
# [13:03] <TabAtkins__> szilles: So there is a real legacy problem.
# [13:03] <fantasai> szilles: the legacy problem isn't legacy content, it's legacy UAs
# [13:04] <TabAtkins__> annevk5: You can have a media query for a vertical-capable UA.
# [13:05] <TabAtkins__> szilles: That isn't an overall solution - pages are often mixed vert and horiz.
# [13:05] <TabAtkins__> [hakon is pionting to the examples now]
# [13:05] <fantasai> ScribeNick: fantasai
# [13:05] <TabAtkins__> howcome: the first example is two completely separate stylesheets.
# [13:05] <fantasai> howcome: the UA has to magically select the right one
# [13:05] <TabAtkins__> howcome: Perhaps a rel attribute to help select it automatically.
# [13:06] <fantasai> Alex: this wouldn't work in IE6, which supports vertical but not alternate style sheets
# [13:06] <fantasai> Steve: that wouldnt' handle mixed vertical-horizonal text
# [13:06] <fantasai> howcome: You would have a horizontal-only stylesheet, and then one that has complex
# [13:06] <fantasai> hwocome: let's go through quickly to get an overview
# [13:07] <fantasai> howcome scrolls to pseudo class selectors
# [13:07] <TabAtkins__> howcome: Second proposal is to use pseudoclasses.
# [13:07] <fantasai> ScribeNick: TabAtkins__
# [13:07] <TabAtkins__> howcome: So if you have :ltr here it means that horiz is supported and @dir=ltr.
# [13:07] <TabAtkins__> howcome: Same with :rtl. :ttb means vert is supported and writing-mode:tb-rl
# [13:08] <TabAtkins__> szilles: And if it changes you're back to the same problem.
# [13:08] <TabAtkins__> howcome: If it changes you reflow.
# [13:08] <anne5> (why is the initial value is tb-rl?)
# [13:08] <anne5> s/is//
# [13:09] <TabAtkins__> fantasai: The confusing thing is that :rtl :ltr are selecting against individual elements. :ttb is selecting a document property instead.
# [13:09] <fantasai> s/document/user agent/
# [13:10] <TabAtkins__> fantasai: There are better ways to do this.
# [13:10] <fantasai> TabAtkins__: :ltr and :rtl behave a certain way
# [13:10] <fantasai> TabAtkins__: :ttb is a completely different thing.
# [13:11] <fantasai> TabAtkins__: :ltr and :rtl is determined by which direction the element is in
# [13:11] <fantasai> TabAtkins__: :ttb is asking whether the UA is in vertical mode
# [13:11] <dbaron> [four conversations at once]
# [13:11] <anne5> (why can't :ttb be based on the computed value of 'writing-mode' for the given element?)
# [13:11] * dsinger in all four directions, too
# [13:11] <fantasai> anne5: :ttb { writing-mode: horizontal; }
# [13:12] <anne5> we already have that problem elsewhere
# [13:12] <fantasai> anne5: It's a fundamental principle that we do not make selectors depend on the value of CSS properties
# [13:12] <TabAtkins__> howcome: Next example! This is a media-query variant that queries @media (vertical-text) {}
# [13:12] <anne5> I don't think it's a problem
# [13:12] <fantasai> anne5: we're not going there
# [13:12] <anne5> e.g. :hover { display:none }
# [13:12] <TabAtkins__> jdaggett: So this is asking for capability or setting?
# [13:12] <anne5> we already did
# [13:12] <TabAtkins__> szilles: Capability.
# [13:12] <dbaron> dbaron: You could have media queries for capability and mode separately.
# [13:13] <dbaron> howcome: where mode is whether the user has put it into vertical mode
# [13:13] <TabAtkins__> howcome: You could also have both media queries for device capability of doing vertical writing, and whether the user has asked for vertical or horiz writing.
# [13:14] <TabAtkins__> jdaggett: [shows off an ereader app]
# [13:14] * Quits: myakura (d2e8220d@78.129.202.38) (Quit: http://www.mibbit.com ajax IRC Client)
# [13:14] <fantasai> [with a vertical - horizontal mode switch button]
# [13:14] <TabAtkins__> jdaggett: [shows it offering a vert/horiz choice in the basic menubar]
# [13:14] <TabAtkins__> jdaggett: It's this functionality the epub guys are talking about.
# [13:15] <TabAtkins__> jdaggett: This seems like a red herring. There's some text you'll look at one way, and some text you'll look at another way.
# [13:15] <TabAtkins__> anne5: It seems weird to explicitly address this use-case. It feels like it should be alternate stylesheets. There could be tons of devices with weird buttons that switch things.
# [13:15] <dbaron> The query for capability could be @supports ( writing-mode: tb-rl )
# [13:16] <TabAtkins__> arronei: Those devices could be designed to toggle between very specific types of stylesheets. Maybe a rel value or similar.
# [13:16] <TabAtkins__> szilles: Getting back to elika's point, I'd like to use most of my stylesheet in either mode.
# [13:16] <TabAtkins__> arronei: That's how alternate stylesheets work. You can set a persistent stylesheet and then choose the particular alternates.
# [13:17] <anne5> there's a whole lot of style sheet types: http://dev.w3.org/csswg/cssom/#style-sheet-collections
# [13:17] <TabAtkins__> jdaggett: Also, that's a rare use-case. The common case is that people are designing a page for one direction only.
# [13:17] <anne5> people who wrote HTML4 made this complicated
# [13:17] <TabAtkins__> szilles: You're assuming that one person is doing all this.
# [13:17] <anne5> (and also Hixie)
# [13:20] <TabAtkins__> TabAtkins__: If you're now saying that pages aren't generally designing for both directions, but you just showed off a device that makes switching between directions easily, it feels contradictory.
# [13:21] <TabAtkins__> jdaggett: Those are basically for compatibility. Some pages are meant to be read horizontally or are easier to read like that, others are easier to read vertically. The buttons aren't really meant for user preference, just selecting the particular mode that a certain page is designed towards.
# [13:22] <TabAtkins__> dbaron: I don't think we should screw up vertical text on the web by fixing it towards epub immediately. And I don't think we *can* do it right without implementation experience.
# [13:22] <TabAtkins__> dbaron: It's about finding the biggest use-cases first and then figuring out the rest based on what people say they want.
# [13:23] <TabAtkins__> jdaggett: [shows off a japanese website]
# [13:23] <TabAtkins__> jdaggett: They're using in various places a mixture of vert and horiz text.
# [13:24] <TabAtkins__> jdaggett: More than "how is someone doing fallback", they'll probably design their site so that in older UAs they'll do a flash version, and everywhere else they'll do it in CSS.
# [13:24] <TabAtkins__> howcome: It'll probably be useful there to have a query to ask if there is vertical support.
# [13:24] <jdaggett> http://www.ukai.co.jp/toriyama/flash/index.html
# [13:25] * fantasai wants to kill the writing-mode property. It's such a stupid, stupid idea. And nobody gets it, because nobody understands that this ignorantly-designed shorthand for the switch people want also screws up bidi
# [13:25] <TabAtkins__> anne5: I don't think we necessarily have to do that. They'll find some way to do it. We give them vertical text and they'll play with it.
# [13:25] * anne5 wonders why ChrisL was laughing
# [13:25] <TabAtkins__> howcome: It's such a cheap and easy switch though.
# [13:26] <TabAtkins__> anne5: But still, every feature has a cost.
# [13:26] <TabAtkins__> jdaggett: [shows off another japanese website]
# [13:26] <TabAtkins__> fantasai: In a case like this your design would be completely different.
# [13:26] <TabAtkins__> arronei: Which goes back to alternate stylesheets.
# [13:27] <TabAtkins__> szilles: So it seems like what we're discussing betweeen is alternate stylesheets vs alternate stylesheets + maybe some support for automatically handling both.
# [13:27] <TabAtkins__> szilles: ON another dimension, there's the question of how to select thee alternate stylesheet.
# [13:28] <Bert> (I think I'm very close to Anne's view, but I have the impression that vertical-capability is close to the edge: is it as important as width in MQ, or is it not?)
# [13:28] <TabAtkins__> howcome: One downside of the alternate stylesheet is you can't do it in the <style> element.
# [13:28] <TabAtkins__> anne5: You can with a @title on <style>.
# [13:29] <TabAtkins__> howcome: In which case we could also see people building a naming convention for vertical.
# [13:29] <fantasai> you can define specific class names and have the mode switches depend on those class names
# [13:29] <TabAtkins__> howcome: Do we think we could make that proposal?
# [13:29] <TabAtkins__> anne5: I think the use-case isn't that strong.
# [13:30] <TabAtkins__> howcome: There's a few thousand years of vertical-text in the east.
# [13:30] <TabAtkins__> anne5: But there's not a few thousand years of the direction-switcher button.
# [13:31] <TabAtkins__> jdaggett: I think I'd say that some of the use-cases of epub can be handled within epub itself. There are also a whole set of vertical-text features that are being overshadowed by these epub features.
# [13:32] <TabAtkins__> fantasai: Right, epub can decide the convention for deciding between stylesheets.
# [13:32] <TabAtkins__> fantasai: The problem we need to solve here is the fallback issue.
# [13:32] * gsnedders gets tired of nodding agreeing with fantasai, but still agrees
# [13:32] * Quits: ChrisL (ChrisL@128.30.52.169) (Ping timeout)
# [13:32] <TabAtkins__> fantasai: A lot of the new layout things we're doing - vertical, flexbox, template, maybe multicol - completely break the page if they're not supported.
# [13:33] <TabAtkins__> fantasai: We need a way to detect support for that.
# [13:33] <TabAtkins__> howcome: We can do that in MQ. We don't want to put in all the properties, but we can detect properties of the environment in terms of support.
# [13:34] <TabAtkins__> jdaggett: That doesn't solve the default problem, though. Which one to use automatically.
# [13:34] * Joins: ChrisL (ChrisL@128.30.52.169)
# [13:34] <TabAtkins__> szilles: I'd like to hear consensus that we do need an alternate stylesheet mechanism.
# [13:35] <TabAtkins__> howcome: We have that, but we need a convention on how to use it.
# [13:35] <TabAtkins__> fantasai: Or not even quite that - epub has the ability to do some of that specially. What we want is some recommendation that, if you offer these config knobs to the user that need different stylesheets, this is the way to do it.
# [13:37] <fantasai> fantasai: so that if you want a orizontal-vertical switch, or a high-contrast:low-contrast switch, or a big-text:little-text switch that's standardized, this is how you hook your standard set of controls into the alternate stylesheet mechanism
# [13:38] <anne5> (I think the problem with using Media Queries is that they are not for extracting information, which is sort of what you want for UI.)
# [13:39] <anne5> (Though I guess you could evaluate the media queries for the page assuming the preference has either value and see if there's a difference.)
# [13:39] <anne5> (But I think this feature is not needed at all.)
# [13:40] <anne5> (This feature sounds a lot like 'color-index')
# [13:40] <jdaggett> http://lists.w3.org/Archives/Public/www-style/2010Jun/0133.html
# [13:40] <TabAtkins__> TabAtkins___: Do we still need the ability to make a single stylesheet that can handle the page in both horiz and vert?
# [13:41] <TabAtkins__> fantasai: For webpages, generally not. They'll be design-heavy and specialized for one direction. Books can be either way, though.
# [13:41] <TabAtkins__> jdaggett: I disagree. I think that while books *in general* can be either, specific books are usually designed to go a particular way.
# [13:41] <TabAtkins__> fantasai: But they offer switching buttons.
# [13:42] <TabAtkins__> TabAtkins: I think that's just to set the device to using the proper form. It's fobbing off the detection to the user.
# [13:42] <TabAtkins__> fantasai: I dont' want to do market research for the japanese market. They just need to tell us about that.
# [13:43] <TabAtkins__> jdaggett: [brings up another slide, showing mixed uses of different ways to write mixed english/japanese in a single doc]
# [13:44] <TabAtkins__> jdaggett: Frex, you might have in single text some arabic numbers written horizontally in halfwidth or thirdwidth characters, while others are written vertically.
# [13:44] * Quits: Arron (arronei@213.236.208.247) (Ping timeout)
# [13:44] <TabAtkins__> jdaggett: [shows an example of a date, where the year part is written vertically and the month is written horiz with halfwidth numberes.
# [13:45] <TabAtkins__> jdaggett: [shows an exmplae of an article including both a horizontal section and a vertical section together, where the same word "iPad" appears in both sections, in both direction]
# [13:46] <TabAtkins__> jdaggett: shows an example where horizontally-written numbers in horizontal japanese text also use halfwidth characters]
# [13:47] * Joins: Arron (arronei@213.236.208.247)
# [13:48] <TabAtkins__> jdaggett: This points to maybe needing some type of text-transform, from fullwidth to halfwidth or something.
# [13:48] <Arron> Adding to ealier conversation: Using alternate stylesheets there just needs to be some identifier that UAs can map to. If we define those identifiers for some of the common cases then UAs can map their controls to their created alternate stylesheets for horizontal or vertical, etc...
# [13:49] * Quits: karl (karlcow@128.30.54.58) (Quit: Freedom - to walk free and own no superior.)
# [13:49] <TabAtkins__> jdaggett: [shows an example where a short word "iPhone" in vertical text is written vertically with normal characters, while a longer word "i.softbank" is written horizontally and then rotated vertically]
# [13:49] <TabAtkins__> fantasai: We'll have some switches for these types of things.
# [13:50] <TabAtkins__> alexmog: Is "iphone" in full-width characters?
# [13:50] <TabAtkins__> jdaggett: Typically the latin will be in normal codepoints, but we might have a CSS feature to switch it into fullwidth characters.
# [13:50] <TabAtkins__> jdaggett: I wouldn't say that fullwidth characters would probably ever be used in the "layout as normal then rotate the whole span" case.
# [13:52] <TabAtkins__> ChrisL: Important and interesting a11y issue here - if you can write "iphone" in ascii and use CSS-switch it to using the fullwidth characters, you can actually search for it. Good luck searching with fullwidths.
# [13:54] <TabAtkins__> szilles: About the "1GB" part in that example (currently written vertically), would that be a case for writing with halfwidth glyphs so you can write it horizontally?
# [13:54] <TabAtkins__> jdaggett: That's very rare. It's not what's done right now.
# [13:55] <TabAtkins__> fantasai: Without special support for "writing an english word horizontally embedded in a vertical line" you can just use inline-block and set writing-mode as appropriate.
# [13:55] <TabAtkins__> fantasai: Or just an image.
# [13:56] <TabAtkins__> jdaggett: That would screw up the typical japanese way of doing things. We shouldn't do that automatically.
# [13:56] <TabAtkins__> fantasai: How is the "30" (done horizontally) typically done?
# [13:56] <TabAtkins__> jdaggett: You just use two half-width glyphs.
# [13:57] <TabAtkins__> fantasai: We can do that. Wrap that in a span and set some property, and it'll merge them together.
# [13:57] <TabAtkins__> jdaggett: Right, and maybe we could even do that contextually. Just anywhere you find 2 half-width characters together it automatically does it.
# [13:57] <TabAtkins__> Bert: What about, say, a license plate that happens to have 2 consecutive digits? That would screw it up.
# [13:57] <TabAtkins__> jdaggett: Right, it might not work at all times.
# [13:58] <TabAtkins__> fantasai: We'll look into if we can do it contextually, but it may not make css3.
# [13:58] * Joins: karl (karlcow@128.30.54.58)
# [13:58] <TabAtkins__> alexmog: Are there any design programs that do this automatically contextually?
# [13:58] <TabAtkins__> jdaggett: Not sure right now.
# [13:58] <Bert> ('block-flow: tb-only-if-short-enough' with a better name.)
# [13:59] <TabAtkins__> szilles: The inDesign guys were in favor of marking it up.
# [13:59] <TabAtkins__> JohnJansen: I think there's a way to hit 80% here and then allow an override.
# [13:59] <TabAtkins__> jdaggett: [shows a magazine page where many different sections have different modes]
# [14:00] * Parts: howcome (howcome@213.236.208.247)
# [14:00] <TabAtkins__> szilles: Body text is often vertical, while callouts and captions are often horizontal.
# [14:02] <TabAtkins__> jdaggett: My point is that I think this kind of vertical text layout leads a lot to grid.
# [14:02] <TabAtkins__> fantasai: This has nothing to do with grid.
# [14:04] <TabAtkins__> szilles: In general, the directional statement lies with the content today.
# [14:05] <TabAtkins__> fantasai: I think you'd just assign it to different elements. The sidebar is horizontal, etc.
# [14:05] <TabAtkins__> szilles: That presumes I know where the element is going in the template.
# [14:06] <TabAtkins__> TabAtkins: If you have multiple templates, you'll have multiple blocks of styles, so you can assign writing modes appropriately for each.
# [14:07] <TabAtkins__> fantasai: As far as the coarse layout is concerned, this page doesn't give you any more problems in japanese than it does in english.
# [14:07] <TabAtkins__> jdaggett: But if you don't consider japanese cases, you may make assumptions that break things.
# [14:07] <TabAtkins__> fantasai: [something about overflow]
# [14:08] <TabAtkins__> jdaggett: It sounds like you have a bunch of info in notes?
# [14:08] <TabAtkins__> fantasai: Yes, that's why I'm going to write this next month.
# [14:08] <TabAtkins__> howcome: I think from this topic we've kind of decided we don't need these logical directions?
# [14:09] <TabAtkins__> fantasai: We didn't decide that. We'll be investigating that in TPAC with the i18n WG.
# [14:09] <TabAtkins__> howcome: I'd like to record that, then, and also record that we think that alternate stylesheets are a good way to go.
# [14:10] <TabAtkins__> fantasai: Agreed.
# [14:10] <TabAtkins__> szilles: What are the weaknesses of alternate stylesheets? Duplication of info?
# [14:11] <TabAtkins__> jdaggett: I think I'm done. Is there anything else to say?
# [14:11] <TabAtkins__> szilles: I think that maybe the logical may make more sense for bidi than for vertical.
# [14:13] <TabAtkins__> howcome: I just think that adding duplicate sets of properties is a big pain.
# [14:14] <TabAtkins__> howcome: And it won't end. You may want margins dependent on whether it's a left or right page, for example.
# [14:16] <TabAtkins__> [discussion about the conflict between margin-start and margin-left, frex]
# [14:16] <fantasai> anne: you decide after parsing
# [14:16] <TabAtkins__> [and about which one gets used, when you can determine that, and how much data you have to carry around]
# [14:17] <TabAtkins__> anne5: When you start laying out the element, you know the writing-mode computed values.
# [14:17] <fantasai> dbaron points to http://fantasai.inkedblade.net/style/discuss/directions/box-switch which has one value always take precedence
# [14:17] <TabAtkins__> dbaron: At computation, not layout.
# [14:17] <fantasai> Alex: The margin-outside example is much more complicated
# [14:17] <fantasai> Alex: You can only resolve this during layout
# [14:17] <TabAtkins__> howcome: You still have to double-book and carry both around.
# [14:18] <fantasai> Alex: So you must have a separate storagae value for margin-outside
# [14:18] <fantasai> Values are easier to deal with
# [14:18] <TabAtkins__> howcome: And then there's all sorts of other properties, float and clear and caption-side and background.
# [14:19] <TabAtkins__> howcome: And what about the top/bottom/left/right properties? Do we need start: and end: and out:?
# [14:19] <TabAtkins__> fantasai: There are two different proposals that have been decently fleshed out for how to cascade these.
# [14:19] <TabAtkins__> fantasai: One by me, one by dbaron.
# [14:20] <TabAtkins__> fantasai: But I don't think that either work for margin-outside.
# [14:20] <TabAtkins__> fantasai: Becuase you don't know what page it'll be on, and thus which margin -outside maps to, until layout time.
# [14:20] <fantasai> Alex: You need six real values and 10 virtual values
# [14:21] <TabAtkins__> anne5: Do you need this for vertical?
# [14:21] <TabAtkins__> fantasai: It would be helpful, for example to make lists with gutters for the bullets.
# [14:21] <fantasai> Alex: left/right/etc an map at cascade time, outside/inside would have to map at layout time
# [14:22] <TabAtkins__> jdaggett: The key point is simplifying things. It makes it simpler because you have to write less properties, but it's not strictly necessary; you can do it other ways.
# [14:22] <TabAtkins__> jdaggett: To me it's not just the number of core properties that need to be added, it's the number of other modules that have to make it work.
# [14:22] <TabAtkins__> jdaggett: Like border-radius now needs border-radius-startbefore.
# [14:23] <TabAtkins__> howcome: That hurts. But what about lists? Does the :ltr and :rtl work for that?
# [14:23] <TabAtkins__> fantasai: Yeah, that should solve it.
# [14:24] <TabAtkins__> anne5: And what about switching the meaning of physical properties?
# [14:24] <TabAtkins__> fantasai: No. But we need to discuss it so I have a good answer when I talk about it later for why we're not doing it.
# [14:26] <TabAtkins__> TabAtkins: It sounds barely reasonable for vertical text because you're rotating, but it makes no sense with rtl languages where ti mirrors, and margin-right becomes left and margin-left becomes right.
# [14:31] <dsinger> dave suggests (a) that we find examples that contain horizontal text and make sure the examples work with vertical text and (b) find occurrences of direction-sensitive words in our specs (top, left, bottom, right, above, below) and check that we mean that physical direction (we saw an example yesterday which started direction-agnostic and then went on assuming LR text)
# [14:31] <TabAtkins__> alexmog: Idea for specifying multiple new direction values without producing new properties.
# [14:33] <TabAtkins__> alexmog: "margin:out(10px); margin:before(20px);" overriding whatever direction the out or before directions would be.
# [14:34] * Quits: jdaggett (jdaggett@213.236.208.247) (No route to host)
# [14:34] * Quits: dsinger (dsinger@213.236.208.247) (Connection reset by peer)
# [14:34] * Quits: tantek (tantek@213.236.208.247) (Connection reset by peer)
# [14:34] * Quits: glazou (glazou@213.236.208.247) (Connection reset by peer)
# [14:34] * Quits: CesarAcebal (acebal@213.236.208.247) (Connection reset by peer)
# [14:34] * Joins: dsinger (dsinger@213.236.208.247)
# [14:34] * Joins: CesarAcebal (acebal@213.236.208.247)
# [14:34] * Joins: tantek (tantek@213.236.208.247)
# [14:34] * Joins: jdaggett (jdaggett@213.236.208.247)
# [14:34] * Joins: glazou (glazou@213.236.208.247)
# [14:35] * Joins: TabAtkins_ (chatzilla@213.236.208.247)
# [14:35] * Quits: JohnJansen (qw3birc@128.30.52.28) (Quit: Page closed)
# [14:35] * Joins: JohnJansen (qw3birc@128.30.52.28)
# [14:36] <TabAtkins_> ACTION Alex: Send proposal on "margin:out(10px);" and similar to the list for discussion.
# [14:36] * trackbot noticed an ACTION. Trying to create it.
# [14:36] * RRSAgent records action 9
# [14:36] <trackbot> Created ACTION-263 - Send proposal on "margin:out(10px);" and similar to the list for discussion. [on Alex Mogilevsky - due 2010-09-01].
# [14:36] * Quits: TabAtkins__ (chatzilla@213.236.208.247) (No route to host)
# [14:36] <TabAtkins_> RESOLVED: Physical directions stay physical - margin-left will always refer to the left side, not the top or right side based on physical direction.
# [14:37] <fantasai> Tab: I have a patch pending in WebKit to support 4-digit hex format
# [14:37] <fantasai> Tab: A lot of designers use hex format, it's a pain to switch to rgba when we want to add opacity
# [14:37] <fantasai> dbaron: In HTML, hex parsing is fixed up. but not in CSS
# [14:38] <fantasai> Tab: The patch is mainly just pending me putting this into a spec draft
# [14:39] * Quits: Ms2ger (Ms2ger@91.181.99.238) (Ping timeout)
# [14:39] * Quits: ChrisL (ChrisL@128.30.52.169) (Ping timeout)
# [14:39] <fantasai> Tantek: I don't want to add this to css3-color
# [14:39] <fantasai> Tab: No, I want to add to css4-color
# [14:40] <fantasai> Tab: Other question is whether serialization tests should go into css3-color testsuite
# [14:40] <fantasai> Anne: CSS4 Color spec should define the OM data type
# [14:41] <fantasai> RESOLVED: Add #rrggbbaa to css4-color
# [14:42] <fantasai> Bert: I'm against adding new features.
# [14:42] <fantasai> Bert: I'm against CSS4.
# [14:43] <fantasai> ChrisL: Then you shouldn't be on this committee
# [14:44] <fantasai> Bert objects to adding #rrggbbaa.
# [14:44] <fantasai> All others in favor
# [14:44] <fantasai> glazou: Raise a formal objection if you want. Change the chair. I don't care.
# [14:45] <fantasai> dsinger says something about sending things to the mail list
# [14:45] <tantek> http://w3.org/tr/css3-ui
# [14:45] <fantasai> Topic: CSS3 UI
# [14:45] <TabAtkins_> tantek: It's been 6 years since we had UI CR.
# [14:45] <dsinger> (said) if there is an objection, tell the list what problem you see in case I (or others) have missed something, that's all
# [14:45] <TabAtkins_> tantek: A large number of these features have been implemented, but not everything.
# [14:46] <TabAtkins_> tantek: Some was at risk, but some of the non-implemented stuff wasn't marked as at risk.
# [14:46] <TabAtkins_> tantek: And some just weren't implemented the way the spec says; maybe we dont' want those anymore.
# [14:46] <TabAtkins_> tantek: So I propose that anything that hasn't been mplemented by at least two impls should be dropped.
# [14:46] <TabAtkins_> tantek: Add a couple of things that have been implmented and belong here, like pointer-events and overflow-x/y.
# [14:47] <TabAtkins_> anne5: You want to move overflow to this module?
# [14:47] <TabAtkins_> tantek: It was there originally, but it got moved to Box. Since then we've just backported overflow fixes to 2.1.
# [14:48] <TabAtkins_> glazou: Tantek, you seem to be dropping a long list of features. Do you think anything will soon be implemented?
# [14:48] <TabAtkins_> tantek: It's been 6 years. I don't have much hope for a rapid implementation.
# [14:48] <TabAtkins_> anne5: "appearance" has been implemented in at least two browsers.
# [14:48] <TabAtkins_> tantek: Yes, but not the way the spec has it. It's basically a different feature with the same name. So it's not for UI3.
# [14:48] <anne5> (I actually thought it was implemented somewhat like the spec, but then I never fully understood the spec)
# [14:49] <TabAtkins_> tantek: So my plan is to chop it down, short LC, short CR, then to PR.
# [14:49] <TabAtkins_> tantek: Gist of things I want to add to UI4 is -
# [14:49] <TabAtkins_> tantek: HTML5 has introduced a bunch of new form UI.
# [14:49] <TabAtkins_> tantek: For example, a placeholder can be put into form elements.
# [14:49] <TabAtkins_> tantek: Authors want the ability to style that placeholder.
# [14:49] <TabAtkins_> tantek: In Moz we had enough requests that we implemented in prefixed.
# [14:50] <TabAtkins_> tantek: So, analyze HTML5's new form stuff, see which parts need to be ported back to CSS.
# [14:50] <TabAtkins_> jdaggett: What about these "system font values".
# [14:51] <TabAtkins_> dbaron: They're in 2.1, actually. Not the entire list, but a lot of them.
# [14:51] * Joins: ChrisL (ChrisL@128.30.52.169)
# [14:51] <TabAtkins_> tantek: So that's the plan there - see if any of the further values have been implemented. If so, great; if not, drop them.
# [14:52] <TabAtkins_> anne5: I'd like to see those fonts things moved to the Fonts module.
# [14:52] <anne5> especially since defining 'font' in two separate modules is just a bit too much, imo
# [14:53] <TabAtkins_> tantek: These keywords are defined in terms of UI features.
# [14:53] <TabAtkins_> [discussion about the keywords being very windows-based]
# [14:53] <TabAtkins_> jdaggett: tantek, will you be counting prefixed properties as "implementations"?
# [14:53] <TabAtkins_> tantek: If they're implemented the same way they're specified, that's just the impl being conservative, so yes.
# [14:55] <TabAtkins_> fantasai: I suggest putting the selectors in a separate draft "Selectors UI", so other specs like the QuerySelector API can reference just that.
# [14:56] <TabAtkins_> tantek: I wouldn't have a problem with doing that for *new* selectors, but I want to keep the current selectors in UI and just move it through. Doing otherwise seems like unnecessary editorial work.
# [14:56] <fantasai> arron: You can't publish css3-ui until the new charter
# [14:56] <fantasai> fantasai: But if you pull out the selectors and publish them separately, you can publish that now
# [14:57] <fantasai> fantasai: because selectors fall under our current charter
# [14:57] <fantasai> Tantek: I'll consider that.
# [14:57] <TabAtkins_> tantek: Also, could implementors tell me what properties from UI they claim to have implemented, so I can just trust that? 3 weeks deadline.
# [14:57] <fantasai> fantasai: Splitting out a draft doesn't take long. I can do that kind of thing it in one or two hours.
# [14:58] <TabAtkins_> ACTION Daniel: At next telcon, remind people about Tantek's request for impl claims for UI stuff.
# [14:58] * trackbot noticed an ACTION. Trying to create it.
# [14:58] * RRSAgent records action 10
# [14:58] <trackbot> Created ACTION-264 - At next telcon, remind people about Tantek's request for impl claims for UI stuff. [on Daniel Glazman - due 2010-09-01].
# [14:59] * Quits: glazou (glazou@213.236.208.247) (Quit: glazou)
# [15:00] * Quits: jdaggett (jdaggett@213.236.208.247) (Quit: jdaggett)
# [15:01] * Quits: dsinger (dsinger@213.236.208.247) (Quit: dsinger)
# [15:02] * Quits: tantek (tantek@213.236.208.247) (Quit: tantek)
# [15:19] * Quits: anne5 (annevk@213.236.208.247) (Quit: anne5)
# [15:31] * Quits: ChrisL (ChrisL@128.30.52.169) (Ping timeout)
# [15:36] * Quits: Arron (arronei@213.236.208.247) (Ping timeout)
# [15:36] * Joins: Arron (arronei@213.236.208.247)
# [15:50] * Joins: sylvaing (sylvaing@76.104.131.10)
# [15:59] * Joins: bart (chatzilla@83.163.136.98)
# [16:05] * Joins: jdaggett (jdaggett@213.236.208.247)
# [16:08] * Joins: anne5 (annevk@213.236.208.247)
# [16:09] * Joins: Curt` (DorkeyDear@75.10.129.150)
# [16:09] * Joins: glazou (glazou@213.236.208.247)
# [16:11] * Quits: JohnJansen (qw3birc@128.30.52.28) (Ping timeout)
# [16:12] * Quits: glazou (glazou@213.236.208.247) (Ping timeout)
# [16:12] * Quits: anne5 (annevk@213.236.208.247) (Ping timeout)
# [16:12] * Quits: Doofl (mstensho@213.236.208.247) (Ping timeout)
# [16:12] * Quits: szilles (chatzilla@213.236.208.247) (Ping timeout)
# [16:12] * Quits: futhark (rune@213.236.208.22) (Ping timeout)
# [16:12] * Quits: lstorset (lstorset@213.236.208.22) (Ping timeout)
# [16:12] * Quits: jdaggett (jdaggett@213.236.208.247) (Ping timeout)
# [16:12] * Quits: Lachy (Lachlan@213.236.208.22) (Ping timeout)
# [16:12] * Quits: alexmog (alexmog@213.236.208.247) (Ping timeout)
# [16:13] * Quits: CesarAcebal (acebal@213.236.208.247) (Ping timeout)
# [16:13] * Quits: TabAtkins_ (chatzilla@213.236.208.247) (Ping timeout)
# [16:13] * Quits: dbaron (dbaron@213.236.208.247) (Ping timeout)
# [16:13] * Quits: oyvind (oyvinds@213.236.208.22) (Ping timeout)
# [16:13] * Quits: Arron (arronei@213.236.208.247) (Ping timeout)
# [16:13] * Quits: kubala (Kuba@195.116.30.193) (Ping timeout)
# [16:13] * Joins: jdaggett (jdaggett@213.236.208.247)
# [16:14] * Joins: Arron (arronei@213.236.208.247)
# [16:14] * Joins: glazou (glazou@213.236.208.247)
# [16:14] * Joins: dsinger (dsinger@213.236.208.247)
# [16:14] * Joins: futhark (rune@213.236.208.22)
# [16:14] * Joins: TabAtkins_ (chatzilla@213.236.208.247)
# [16:14] * Joins: anne5 (annevk@213.236.208.247)
# [16:14] * Joins: CesarAcebal (acebal@213.236.208.247)
# [16:14] * Joins: Doofl (mstensho@213.236.208.247)
# [16:14] * Joins: dbaron (dbaron@213.236.208.247)
# [16:15] * Joins: alexmog (alexmog@213.236.208.247)
# [16:15] * Joins: tantek (tantek@213.236.208.247)
# [16:15] <jdaggett> http://people.mozilla.org/~jdaggett/webfontsfuture.pdf
# [16:15] * Joins: kubal (Kuba@195.116.30.193)
# [16:16] * Joins: szilles (chatzilla@213.236.208.247)
# [16:17] <TabAtkins_> johnjansen: I wanted to get a date for when impl reports could be available.
# [16:18] * Quits: tantek (tantek@213.236.208.247) (Quit: tantek)
# [16:18] <TabAtkins_> johnjansen: I also made an assumption that impl reports should always be on the w3c site, but that appears to be incorrect. I'd like an affirmation that we will post them publicly.
# [16:18] <sylvaing> Zakim, code
# [16:18] <Zakim> I don't understand 'code', sylvaing
# [16:18] <TabAtkins_> glazou: You said that to run the test against an impl takes 2-3 days.
# [16:18] <TabAtkins_> johnjansen: Yes.
# [16:18] <TabAtkins_> glazou: We may find a few bugs while running the tests, so we can probably dedicate a month for that.
# [16:19] <TabAtkins_> dbaron: I think that 1 month after test-suite completion sounds fine, especially if we can write it that way.
# [16:19] * Joins: ChrisL (ChrisL@128.30.52.169)
# [16:19] <sylvaing> Zakim, code ?
# [16:19] <Zakim> sorry, sylvaing, I don't know what conference this is
# [16:19] * sylvaing no bridge today ?
# [16:19] <ChrisL> zakim, room for 2?
# [16:19] <Zakim> ok, ChrisL; conference Team_(css)14:17Z scheduled with code 26632 (CONF2) for 60 minutes until 1517Z
# [16:20] <glazou> hold on sylvaing
# [16:20] <ChrisL> sylvaing, we now have a temp bridge, or could use skype also
# [16:20] <TabAtkins_> fantasai: I want to reiterate that the test suite is basically complete. some fixes may need to be made, but we always give notice of that, so if you want to start impl reports now you won't be wasting your time.
# [16:20] <fantasai> specifically, I list all tests that have substantively changed (and would therefore need to be rerun)
# [16:21] <glazou> sylvaing: can you call nattokirai through Skype ?
# [16:22] <sylvaing> glazou, will follow on IRC then. no worries. thanks !
# [16:23] * fantasai notes that sylvaing has a very nice microphone for you that Tab says is better than the polycom landline here
# [16:23] * fantasai sylvaing-> jdaggett
# [16:23] <TabAtkins_> szilles: One of the problems with fonts in CSS is that it would be nice if there was a way to take a font-family name and finding the font that would work for it on all platforms.
# [16:24] <TabAtkins_> szilles: The problem is that there isn't an easy way to do that.
# [16:24] * Joins: dsinger_ (dsinger@213.236.208.247)
# [16:24] * Quits: dsinger (dsinger@213.236.208.247) (Connection reset by peer)
# [16:24] * Quits: CesarAcebal (acebal@213.236.208.247) (Connection reset by peer)
# [16:24] * Joins: CesarAcebal (acebal@213.236.208.247)
# [16:24] * dsinger_ is now known as dsinger
# [16:24] * Quits: jdaggett (jdaggett@213.236.208.247) (No route to host)
# [16:24] * Joins: jdaggett (jdaggett@213.236.208.247)
# [16:25] * sylvaing that's right ! John does have the awesome speaker system. then it's worth re-installing Skype. brb.
# [16:25] * Quits: TabAtkins_ (chatzilla@213.236.208.247) (No route to host)
# [16:25] * Joins: TabAtkins_ (chatzilla@213.236.208.247)
# [16:26] <TabAtkins_> jdaggett: The underlying problem is that th eoriginal truetype spec has a bifurcation. the font-family name can be different on mac and windows.
# [16:26] <TabAtkins_> jdaggett: Then along the way there were questions.
# [16:26] <TabAtkins_> jdaggett: One was what to do with old applications that only have a bold and italic variation.
# [16:26] <szilles> Jdaggett: In the TrueType spec, at least two font family names are allowed, one for the Mac Platform and one for the Windows platform
# [16:26] * Quits: dbaron (dbaron@213.236.208.247) (Ping timeout)
# [16:26] * Joins: dbaron (dbaron@213.236.208.247)
# [16:26] <TabAtkins_> jdaggett: So one solution was to create a new, separate name for Windows that would denote the larger family.
# [16:27] <TabAtkins_> jdaggett: So you have one font-family that's the basic level, another more general one.
# [16:27] <TabAtkins_> jdaggett: Then they looked at CSS and saw the font-selection model.
# [16:27] * Quits: ChrisL (ChrisL@128.30.52.169) (Ping timeout)
# [16:27] <szilles> Microsoft and Adobe agreed on a name that covers a wider set of variations than the orignal Windows font family name covered
# [16:27] <TabAtkins_> jdaggett: If you put in things that can't be defineed by -weight, -style, -stretch (Adobe has faces for optical sizing, frex), there's no way to select it.
# [16:27] <TabAtkins_> jdaggett: So they came up with a third name.
# [16:28] <TabAtkins_> jdaggett: So as it stands, there are 3 names defined for windows, and 1 defined for mac.
# [16:28] <TabAtkins_> jdaggett: So when you say "I want font xxx", what should be given to it?
# [16:28] * Quits: Curt` (DorkeyDear@75.10.129.150) (Connection reset by peer)
# [16:28] * Joins: Curt` (DorkeyDear@75.10.129.150)
# [16:28] <szilles> This means that there are three names defined for Windows and an additional one for the Mac
# [16:28] <TabAtkins_> jdaggett: For most fonts it's okay, but for adobe fonts there's a problem. It's understandable, but the font-family that a user is seeing is system-dependent.
# [16:28] <TabAtkins_> jdaggett: So it's not a problem of CSS doing the wrong thing, it's the OS displaying a different family name for the exact same font-file.
# [16:29] <TabAtkins_> jdaggett: So unless you can get Apple to agree to look at those names, there's nothing we can say.
# [16:29] * Joins: oyvind (oyvinds@213.236.208.22)
# [16:29] <TabAtkins_> jdaggett: I think it's fundamentally wrong to say that you should select fonts based on a name the user isn't seeing.
# [16:29] <TabAtkins_> jdaggett: If I go to Fontbook on my mac, I should be able to write a document using that name.
# [16:29] * Joins: lstorset (lstorset@89.9.85.246)
# [16:30] <TabAtkins_> jdaggett: For 99% of cases, this isn't an issue. Our model is sufficient. It's only for designers building large families that we need a higher selection model.
# [16:30] <TabAtkins_> jdaggett: Adobe suggested using the WWS name, but that's a windows-only name, which is weird.
# [16:30] * Joins: ChrisL (ChrisL@128.30.52.169)
# [16:31] <TabAtkins_> jdaggett: One way to solve it woudl be to say that if a family has more faces than the CSS model can represent, you can select it by the specific WWS name.
# [16:31] <TabAtkins_> jdaggett: But I think the fundamental answer has to come from apple.
# [16:31] <TabAtkins_> dsinger: We're only using one name!
# [16:31] * sylvaing the sound of this thing is ridiculously good
# [16:31] <TabAtkins_> jdaggett: Right; the original problem was just solved by applee in a different way.
# [16:32] <ChrisL> but the apple name is not exposed through windows api's
# [16:33] <TabAtkins_> jdaggett: At Moz we're going to bring in the TypeFont manager or whatever at Apple and we're going to try and figure out something.
# [16:33] <TabAtkins_> szilles: I just wanted to make sure we recorded the nature of the problem and encouraged solutions.
# [16:33] <TabAtkins_> jdaggett: I think the proposed solution isn't bad, but fonts have a fundamental incongruity outside our jurisdiction that makes this a sticky problem.
# [16:35] <TabAtkins_> [does this issue affect webfonts?]
# [16:35] <TabAtkins_> jdaggett: No, because @font-face doesn't care about the font face.
# [16:35] <TabAtkins_> s/font face/family name/
# [16:35] <TabAtkins_> glazou: Next topic, ::selection.
# [16:36] <glazou> http://lists.w3.org/Archives/Public/www-style/2010May/0275.html
# [16:36] <ChrisL> s/about the font face/about the name in the name table, only the name in @font-face/
# [16:36] <TabAtkins_> howcome: This was pulled out of the Selectors spec, so it's not in any working draft now.
# [16:37] <TabAtkins_> glazou: No, but we have partial impls, though not really interop.
# [16:37] <TabAtkins_> glazou: Some visually impaired users rely on it because it lets you set the colors and background of the selection.
# [16:37] <dbaron> http://lists.w3.org/Archives/Public/www-style/2008Oct/0268.html
# [16:37] <TabAtkins_> howcome: What draft would it be in?
# [16:37] <TabAtkins_> glazou: Either Selectors 4, or UI 4.
# [16:38] <TabAtkins_> dbaron: Last time wee discussed this I brought up a summary of these issues (above url).
# [16:38] <TabAtkins_> dbaron: I brought up five requirements, and I'd like to know, for any proposal, which requirements it breaks.
# [16:38] <TabAtkins_> dbaron: the first one is that the appearance of a piece of text when it's selected shouldn't depend on the root container of the selection (nearest common ancestor of the endpoints).
# [16:39] <TabAtkins_> dbaron: So you shouldn't get into a situation where extending it by a few characters shouldn't change the whole thing.
# [16:39] <TabAtkins_> glazou: Sounds reasonable form a user perspective.
# [16:39] <TabAtkins_> dbaron: Second is that the default selection style should be representable in pure CSS.
# [16:39] <TabAtkins_> dbaron: Third is that author styles should override system styles.
# [16:40] <TabAtkins_> dbaron: Four is that the background and foreground color of the selection should always override the back/foreground of the unselected text.
# [16:40] <TabAtkins_> dbaron: So you don't want to get into a situation where an inline with a backgorund shows its background, not the selection background.
# [16:41] <TabAtkins_> dbaron: And Five is that selection style should be settable per element.
# [16:41] <TabAtkins_> dbaron: In the previous discussion, the models we discussed didn't meet these requirements.
# [16:41] * Joins: JohnJansen (qw3birc@128.30.52.28)
# [16:41] <TabAtkins_> dbaron: So I want to be careful that if we violate these requirements we do so knowingly. I'm hesitant to break them.
# [16:41] <TabAtkins_> sylvaing: #4, does that mess with specificity rules?
# [16:42] <TabAtkins_> dbaron: Not necessarily - it's a pseudoelem so we can do what we want.
# [16:42] * gsnedders notes the last time stuff went down was the entire office losing internet access, not just us, so maybe not the coffee machine
# [16:42] * Quits: lstorset (lstorset@89.9.85.246) (Ping timeout)
# [16:42] <TabAtkins_> glazou: And the fifth rule implies you have some sort of hierarchical inheritance of ::selection.
# [16:42] <TabAtkins_> dbaron: We should probably go back and look at francois' message so we can better understand these.
# [16:43] <TabAtkins_> dbaron: Though possibly this is best done on-list.
# [16:44] <TabAtkins_> glazou: I think using these requirements is pretty trivial to create an algorithm.
# [16:44] <TabAtkins_> dbaron: Yeah, I was able to create three possibilities that did so (one maybe failed #5), but they were all somewhat messy.
# [16:45] <TabAtkins_> dbaron: In one, *::selection is handled badly. I describe it in the message.
# [16:45] <TabAtkins_> dbaron: Because it makes *::selection override elem::selection in descendants of the elem.
# [16:45] <TabAtkins_> dbaron: Maybe it's not that bad; it just makes you represent the system default as :root::selection
# [16:46] <TabAtkins_> glazou: I'm not sure it's a bug. Sounds like a feature.
# [16:46] * Quits: alexmog (alexmog@213.236.208.247) (Quit: alexmog)
# [16:46] <TabAtkins_> TabAtkins: Yeah, as long as we have a way around it, this doesn't sound too bad. An author probably won't do *::selection itself.
# [16:47] <TabAtkins_> dbaron: But there may be existing content using that.
# [16:47] <TabAtkins_> dbaron: B & C both introduce a new cascade concept for ::selection.
# [16:48] <TabAtkins_> dbaron: I'm sorta coming from an unusual perspective, though, since I'm from the only vendor who's implemented it with a prefix.
# [16:49] <TabAtkins_> glazou: Sounds like most people either haven't read the message or read it too long ago, so it's not worthwhile to talk now.
# [16:49] <TabAtkins_> glazou: But we all know about and agree on the five requirements. We know what we want, if not how to implement it.
# [16:50] <TabAtkins_> glazou: I suggest, since we wont' have to discuss 2.1 issues on the conf calls, let's give some time to study existing impls.
# [16:50] * Joins: miketaylr (miketaylr@38.117.156.163)
# [16:50] <TabAtkins_> dsinger: If we could take existing impls and check how well they match the five requirements would be useful.
# [16:50] <TabAtkins_> glazou: Yes.
# [16:51] <TabAtkins_> rune: I implemented ::selection in Opera.
# [16:51] <TabAtkins_> howcome: Opinions on where we shoudl go with this?
# [16:51] <TabAtkins_> rune: Nothing yet, but I can give some thoughts based on our impl.
# [16:51] <TabAtkins_> rune: It's implemented using synthesized selection color and bgcolor, which are the only two properties we support.
# [16:52] <TabAtkins_> rune: Those two properties are inherited by default.
# [16:52] <TabAtkins_> glazou: From selection to selection?
# [16:52] <TabAtkins_> dbaron: You're saying you treat the pseudoelem as two virtual properties?
# [16:52] <TabAtkins_> rune: Yeah.
# [16:53] <TabAtkins_> dbaron: It sounds like what you do is basically similar to my proposal A, or possibly more like B.
# [16:53] <TabAtkins_> rune: I don't directly remember what we did with inheritance.
# [16:53] <glazou> sylvaing: can you hear well ?
# [16:53] <TabAtkins_> rune: Whether we inherit from the real color property, or...
# [16:53] <TabAtkins_> dbaron: I think I don't much care what explicit inheritance does, and we should just define what works for this.
# [16:54] <TabAtkins_> dbaron: Let me restate and see if you agree.
# [16:54] * sylvaing glazou, yes, it's ridiculously good even when people are far away it's very clear
# [16:54] <TabAtkins_> dbaron: Basically you take any selector with ::selection, and treat it like that selector minus the ::selection, find the color and background properties and map them to an additional pair of hidden properties.
# [16:54] * sylvaing ...and i heard you ask from the other room
# [16:55] <TabAtkins_> dbaron: Then you cascade those as normal, and use the hidden properties for things inside the selection.
# [16:56] * jdaggett sylvaing: http://www.amazon.com/Communicator-Grey-C100S-Speakerphone-Skype/dp/B000GG0EFY/ref=sr_1_3?ie=UTF8&s=electronics&qid=1282747958&sr=8-3
# [16:56] * Joins: glazou_ (glazou@213.236.208.247)
# [16:56] <TabAtkins_> rune: We're not mixing colors - if you have two partially transparent colors we just paint the selection color, not the composited version.
# [16:56] * Quits: glazou (glazou@213.236.208.247) (Ping timeout)
# [16:56] <TabAtkins_> rune: But maybe we could change that.
# [16:56] <TabAtkins_> dbaron: We should probably do more research here.
# [16:57] <glazou_> http://lists.w3.org/Archives/Public/www-style/2010May/0328.html
# [16:59] <fantasai> http://lists.w3.org/Archives/Public/www-style/2010May/0338.html
# [16:59] <TabAtkins_> TabAtkins: [summarizes the thread]
# [17:00] <TabAtkins_> dbaron: Getting this right would require a lot of work to define how things map well.
# [17:00] <TabAtkins_> dbaron: Actually doing it in an impl would be easy; the hard part is writing the spec for it in a sufficiently detailed manner.
# [17:01] * fantasai agrees with Aryeh and dbaron
# [17:01] <TabAtkins_> dbaron: So if someone brought us a table of language->liststyle mappings and the i18n group approved it, I'd do it. But I don't think it's particularly worthwhile for the group itself to work on it.
# [17:02] <TabAtkins_> szilles: Maybe we should ask the i18n group to prepare the table for us.
# [17:02] <TabAtkins_> fantasai: They have way more important things to work on.
# [17:03] <TabAtkins_> szilles: One comment - the w3c has comments at a top level that it's hard to use its specs in various countries.
# [17:03] <TabAtkins_> szilles: Which we're interested in having happen.
# [17:03] <TabAtkins_> szilles: So maybe I agree that it shoudln't be asked of the i18n group, but I want to record it as something we might want.
# [17:04] <TabAtkins_> szilles: I might even want a registry rather than a spec for the mapping.
# [17:04] <TabAtkins_> ChrisL: Speaking of that, I have a doc I got from the w3c indic group about the requirments they have for indic languages to be represented properly on the web.
# [17:05] <TabAtkins_> ChrisL: Some of this is just browser bugs, but there's also useful things for us to look at.
# [17:05] <TabAtkins_> ChrisL: First thing - ::first-letter.
# [17:06] <TabAtkins_> ChrisL: You have syllables and sometimes vowels that join onto the first letter, so what is actually the ::first-letter?
# [17:06] <TabAtkins_> fantasai: We discussed this a while ago.
# [17:06] <TabAtkins_> anne5: Can we have that doc?
# [17:06] <TabAtkins_> ChrisL: Not officially yet, but I expect soon.
# [17:07] <TabAtkins_> howcome: Didn't we define this as "grapheme cluster"?
# [17:07] <TabAtkins_> fantasai: CSS3 does, though there's a lot of useful stuff in an informative note because no one wanted to make it normative.
# [17:07] <TabAtkins_> fantasai: One of the big problems was we had no exmaples, so this is really useful and we should thank them.
# [17:08] <TabAtkins_> ChrisL: Now list numbering.
# [17:09] <TabAtkins_> ChrisL: Languages with the same script may use different ordering for bullets.
# [17:09] <TabAtkins_> TabAtkins: Lists3 already allows for that; if there are langauges we have together now that shoudl be separate, we'd love to know.
# [17:10] <TabAtkins_> ChrisL: Underlining!
# [17:10] <TabAtkins_> ChrisL: In some indic scripts you have marks down below that are important to tell what's the information, and the underline can cover that up and make it impossible.
# [17:10] <TabAtkins_> jdaggett: That's controllable by the font - if you're getting overwritten you're using a garbage font.
# [17:11] <TabAtkins_> ChrisL: Okay, so this may just be a browser bug. We can respond and tell them that.
# [17:11] <TabAtkins_> jdaggett: Also, I see a lot of <p> without @lang attributes, so ont selection is totally UA-dependent.
# [17:11] * sylvaing must track down the name of the young indic type designer who presented at typecon on friday
# [17:12] <TabAtkins_> jdaggett: For strikethrough, it's used as an editting mark in English. Is the equivalent editting mark the same there?
# [17:13] <TabAtkins_> ChrisL: So that's the information. I've asked to be able to send this to the list for wider discussion.
# [17:14] <TabAtkins_> ChrisL: And this isn't a one-shot; they want to work with us.
# [17:14] <TabAtkins_> glazou_: Welcome!
# [17:14] <TabAtkins_> glazou_: Next topic, template layout.
# [17:15] * Joins: mollydotcom (mollyh@95.34.118.56)
# [17:15] <TabAtkins_> CesarAcebal: I didn't prepare anything specifically for this.
# [17:15] <TabAtkins_> CesarAcebal: What I'd be interested in, though, is finding out what your opinion is on the state of the module.
# [17:15] <TabAtkins_> CesarAcebal: What's the priority, etc.
# [17:15] <TabAtkins_> CesarAcebal: Or, what do you want to change.
# [17:16] <TabAtkins_> fantasai: Hyatt posted to the list a while ago that it's not possible to prefix anything in the syntax so you can't do an experimental implementation.
# [17:17] * Joins: tantek (tantek@213.236.208.247)
# [17:17] <fantasai> http://lists.w3.org/Archives/Public/www-style/2009Mar/0191.html
# [17:18] <TabAtkins_> fantasai: He had good ideas to solve that and that would also make it easier to find out what is going on in the stylesheet.
# [17:18] <TabAtkins_> jdaggett: What's the relationship between Grid and Template?
# [17:19] <TabAtkins_> TabAtkins: They're complementary, but not directly tied together right now. But I and Alex want to explore options to merge them further.
# [17:19] <TabAtkins_> jdaggett: Any implementations?
# [17:19] <TabAtkins_> Bert: Two javascript implementations, and one in Fedenouik's HTMLayout engine.
# [17:19] * Joins: Lachy (Lachlan@213.236.208.22)
# [17:20] * Joins: alexmog (alexmog@213.236.208.247)
# [17:21] <TabAtkins_> alexmog: MS is interested in grid and other similar layout type things. I'm not prepared right now to give specific promises now, but maybe we can talk more specifically in the future.
# [17:21] <TabAtkins_> howcome: Do we have specific examples of how this would work in use?
# [17:22] <TabAtkins_> TabAtkins: I've spent time exploring how layouts of Facebook pages, CNN, etc. would work with Template and Flexbox.
# [17:22] <TabAtkins_> jdaggett: Could you publish those to the list?
# [17:22] <TabAtkins_> TabAtkins: Yes, and I'll continue doing these types of things for any new ideas.
# [17:23] <TabAtkins_> jdaggett: I think it would make me feel a little better if these things were somewhat combined.
# [17:23] <TabAtkins_> sylvaing: Agreed. It would make it easier to see the value of these.
# [17:23] <TabAtkins_> CesarAcebal: I am convinced that Template Layout makes so many layouts much much simpler than anything that currently exists.
# [17:24] <TabAtkins_> Bert: There are some examples in the spec and in Cesar's thesis with Andy Clark doing experiments with it.
# [17:24] <TabAtkins_> CesarAcebal: My thesis PDF was posted to the list.
# [17:25] <TabAtkins_> CesarAcebal: As a personal opinion, a summary, I think the major difference preferring Template over current layout mechanism is that is allows us to define the layout of the whole page in an explicit way.
# [17:25] <TabAtkins_> CesarAcebal: Currently we lay out pages by saying that this element floats, this element positions like this, etc. The final layout is only known after all the interactions.
# [17:25] <TabAtkins_> CesarAcebal: Template Layout, you just say "I want two columns" and then you put elements in there.
# [17:26] * Quits: Arron (arronei@213.236.208.247) (Ping timeout)
# [17:26] <TabAtkins_> CesarAcebal: I also believe that with Template Layout it would be very easy to have gui tools to work with CSS layouts.
# [17:26] * Joins: Arron (arronei@213.236.208.247)
# [17:27] <TabAtkins_> CesarAcebal: When you show a designer the prototype, they always say "Woah, when is this going to be on the internet?".
# [17:27] <TabAtkins_> fantasai: I posted in the room the url to Hyatt's proposal to make it easier. If people agree, we can resolve this.
# [17:28] <TabAtkins_> [general agreement with it]
# [17:28] <dbaron> dbaron: You can still do an experiment with the extra property even if it's not in the draft.
# [17:28] <dbaron> Bert (before dbaron): I don't want an extra property
# [17:29] <TabAtkins_> Bert: I'm not in favor of the new property it introduces.
# [17:30] <TabAtkins_> glazou_: Hyatt said that it *cannot* be implemented as written because you can't introduce a prefix.
# [17:30] <dbaron> fantasai: could also put a functional notation in the display property around the template
# [17:31] <TabAtkins_> dsinger: Let's circle back to Hyatt and see if he needs his specific suggestion or if something else would work.
# [17:31] <dbaron> dbaron: Using a function also means we don't permanently use up the <string> syntax.
# [17:31] <dbaron> fantasai: And using a function also means one can search for the name for that function.
# [17:31] <TabAtkins_> dbaron: I think the functional notation is reasonable permanently because it doesn't use up the string value permanently, just a function name.
# [17:33] <TabAtkins_> RESOLVED: Edit the Template spec in some manner to make it possible to do vendor experimentation.
# [17:36] <TabAtkins_> fantasai: [writes up some syntax options on the board]
# [17:36] <TabAtkins_> fantasai: First is about slots. Hyatt suggests using "position: slot(a);".
# [17:37] <TabAtkins_> alexmog: And that would allow "-webkit-slot(a)" during experimentation.
# [17:37] <TabAtkins_> fantasai: And then actually defining the grid.
# [17:37] <TabAtkins_> fantasai: Hyatt suggests a "grid-template" value for display, which then looks to the value of a "grid-template" property.
# [17:38] <TabAtkins_> fantasai: Someone else suggested a "display: template(foo)" function.
# [17:38] * sylvaing will have to run in 5
# [17:38] <TabAtkins_> fantasai: And Bert suggested putting a "-vendor-template" token as the first value of display.
# [17:39] <TabAtkins_> fantasai: Keep in mind that templates will usually be multiline strings.
# [17:40] <TabAtkins_> fantasai: And second option for position, similar to Bert's proposal of a vendor token.
# [17:40] <TabAtkins_> glazou_: A, A.
# [17:40] <TabAtkins_> jdaggett: A, B
# [17:41] * Quits: alexmog (alexmog@213.236.208.247) (Quit: alexmog)
# [17:41] <sylvaing> can't tell what the options are from here. jdaggett needs an HD webcam :)
# [17:41] <TabAtkins_> CesarAcebal: A, B
# [17:41] <TabAtkins_> ChrisL: A, B
# [17:41] <TabAtkins_> TabAtkins: A, B
# [17:41] <TabAtkins_> tantek: abstain
# [17:41] <TabAtkins_> JohnJansen: A, A
# [17:41] <TabAtkins_> arronei: A, b
# [17:41] <TabAtkins_> dsinger: A, A
# [17:41] <TabAtkins_> anne5: abstain
# [17:41] <TabAtkins_> dbaron: A, B
# [17:42] <TabAtkins_> alexmog: abstain
# [17:42] <TabAtkins_> howcome: abstain
# [17:42] <TabAtkins_> Bert: don't care, C
# [17:42] <TabAtkins_> szilles: A, B
# [17:42] <TabAtkins_> gsnedders: abstain
# [17:43] <TabAtkins_> fantasai: A, B
# [17:43] <jdaggett> First questions
# [17:43] <jdaggett> A. position: slot(a)
# [17:43] <jdaggett> B. position: -webkit "a"
# [17:43] <jdaggett> Second question
# [17:44] <jdaggett> A. display: grid-template;
# [17:44] <jdaggett> grid-template: "aaa"
# [17:44] <jdaggett> B. display: template("aaa")
# [17:44] <jdaggett> C. display: -webkit "aaa"
# [17:45] <jdaggett> results:
# [17:45] <TabAtkins_> Poll results: IA: 11, IB: 0. IIA: 4, IIB: 7, IIC: 1.
# [17:45] <sylvaing> agrees with A, B
# [17:46] <sylvaing> needs to go. thanks everyone !
# [17:46] <TabAtkins_> Later, sylvaing
# [17:46] <jdaggett> bye now!
# [17:46] * Quits: sylvaing (sylvaing@76.104.131.10) (Quit: sylvaing)
# [17:48] <TabAtkins_> CesarAcebal: [shows off some examples of template layout, which he used in his thesis defense]
# [17:52] <fantasai> Topic: Vendor Prefixes
# [17:53] <fantasai> dbaron: One thing we've been hearing from authors is they really don't like vendor prefixes when multiple browsers implement
# [17:53] <fantasai> dbaron: So I'd like to be able to drop prefixes sooner
# [17:53] <fantasai> dbaron: I'd like to ship calc() without prefixes
# [17:53] * mollydotcom thinks designers and devs don't understand the reason and rationale behind vendor prefixes
# [17:53] <Bert> -> http://code.google.com/p/css-template-layout/ adeveria's jQuery-based template layout prototype.
# [17:54] <fantasai> howcome: The problem here is that we're getting to the point when we need to implement others prefixes
# [17:54] * mollydotcom also thinks they use that as a means to blame browsers for not implementing what they want, when they want it
# [17:55] <fantasai> glazou: Question is, is calc() stable enough that we can remove the prefixes
# [17:55] <fantasai> ?
# [17:55] <fantasai> dbaron: There are 2 implementations in progress, that I know of
# [17:56] <fantasai> dbaron: If we're planning to do this, we should ask www-style for comments first
# [17:56] <fantasai> fantasai: Is the rest of Values and Units ready for Last Call?
# [17:57] <fantasai> dbaron: One comment about calc(), specifically
# [17:57] <fantasai> dbaron: For the subset that we're implementing, it's hard to imagine that it would mean something else.
# [17:58] <fantasai> Tab: We only have lengths, which you can add, and you can multiply or divide by numbers.
# [17:58] <fantasai> Tab: I think that's safe enough.
# [17:58] <fantasai> Steve: I would file a formal objection, because the process is supposed to allow for a Last Call period before call for implementation
# [17:59] <fantasai> Bert: It's not illegal for implementations before CR, but it's wrong for us to encourage implementations.
# [17:59] <fantasai> JohnJansen: I would ask if we can take calc() to CR faster.
# [18:00] <fantasai> discussing moving css3-values to LC/CR
# [18:00] <fantasai> ACTION dbaron: Make a list of at-risk features, and list of features that should be dropped for rapid movement to CR
# [18:00] * trackbot noticed an ACTION. Trying to create it.
# [18:00] * RRSAgent records action 11
# [18:00] <trackbot> Created ACTION-265 - Make a list of at-risk features, and list of features that should be dropped for rapid movement to CR [on David Baron - due 2010-09-01].
# [18:01] <fantasai> dbaron: I would mark vh, vw, and vm, fr, and gr.
# [18:02] * Quits: ChrisL (ChrisL@128.30.52.169) (Ping timeout)
# [18:02] <fantasai> fantasai: Are fr and gr used for anything yet (aside from layout drafts)?
# [18:02] <fantasai> no
# [18:02] <fantasai> fantasai: Then let's drop those, keep the v* sections
# [18:02] <fantasai> fantasai: And mark the things in dbaron's list as at-risk
# [18:03] <fantasai> fantasai: Someone commented that vm is no longer necessary now that we have min/max
# [18:03] <fantasai> dbaron: We might want to also mark min/max at-risk
# [18:04] <fantasai> Ok, we're done
# [18:04] <fantasai> Meeting closed.
# [18:04] <fantasai> Thank you Håkon!
# [18:04] <glazou_> ADJOURN !!!
# [18:04] * Quits: CesarAcebal (acebal@213.236.208.247) (Quit: CesarAcebal)
# [18:05] * Quits: JohnJansen (qw3birc@128.30.52.28) (Quit: Page closed)
# [18:05] <fantasai> glazou_: Side-note about Lyons, you have to register and pay a fee
# [18:05] <fantasai> glazou_: Also, the hotels near the conference center are expensive and crap
# [18:06] <fantasai> glazou_: And there are not many hotels in that area
# [18:06] <fantasai> glazou_: Also Lyons is very busy at that time, so I recommend booking your flights and hotel asap
# [18:07] * dsinger Hotel Roosevelt: http://www.booking.com/hotel/fr/hotelrooseveltlyon.html?aid=309824;label=postbooking_confemail
# [18:09] * Quits: Arron (arronei@213.236.208.247) (Ping timeout)
# [18:09] * Quits: dsinger (dsinger@213.236.208.247) (Quit: dsinger)
# [18:10] * Quits: glazou_ (glazou@213.236.208.247) (Quit: glazou_)
# [18:12] * Quits: szilles (chatzilla@213.236.208.247) (Ping timeout)
# [18:13] * Quits: jdaggett (jdaggett@213.236.208.247) (Ping timeout)
# [18:13] * Quits: tantek (tantek@213.236.208.247) (Quit: tantek)
# [18:14] * mollydotcom waves and thanks everyone and hopes to see you again soon (except for Anne who gave me his cold :P)
# [18:15] * Quits: TabAtkins_ (chatzilla@213.236.208.247) (Ping timeout)
# [18:16] * Quits: anne5 (annevk@213.236.208.247) (Quit: anne5)
# [18:17] * Quits: Lachy (Lachlan@213.236.208.22) (Quit: This computer has gone to sleep)
# [18:18] * Quits: dbaron (dbaron@213.236.208.247) (Ping timeout)
# [18:19] * Zakim dbaron, you asked to be reminded at this time to go home
# [18:19] * Parts: mollydotcom (mollyh@95.34.118.56)
# [18:33] * Joins: Lachy (Lachlan@84.215.59.50)
# [18:34] * Zakim excuses himself; his presence no longer seems to be needed
# [18:34] * Parts: Zakim (rrs-bridgg@128.30.52.169)
# [18:42] * Joins: tantek (tantek@84.208.66.187)
# [18:44] * Quits: tantek (tantek@84.208.66.187) (Quit: tantek)
# [19:02] * Parts: Doofl (mstensho@213.236.208.247)
# [20:31] * Joins: glazou (glazou@62.92.21.80)
# [20:32] * Quits: glazou (glazou@62.92.21.80) (Quit: glazou)
# [21:53] * Joins: Arron (arronei@84.208.66.187)
# [21:53] * Joins: TabAtkins_ (chatzilla@84.208.66.187)
# [21:54] * Quits: TabAtkins_ (chatzilla@84.208.66.187) (Quit: ChatZilla 0.9.86-rdmsoft [XULRunner 1.9.0.13/2009073109])
# [21:57] * Joins: tantek (tantek@84.208.66.187)
# [22:11] * Joins: tantek_ (tantek@84.208.64.109)
# [22:14] * Quits: tantek (tantek@84.208.66.187) (Ping timeout)
# [22:14] * Quits: tantek_ (tantek@84.208.64.109) (Ping timeout)
# [22:21] * Joins: tantek (tantek@84.208.64.109)
# [22:24] * Quits: Arron (arronei@84.208.66.187) (Ping timeout)
# [22:25] * Quits: tantek (tantek@84.208.64.109) (Ping timeout)
# [22:30] * Joins: jdaggett (jdaggett@195.159.215.166)
# [22:30] * Quits: jdaggett (jdaggett@195.159.215.166) (Quit: jdaggett)
# [22:32] * Joins: tantek (tantek@84.208.64.109)
# [22:35] * Joins: dbaron (dbaron@84.208.66.187)
# [22:36] * Quits: tantek (tantek@84.208.64.109) (Ping timeout)
# [22:42] * Joins: tantek (tantek@84.208.64.109)
# [22:47] * Quits: tantek (tantek@84.208.64.109) (Ping timeout)
# [22:53] * Joins: tantek (tantek@84.208.64.109)
# [22:57] * Joins: Arron (arronei@84.208.66.187)
# [22:57] * Quits: tantek (tantek@84.208.64.109) (Ping timeout)
# [23:02] * Joins: lstorset (lstorset@84.215.115.49)
# [23:04] * Joins: tantek (tantek@84.208.64.109)
# [23:08] * Quits: tantek (tantek@84.208.64.109) (Ping timeout)
# [23:14] * Joins: tantek (tantek@84.208.64.109)
# [23:19] * Quits: tantek (tantek@84.208.64.109) (Ping timeout)
# [23:19] * Quits: dbaron (dbaron@84.208.66.187) (Ping timeout)
# [23:25] * Joins: tantek (tantek@84.208.64.109)
# [23:29] * Quits: tantek (tantek@84.208.64.109) (Ping timeout)
# [23:36] * Joins: tantek (tantek@84.208.64.109)
# [23:40] * Quits: tantek (tantek@84.208.64.109) (Ping timeout)
# [23:43] * Parts: futhark (rune@213.236.208.22)
# [23:46] * Joins: tantek (tantek@84.208.64.109)
# [23:50] * Quits: tantek (tantek@84.208.64.109) (Ping timeout)
# [23:57] * Quits: shepazu (schepers@128.30.52.169) (Quit: shepazu)
# [23:57] * Joins: tantek (tantek@84.208.64.109)
# Session Close: Thu Aug 26 00:00:00 2010

The end :)