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