IRC log of css on 2011-03-09

Timestamps are in UTC.

17:07:10 [RRSAgent]: RRSAgent has joined #css
17:07:10 [RRSAgent]: logging to http://www.w3.org/2011/03/09-css-irc
17:07:18 [dbaron]: RRSAgent, this meeting spans midnight
17:07:33 [Bert]: meeting: CSS ftf day 3
17:07:43 [Bert]: chair: peter/daniel
17:07:52 [RRSAgent]: I have made the request to generate http://www.w3.org/2011/03/09-css-minutes.html Bert
17:08:23 [bradk]: bradk has joined #css
17:09:22 [smfr]: smfr has joined #css
17:09:44 [sylvaing]: sylvaing has joined #css
17:10:26 [jdaggett]: topic: css3 fonts
17:10:28 [jdaggett]: http://dev.w3.org/csswg/css3-fonts
17:10:56 [Kazutaka]: Kazutaka has joined #CSS
17:11:43 [hober]: hober has joined #css
17:12:18 [fantasai]: ScribeNick: fantasai
17:13:11 [fantasai]: jdaggett: There are some recent edits that I wanted to go over, based on comments that were made at previous F2F and on www-style
17:13:28 [fantasai]: jdaggett: We'll go through those, then at the end there's some discussion that needs to happen wrt WOFF.
17:13:49 [alexmog]: alexmog has joined #css
17:14:00 [fantasai]: jdaggett: Overview: css3-fonts expands font properties from CSS2.1 and adds definition for @font-face which allows fonts to be downloaded, and add supports for OpenType font features, which are exposed via font-variant
17:14:09 [howcome]: howcome has joined #css
17:14:20 [fantasai]: jdaggett: Font features are ways of selecting alternate glyphs or alternate ways of showing text using data that's contained in OT fonts.
17:14:32 [fantasai]: jdaggett: Covers superscripts subscripts, alternate glyphs, ligatures, etc.
17:14:44 [szilles]: szilles has joined #css
17:15:13 [fantasai]: jdaggett: It let's you select which (of multiple variant glyphs for given set of codepoints) is chosen
17:15:27 [fantasai]: jdaggett shows stylistic()
17:15:55 [fantasai]: jdaggett: Because the argument to stylistic() is specific to the font, a lot of people in the group felt we needed a way to associate that value with the font that had that feature.
17:16:03 [jdaggett]: http://dev.w3.org/csswg/css3-fonts/#font-feature-values
17:16:21 [fantasai]: jdaggett: Because of that, we added the @font-feature-values rule
17:16:38 [fantasai]: jdaggett: For each of the font-specific alternate types, you define a set of name-value pairs for a given font
17:16:57 [fantasai]: jdaggett explains the rest of @font-feature-values
17:17:27 [fantasai]: basically, you create an @-rule associated with a font name
17:17:35 [fantasai]: and then within that block you define name-value pairs
17:17:53 [fantasai]: the same name can be used in multiple @-rules, associating different values with the same name depending on the font
17:18:12 [fantasai]: then in the declaration, stylistic() takes the name, and maps to the appropriate value depending on the font actually in use
17:20:02 [fantasai]: howcome: Do we need the comma between the name-value pairs?
17:20:06 [fantasai]: fantasai: technically, no
17:20:41 [fantasai]: jdaggett: I think it makes it easier to read
17:22:08 [fantasai]: jdaggett: I had swash: delicate 1, flowing 2; but since the cascading behavior is different from what you'd expect from that, WG wanted to change the syntax
17:22:28 [fantasai]: fantasai: The cascading behavior is as if "swash" was an element name, and the name-value pairs were property-value declarations.
17:23:27 [fantasai]: fantasai: There was another proposal that made this clearer (by adopting element { property: value; } syntax) at the expense of adding more braces
17:24:56 [fantasai]: jdaggett shows more examples from the spec that illustrate the cascading behavior, which collects all name-value mappings across style sheets (redeclaring same name overrides, just like property-value declarations)
17:25:31 [johnjan]: johnjan has joined #css
17:25:46 [TabAtkins_]: TabAtkins_ has joined #css
17:27:34 [fantasai]: jdaggett shows some other func() font feature notations that use @font-feature-values rule
17:28:30 [fantasai]: more discussion of comma
17:28:37 [fantasai]: howcome thinks it's unnecessary typing
17:29:21 [fantasai]: fantasai notes that counter properties don't use commas
17:31:01 [fantasai]: dbaron notes that he always gets that wrong even though he implemented it
17:31:09 [fantasai]: howcome: commas used to be used to denote alternates
17:31:33 [fantasai]: Tab: But that's not true anymore
17:31:45 [fantasai]: Tab: e.g. text-shadow, background
17:31:54 [fantasai]: Some discussion of syntax
17:32:15 [fantasai]: howcome feels it's unclear that the name-value pairs are additive, suggests being more verbose and using separate @ rules for each pair
17:32:23 [fantasai]: jdaggett notes that this is possible if that's wanted
17:32:32 [fantasai]: several feel that's excessive typing and don't want to require it
17:33:24 [arno]: arno has joined #css
17:34:49 [fantasai]: jdaggett shows the Greek coin example
17:35:13 [bz]: bz has joined #css
17:35:51 [bradk]: http://www.tktype.com/chartwell.php
17:37:39 [fantasai]: jdaggett notes for the future that having selectors for picking out patterns to alter the font-features of would be nicer than having to use spans
17:37:49 [fantasai]: but this example is rare enough that for now this doesn't seem to be a problem for us to solve
17:39:51 [fantasai]: some questions about how OT features work
17:39:52 [jdaggett]: http://dev.w3.org/csswg/css3-fonts/#font-feature-settings-prop
17:39:55 [fantasai]: jdaggett explains
17:40:55 [fantasai]: jdaggett reviews some updates to the font-feature-settings syntax
17:41:07 [fantasai]: jdaggett: There's a set of registered OpenType features.
17:41:12 [fantasai]: jdaggett: All of them will be CSS identifiers
17:41:24 [fantasai]: jdaggett: It's technically possible to define an OpenType feature that, e.g. starts with a 3
17:41:47 [fantasai]: jdaggett: For those cases that we want to escape, you can add the optional ot- prefix
17:42:12 [fantasai]: jdaggett: For these tags I haven't put in any syntax definitions
17:43:37 [fantasai]: jdaggett explains the escaping mechanism e.g. 3cap feature would have to be written as ot-3cap
17:43:58 [fantasai]: jdaggett: For boolean features, just placing the feature name will set it to 1 (on)
17:44:29 [Bert]: (ot-3cap and \3cap are thus the same.)
17:44:32 [fantasai]: jdaggett: Also the author can be explicit with functional notation, wihch allows integers, but can also use "on" and "off"
17:45:01 [fantasai]: dbaron: You don't need the ot- prefix for escaping, since you can just escape the number
17:45:28 [fantasai]: Tab: Why aren't we just using quoted strings?
17:45:33 [dbaron]: ot-3cap and \33cap are the same
17:45:36 [dbaron]: er
17:45:39 [dbaron]: ot-3cap and \33 cap are the same
17:45:40 [Bert]: (Correction: ot-3cap and \33 cap are thus the same.)
17:46:15 [fantasai]: jdaggett^: There was also the question of e.g. attr() function, which could conflict with an OT feature
17:47:07 [fantasai]: jdaggett: You're not just giving the feature name, you have to give a value, too.
17:47:49 [dbaron]: Arron suggests: "3pix" 1
17:48:02 [Arron]: "3pix" 1
17:49:14 [fantasai]: fantasai asks what would happen if a font format defined features that took string values
17:49:21 [fantasai]: plinss: use a comma to separate mapping pairs
17:49:27 [dbaron]: e.g., font-feature-settings: "smcp", "swsh" 2
17:49:58 [fantasai]: jdaggett: for this, I think commas don't make sense
17:50:20 [bradk]: "c2sc" 1, "3piX" 1
17:50:24 [fantasai]: Steve: It would be nice if the pairing notation was the same in both places
17:50:32 [fantasai]: jdaggett: For the name value pairs we are always defining a name and a value
17:50:39 [fantasai]: jdaggett: For this in most cases you just want the tag name
17:51:25 [fantasai]: jdaggett: So you wwant "smcp", "swsh" 2
17:51:46 [fantasai]: plinss: The comma separates features settings, so that you can distinguish between a feature name and a value
17:52:30 [fantasai]: steve says something, several people disagree
17:52:31 [dbaron]: Steves asks whether given @swash flowing 1;, you could do font-feature-settings: swsh(flowing) or font-feature-settings: "swsh" flowing
17:53:33 [fantasai]: jdaggett: So what if I say "iatl" for which we have no feature settings
17:53:49 [fantasai]: dbaron: That seems like extra code to support the non-recommended way of doing something
17:53:54 [dbaron]: s/iatl/ital/
17:54:49 [fantasai]: Steve: I just want to make sure we make a conscious decision.
17:54:51 [dbaron]: jdaggett: That means the author has to know which CSS property maps to which opentype feature name.
17:55:12 [fantasai]: jdaggett: I just want to make sure everyone wants to have a non-functional notation, which is different from above
17:56:55 [fantasai]: several: Yes. Those are CSS-defined. This is an open-ended set of potentially non-identifiers.
17:57:29 [fantasai]: Luke: It's not clear that this is impossible to parse, it's just that you are introducing a whole bunch of these ..
17:57:40 [fantasai]: Luke: We can't have a nice enum of whatever this type is
17:58:10 [fantasai]: Luke: Instead of a simple arbitrary string, you have this extra syntax thing
17:58:25 [fantasai]: fantasai: You have to parse arbitrary idents for counters anyway
17:59:09 [hyatt]: hyatt has joined #css
18:00:05 [fantasai]: Simon: I think you should figure out a way of not using ot-, or use it all the time. Having it be optional is weird
18:00:31 [jdaggett]: alt 1: font-feature-settings: smcp, swsh 2;
18:00:49 [jdaggett]: alt 2: font-feature-settings: "smcp", "swsh" 2;
18:01:26 [jdaggett]: alt 3: font-feature-settings: smcp swsh(2);
18:01:45 [smfr]: alt 2 and alt 3 may require ot- prefixes
18:02:02 [fantasai]: s/2/1/
18:02:17 [jdaggett]: alt 4: font-feature-settings: ot-smcp, ot-swsh(2)
18:03:15 [fantasai]: this sets smcp to 1 and swsh 2
18:04:02 [fantasai]: Steve: I don't understand why each of the pieces are being proposed
18:05:15 [fantasai]: howcome: If it's just a low-level feature as an escape hatch in the baseline, why is the syntax that important?
18:05:34 [fantasai]: glazou: It's about finding the most elegant syntax that avoids problems for the future
18:05:48 [stearns_]: stearns_ has joined #css
18:05:58 [glazou]: glazou has joined #css
18:07:23 [stearns_]: stearns_ has left #css
18:07:25 [fantasai]: fantasai: Font families are either idents or quoted strings
18:07:29 [macpherson]: macpherson has joined #css
18:07:40 [fantasai]: fantasai: Why not do that here, where both 1 and 2 are possible?
18:07:43 [stearns_]: stearns_ has joined #css
18:07:49 [fantasai]: Arron: I like that
18:07:55 [fantasai]: plinss is concerned about this
18:08:13 [fantasai]: dbaron: We have the future-proofing problem for counters and everal other things already
18:08:26 [fantasai]: plinss: With strings you avoid potential conflicts with expansions in either CSS or the fonts
18:08:38 [Bert]: +1 to fantasai (let author use quotes or not, as fits best)
18:08:43 [Jay]: Jay has joined #CSS
18:08:47 [fantasai]: plinss: Also this avoids authors being confused about whether they need to quote something or not
18:09:30 [fantasai]: alt 5: either 1 or 2 is valid
18:09:58 [fantasai]: plinss: It's safer to always require it to be quoted.
18:10:13 [fantasai]: plinss: This is an obscure rarely-used feature. It's simpler and easier to maintain if you always have to quote it
18:10:26 [fantasai]: plinss: This avoids any potential problems ever.
18:10:43 [fantasai]: jdaggett: I define on and off to be 1 and zero
18:10:48 [fantasai]: plinss: That's fine.
18:11:01 [fantasai]: jdaggett: And you're ok with assumption of 1 as default value
18:11:10 [fantasai]: plinss: Yes, no problem. Those are all very clean CSS ways of doing things.
18:11:40 [fantasai]: plinss: Our default design should be to avoid any possible conflicts with future CSS keywords
18:12:03 [fantasai]: plinss: For something obscure like this, we really have no good reason to go against that.
18:12:28 [Bert]: (The "ot-" prefix should probably be on the property name, not on the values...)
18:12:37 [fantasai]: plinss: The ot- prefix is very complex because you parse an ident then have to reparse to break it down, I don't want to introduce that, especially not for something obscure like this
18:14:45 [fantasai]: Bert: The quotes are redundant. They're parseable without.
18:15:06 [fantasai]: Bert: And if you put this in an attribute, e.g. in HTML you have to double-quote.
18:15:13 [fantasai]: Bert: That's why we didn't put quotes in font-family
18:15:14 [cslye_]: cslye_ has joined #css
18:15:47 [fantasai]: Tab: The issue here is that once you go beyond idents, you have to start escaping, and that's very confusing for authors.
18:16:14 [cslye_]: cslye_ has joined #css
18:16:24 [fantasai]: Tab: Very few people understand escaping rules
18:17:00 [fantasai]: Bert argues for arbitrary unquoted strings
18:17:51 [fantasai]: vehement disagreement
18:18:22 [fantasai]: jdaggett: I will write up the proposal and post to the mailing list
18:18:29 [fantasai]: fantasai: I would like to do something that gets a WD published.
18:18:39 [jdaggett]: http://dev.w3.org/csswg/css3-fonts/#vertical-position-prop
18:19:18 [fantasai]: RESOLVED: jdaggett will write up alt 2 into the spec, mark as open issue whether quotes are required
18:19:27 [fantasai]: jdaggett moves on to vertical-position
18:20:17 [fantasai]: jdaggett explains how superscripts and subscripts are currently implemented: the vertical alignment is adjusted, and the font size shrunk down
18:20:46 [fantasai]: jdaggett: This has some problems. The typographic color is affected, since a typographic superscript or subscript is not used
18:20:53 [fantasai]: jdaggett: And because of the vertical alignment, the line height is affected
18:21:04 [fantasai]: jdaggett: So we have this feature
18:21:27 [fantasai]: jdaggett: This property behaves as a shorthand, resetting font-size and vertical-align (to inherit and initial)
18:21:37 [fantasai]: jdaggett: You effectively null out those property definitions
18:21:50 [fantasai]: jdaggett: For older clients that don't support this feature, they will still use the default adjustement to font size
18:22:12 [fantasai]: jdaggett: shows example
18:22:51 [fantasai]: dbaron: There's also the second fallback case, of where the font doesn't support it
18:23:02 [fantasai]: jdaggett: For that we put in synthesizing rules
18:23:30 [fantasai]: Alex: Doesn't this still use smaller size
18:24:41 [fantasai]: jdaggett: Yes. If those glyphs are missing, you don't get them. But you at least get a superscript. And you don't affect the line height.
18:25:09 [fantasai]: dbaron: This seems to be the first time we have a shorthand that sets both inherited and non-inherited properties together. I'm a little concerned about that.
18:25:48 [fantasai]: dbaron: Also, I'd like something that works for the default UA style sheet
18:26:12 [stearns]: if only the old styling is used (vertical-align: sub) does a new implementation use the new synthesizing rules that do not affect line height?
18:26:38 [fantasai]: steve explains his proposal
18:26:47 [fantasai]: dbaron: Third proposal --
18:26:59 [fantasai]: dbaron: Make vertical-position a non-inherited non-shorthand property
18:27:13 [fantasai]: dbaron: Then say that any text inside an element with vertical-position set
18:27:28 [fantasai]: dbaron: you ignore the vertical-align value on the element that had vertical-position set
18:27:56 [fantasai]: dbaron: And you recompute the font size based on the ratio of the font-size of the element with vertical-position set to its parent
18:28:26 [fantasai]: dbaron: if you have nested vertical-position, you ignore it on the nested one
18:29:03 [fantasai]: dbaron: Then you can use it in a UA style sheet, and if the author nests superscripts you no-op it
18:29:20 [fantasai]: fantasai, Steve: But the point was to have nested subscripts to work
18:29:45 [dbaron]: It still doesn't really work with nested subscripts.
18:29:48 [fantasai]: jdaggett: In your (Steve)'s proposal, the line height is affected
18:30:09 [fantasai]: Steve: My thinking is that I have a subscript, and if my font has subscript characters, I want to use them
18:30:18 [fantasai]: Steve: If it doesn't have a character in the font, then I'd like reasonable fallback
18:30:39 [fantasai]: Steve: So my goal is to think about what would the fallback require, and then say how I can then go back and enable the font feature to be used
18:30:45 [fantasai]: Steve: and in fact mixed with fallback
18:31:00 [fantasai]: Steve: Say my subscript is 1a, and the font only has 1 as a subscript
18:31:16 [fantasai]: jdaggett: My concern is that you're still affecting the line height
18:31:39 [fantasai]: Steve: How do I make sure there's enough room for the subscript if we don't adjust the line-height?
18:32:37 [fantasai]: jdaggett: The whole point of the font's glyphs is that they're designed to fit in with the rest of the text so you don't need to change the line height
18:33:30 [fantasai]: Simon: Do fonts have glyphs for all their characters as superscripts?
18:33:44 [Bert]: (Something like: 'vertical-position: superscript', IF the font has superscript glyphs AND the the elt has 'vertical-align: super', sets a hypothetical inherited 'font-size-multiply' property to (parent-size/own-size) and ignores 'vertical-align')
18:33:46 [fantasai]: jdaggett: No. Usually only a small subset. If the glyph is missing, the UA synthesizes whatever is missing
18:35:25 [fantasai]: some confused discussion
18:36:39 [fantasai]: howcome: Why couldn't we key off 'vertical-align' and just have a setting that says "be smart"
18:38:33 [Bert]: ('vertical-position: smart' means, if 'vertical-align' and 'font-size' are set in certain ways and the font has the necessary glyphs, then ignore the properties and use those glyphs.)
18:39:35 [Bert]: Fantasai: keep the computed values, but change the used values.
18:40:06 [TabAtkins_]: dbaron: You need to worry both about children that are nested sub/supers, and children that aren't.
18:41:05 [TabAtkins_]: fantasai: [draws some superscripted]
18:41:36 [TabAtkins_]: fantasai: You have the baseline of the element
18:42:24 [TabAtkins_]: fantasai: And pick one of the baselines in this box. There's a different concept between what baseline you're aligning the text to, and what you expose as the text's "baseline" outside.
18:42:52 [TabAtkins_]: fantasai: So text has an "alphabetic" and a "superscript" baseline.
18:43:20 [TabAtkins_]: fantasai: When this feature is turned on, for the children, rather than aligning the children's alphabetic to the parent's alphabetic, align the children's alphabetic to the parent's superscript baseline.
18:43:47 [TabAtkins_]: fantasai: And font-size is still inherited, so it'll shrink down as you drop, but the used value of font-size is based on the parent, so they'll be the right size when they're rendered.
18:44:06 [TabAtkins_]: szilles: So what jdaggett is concerned about it, what is the line-height for the text?
18:44:34 [TabAtkins_]: fantasai: The used value of the font-size is based on the parent. It *looks* like you're shifting up, but you're really just using a different glyph.
18:44:50 [TabAtkins_]: fantasai: It's only when you start nesting that you'll mess with the line-height.
18:45:11 [TabAtkins_]: dbaron: I think there's a second related problem here.
18:45:22 [TabAtkins_]: dbaron: It's that we're using "font-size:smaller", which isn't what we want.
18:45:26 [stearns]: If you don't have the OpenType glyphs, the synthesized version can run into line height problems as well
18:45:34 [TabAtkins_]: dbaron: jdaggett says there's a metric that says not only where the superscript baseline is, but how large it is too.
18:46:21 [TabAtkins_]: dbaron: if font-size had keywords for "superscript size", etc.
18:46:30 [TabAtkins_]: Bert: MathML has a concept of a "script size".
18:47:02 [TabAtkins_]: dbaron: If you combine the superscript baseline of a font with the superscript size, will you get something within the bounds of the font, so you don't bump the lineheight?
18:47:31 [TabAtkins_]: jdaggett: It *should*, but not guaranteed.
18:47:59 [TabAtkins_]: dbaron: We can ignore the problem of alternate glyphs for a moment, and just look at the sub/sup problem with synthesized/font-size stuff...
18:48:09 [TabAtkins_]: dbaron: Then we'll solve the linebox problem, but not the weight problem.
18:48:45 [TabAtkins_]: dbaron: And perhaps the alternate glyphs oslution will fall out of what we come up with.
18:49:00 [TabAtkins_]: dbaron: This depends on the superscript characters actually matching the reported superscript metrics, or else this all falls apart.
18:49:36 [TabAtkins_]: szilles: There are two categories: 1) fonts that behave like David wants them to behave, and 2) fonts that don't.
18:49:58 [TabAtkins_]: szilles: Which group should we design towards? Either one may be broken in some case.
18:50:56 [TabAtkins_]: cslye: I've looked at some Adobe fonts, and it looks like they're all "broken" - they use the same superscript baseline, which means they probably don't match the character size.
18:51:19 [TabAtkins_]: szilles: I propose that we record an issue for this.
18:53:57 [TabAtkins_]: jdaggett: My problem is that most of these proposals are fairly hairy.
18:54:52 [TabAtkins_]: szilles: [suggestion about making font-size and vertical-align compute to two values, one for normal text and one for sub/super text]
18:55:22 [TabAtkins_]: jdaggett: I suggest I just put in a grave note about this being hairy, so we have some text about this in a WD.
18:55:49 [TabAtkins_]: szilles: I recommend that the note point out that this is trying to solve the "line-heights get changed by sub/superscript" problem.
18:56:02 [TabAtkins_]: szilles: Also that this being a shorthand "messes up" inheritance.
19:14:23 [fantasai]: jdaggett: Next topic is font matching algorithm
19:14:29 [fantasai]: jdaggett: This isn't totally completed
19:14:38 [fantasai]: jdaggett: There are things that still need to be investigated, will talk about that later
19:14:41 [fantasai]: jdaggett:
19:14:55 [fantasai]: jdaggett: This is the world we live in today. *shows lsides of four 'u's*
19:15:01 [fantasai]: jdaggett: You see normal, italic, obld, and bold italic
19:15:33 [fantasai]: jdaggett: The way we're going is this way *shows slide of lots of 'u's with multiple weights, some of which have italics, and some of which have narrow*
19:15:42 [fantasai]: jdaggett: This is the design of the Univers font
19:16:12 [fantasai]: jdaggett: If you go back and look at CSS2.1 algorithm, it says 'first match on this, then match on this'
19:16:20 [fantasai]: jdaggett: It's not fully describing the process that needs to happen
19:16:30 [fantasai]: jdaggett: For each of the axes within this family, you're narrowing until you have only one choice
19:16:47 [fantasai]: jdaggett: e.g. if you have font-stretch: normal, then you narrow to normal stretches
19:17:03 [fantasai]: jdaggett: Then if you say font-style: normal, you filter out the italic faces
19:17:18 [fantasai]: jdaggett: And if you say normal weight, then you select the normal weight within that
19:17:39 [fantasai]: jdaggett: if you select condensed italic bold, then you narrow like this *demonstrates by highlighting characters*
19:18:08 [fantasai]: jdaggett: Sometimes if the appropriate weight or italics is missing, the UA synthesizes them
19:18:45 [fantasai]: jdaggett: But in the font world you can have families like this *shows a slide of 'u's that fill in only random parts of the font weight/stretch/italic chart*
19:18:55 [fantasai]: jdaggett: I tried to make the rules as simple and straightforward as possible
19:19:56 [fantasai]: jdaggett: DirectWrite does some fancy grouping, where it takes fonts that have families that specify a style in the family name
19:20:03 [fantasai]: jdaggett: And it will remove the style names and create its own families
19:20:12 [fantasai]: jdaggett: Both IE9 and FF4 put in hacks to work around,
19:20:25 [fantasai]: jdaggett: if an author says I want "Gill Sans", which is typically available on OS X
19:20:48 [fantasai]: jdaggett: Via DirectWrite you would wind up wth a family that had only Gill Sans Ultra Bold
19:21:13 [fantasai]: jdaggett: Instead of saying very vague terms about you match this and then you match that...
19:21:20 [fantasai]: jdaggett: ...
19:21:25 [fantasai]: jdaggett projects the algo
19:21:47 [fantasai]: howcome: Are we going to have to change our implementations?
19:22:04 [fantasai]: jdaggett: Where there wer ambiguities in the original spec, you may need to change your implementation. I think for the common cases it will not be necessary.
19:22:20 [fantasai]: jdaggett: For most families that exist on most platforms, it's a very simple choice. And those choices will not be affected.
19:22:40 [fantasai]: jdaggett: The choices that will be affected are when someone creates an incongruous family via @font-face
19:23:23 [fantasai]: jdaggett: Right now the choices in such cases that result in random choices
19:23:36 [fantasai]: howcome: It would be good if we could have test cases
19:24:00 [fantasai]: jdaggett: That's the intention. To put in rules here so that I can write tests and point to what they're testing.
19:24:29 [fantasai]: jdaggett: jkew pointed out the first line in rule 4
19:24:41 [fantasai]: jdaggett: Not all of the faces in a family will have the same character
19:25:01 [fantasai]: jdaggett: There's a question of, do you first say "what are all the faces that have a specific glyph" and then match after that
19:25:10 [bradk]: bradk has joined #css
19:25:27 [fantasai]: jdaggett: UAs typically select a face and then find out whether the glyph is there or not.
19:25:55 [fantasai]: jdaggett: But you have problems, e.g. Arial has some faces (e.g. italic) that don't have all the characters in other faces
19:25:57 [sylvaing]: sylvaing has joined #css
19:26:20 [dbaron]: so UAs typically select the face, and then if the glyph isn't present in that face, they fall back to the next *family*
19:26:22 [fantasai]: jdaggett: So you might select bold italic, and since the glyph isn't there, you fall back to a different font instead of falling back to another variant of Arial that has the glyph
19:26:42 [fantasai]: jdaggett: I put rules here that you select font-stretch similar to the way you'd select the weight
19:26:52 [fantasai]: Steve: So sort of the nearest reasonable value
19:26:55 [fantasai]: jdaggett: yes, but not precisely
19:27:05 [fantasai]: jdaggett: Here, for example, the normal face is the family to the left
19:27:17 [fantasai]: jdaggett: You can specify style values that are in between some of these families
19:27:28 [fantasai]: jdaggett: The rule I wrote up in the text is to always go away from 'normal'
19:27:36 [fantasai]: jdaggett: So it may not be the next closest nearest neighbor
19:27:47 [fantasai]: jdaggett: We might end up picking something further away
19:27:53 [fantasai]: Steve: that's true in weights as well
19:28:04 [fantasai]: Arron: You're trying to show visual change
19:28:06 [fantasai]: jdaggett: right
19:28:14 [fantasai]: jdaggett: I also put in rules that you don't synthesize
19:28:23 [fantasai]: jdaggett: That's marked as an issue
19:28:35 [fantasai]: jdaggett: I would prefer that we keep synthesis as effects, and not part of the selection process
19:30:45 [fantasai]: jdaggett: If you have a font style choice of italic and there's no italic, per CSS rules you technically should be falling back
19:30:58 [fantasai]: jdaggett: But in implementations today you don't do that, so these rules match reality
19:31:16 [fantasai]: jdaggett: We have 'normal' 'italic' and 'oblique'
19:31:31 [fantasai]: jdaggett: But typically, whether there is italic or oblique depends on the kind of font
19:31:41 [fantasai]: jdaggett: Current UAs don't distinguish italic and oblique
19:31:59 [fantasai]: jdaggett: So what I've written here is that UAs are allowed to do this, but for @font-face rules they must distinguish
19:33:12 [fantasai]: ...
19:33:29 [fantasai]: jdaggett: There was some confusion over this where some people were interpreting oblique as the synthesized face, but that's not the case.
19:33:36 [fantasai]: Bert: This is a change from CSS2.1
19:33:56 [fantasai]: jdaggett: It's a change from the wording of the CSS2.1 spec, but not from implementations
19:34:16 [fantasai]: jdaggett: In implementations, you couldn't specify italics and get normal.
19:34:25 [fantasai]: howcome: It would be good to get a list of changes.
19:34:34 [dbaron]: (relative to CSS 2.1)
19:35:39 [fantasai]: jdaggett points out sentence that uses actual value of font-size instead of computed, that it should be removed
19:35:57 [fantasai]: Bert thought it was removed already from 2.1, dbaron suggests maybe we forgot this occurrence
19:37:04 [Bert]: (15.7 "font-size" in CSS 2.1 says "On all other properties, 'em' and 'ex' length values refer to the computed font size of the current element. On the 'font-size' property, these length units refer to the computed font size of the parent element.On all other properties, 'em' and 'ex' length values refer to the computed font size of the current element. On the 'font-size' property, these length units refer to the computed font size of the parent element.")
19:37:04 [fantasai]: jdaggett: I also changed the behavior for small-caps, since this is no longer a separate font face with a different name, but part of the main font family, and UAs don't associate unrelated fonts via "small caps" in the name
19:38:46 [fantasai]: jdaggett notes that the system font fallback is very UA-defined, might involve multiple fonts, might depend on codepoint or encoding or language, so has clarified that
19:39:07 [fantasai]: jdaggett also added a last resort representation for missing glyphs
19:39:15 [fantasai]: jdaggett: This leads to character handling issues
19:39:26 [fantasai]: jdaggett: In Unicode you're not dealing with just a single character, but a cluster
19:39:37 [fantasai]: jdaggett: It could be something very simple like an a with an umlaut
19:39:48 [fantasai]: jdaggett: the exact way that we match this hasn't been defined, and we need to define this out more
19:40:08 [fantasai]: jdaggett: I haven't put this in here, but I think what we need to do is map the entire grapheme cluster together
19:40:18 [fantasai]: jdaggett: and if we don't have a font that matches all of those, then go back and do character-by-character
19:40:36 [fantasai]: jdaggett: The thing that's bad right now is that CSS2.1 requires that you use combining characters from the first font even though the base character is from a different font
19:40:56 [fantasai]: jdaggett: I added also that PUAs don't fall back to the system font fallback
19:41:07 [sgalineau]: sgalineau has joined #css
19:42:04 [fantasai]: jdaggett also added an escape clause for U+FFFD
19:42:30 [fantasai]: jdaggett: Another issue is how to deal with variation selectors
19:42:46 [fantasai]: jdaggett: The idea of a variation selector is that for a given Unicode code point, you want to be able to specify a particular representation for that character
19:42:53 [fantasai]: jdaggett: There are a lot of ambiguities here
19:43:16 [fantasai]: jdaggett: There are a lot of debates within people designing Unicode about whether these should be separate characters, or glyphs that are variations of a single character
19:43:35 [fantasai]: jdaggett: The variation selector was to indicate that if possible, you should display a particular character with a particular variation
19:43:46 [fantasai]: jdaggett: This comes up a lot in Chinese and Japanese where over time the glyph representation has changed
19:44:00 [fantasai]: jdaggett: In particular for people's names or place names, they're registered one way, an dyou want to be able to capture that.
19:44:14 [fantasai]: jdaggett: You want to specify with a Unicode codepoint what the ideal representation you're looking for is.
19:44:45 [fantasai]: jdaggett: So that I can show it on my screen with my fonts, and mail it to you and you can't see it because you don't have that ofnt, but you send it to someone else and they can see it
19:44:58 [fantasai]: jdaggett: There's a question here of how you do fallback.
19:45:02 [stearns]: stearns has joined #css
19:45:47 [fantasai]: jdaggett: If you say "I want to display in this font", and a character with a variation selector whose glyph doesn't exist in that font shows up, what do you do?
19:45:51 [fantasai]: jdaggett shows an example
19:48:30 [arno]: arno has joined #css
19:49:46 [fantasai]: in this case there are several variants that are different
19:49:52 [fantasai]: and several variants that are the same
19:50:22 [fantasai]: jdaggett: So do you want to fall back to a different font? Or show the default glyph? What if the default glyph is the same as the variant glyph?
19:50:42 [fantasai]: Steve: This would be a good topic for the workshop in June
19:51:02 [fantasai]: jdaggett: I think you would need to talk to people designing fonts.
19:52:37 [fantasai]: jdaggett: If you go across fonts, you're not guaranteed to get something right
19:52:51 [fantasai]: jdaggett shows some more examples
19:53:25 [fantasai]: jdaggett: Here we're using a gothic font.
19:53:38 [fantasai]: jdaggett: The second line uses a variation selector, takes the glyph from another font
19:53:47 [fantasai]: (serif font)
19:53:57 [fantasai]: jdaggett: This one it's not subtle, the variation is a structural difference.
19:54:06 [fantasai]: jdaggett: But for an author to go from this, to this, it's a little incongruous
19:54:16 [fantasai]: jdaggett: My point is that nothing is cut and dry here.
19:54:22 [fantasai]: jdaggett: There are authors who would rather have the exact glyph
19:54:33 [fantasai]: jdaggett: And there are authors that would rather have the font match
19:55:13 [fantasai]: kojiishi: IVS is primarily for place name and people name
19:55:28 [fantasai]: kojiishi: Using the wrong variant is very impolite
19:55:34 [fantasai]: kojiishi: especially for peoples' names
19:56:56 [fantasai]: some argument between Koji and John about intended behavior of IVS
19:58:21 [fantasai]: jdaggett: If you fall back to a font that has slightly different style, then you may not be able to pick out stylistic differences, particularly if face is gothic face
19:58:47 [fantasai]: Steve: What I've heard you say so far is there are reasonable cases for saying that you want to preserve font integrity and perhaps do what we would do today
19:58:53 [fantasai]: Steve: Let's just deal with IVS
19:59:12 [fantasai]: Steve: There are two options. 1. treat as request for specific thing, and fall back if not there.
19:59:25 [fantasai]: Steve: 2. Use this thing if it's there, otherwise use the thing this is a variation of
19:59:48 [fantasai]: Steve: You've given good examples where one of those approaches is the one that's desired and others where the other approach is desired
20:00:03 [fantasai]: Steve: That suggests to me that have a property to control that would be a useful way for author to say which is more important.
20:00:51 [fantasai]: jdaggett: To define that fallback occurs to the system font, and have to analyze the cmap to find this, that UAs are required to find this font on the system, that's a lot of wrk
20:00:54 [fantasai]: work
20:01:02 [fantasai]: jdaggett: There's how fallback works within fonts, and another of system font fallback
20:01:10 [fantasai]: jdaggett: We don't specify system font fallback
20:01:22 [fantasai]: jdaggett: Is that something that prevents UA from doing something intelligent? No. Just undefined.
20:01:44 [fantasai]: Steve: What occurs to me is that if I make the property have the default value of today's behavior
20:02:15 [fantasai]: jdaggett: The default behavior in FF4 is, if we have a font in the font list that supports the default character, then we will use the default character if the variation selector is not defined.
20:02:30 [fantasai]: jdaggett: This requires the author to specify a font that has the variation they want.
20:02:45 [fantasai]: jdaggett: Practically, they have to do this anyway because the system font is unlikely to have the variation they want
20:02:55 [macpherson_]: macpherson_ has joined #css
20:03:03 [fantasai]: Steve: My proposal is the property does today's behavior by default.
20:03:09 [fantasai]: jdaggett: There is no defined behavior today.
20:03:24 [fantasai]: Steve: This will not be the first time we define default by defining what is
20:03:37 [fantasai]: Steve: Could use property to trigger more refined behavior
20:04:24 [fantasai]: Steve: Could search for IVS, and if it's not there redo search for default glyph
20:05:00 [fantasai]: Steve: I don't think this is that complicated
20:05:10 [fantasai]: jdaggett: It is, doing this as system font fallback is complicated
20:05:16 [fantasai]: fantasai: So don't define it for system font
20:05:49 [fantasai]: jdaggett explains that this doesn't work
20:06:06 [fantasai]: Steve: You go looking through sequence of listed fonts, and if you find an IVS you use it.
20:06:19 [fantasai]: Steve: If you don't find it, you start over for the base character, and that one hits the system font fallback
20:07:30 [fantasai]: jdaggett: But koji says Unicode people want to get the IVS if it's there in the system font
20:07:35 [fantasai]: plinss: Time.
20:07:47 [fantasai]: jdaggett: There are a lot of issues here, and I don't think there's a simple answer here.
20:08:03 [fantasai]: jdaggett: There's a lot of complexity here and we can't decide one way or the other
20:08:22 [fantasai]: Steve: I would like for us to make IVS work, and avoid code points or other subterfuges that would have even worse side-effects.
20:08:46 [fantasai]: kojiishi: If you modify the spec to include normalized shapes for font fallback?
20:09:09 [fantasai]: kojiishi: What's the philosophy behind dealing with grapheme clusters?
20:09:21 [fantasai]: jdaggett: The behavior for grapheme clusters will be distinct from IVS
20:09:35 [fantasai]: jdaggett: Because of the internal structure of the way the selectors are defined, there has to be more with what goes on
20:09:51 [fantasai]: jdaggett: They should try to work similarly, but you have a whole bunch of variation selectors that point at the default.
20:10:11 [fantasai]: jdaggett: So the way this works is going to be slightly different.
20:11:23 [fantasai]: fantasai: Can we file a bug against Unicode?
20:11:52 [fantasai]: fantasai: Request that new variation selectors can only be registered if the registrant can explain how their glyph is different from all the other glyphs
20:12:13 [fantasai]: jdaggett: If a UA is getting a font from the server, by default it will not take fonts that are on a different server.
20:12:22 [fantasai]: jdaggett: This prevents people from using a font from another site on their site
20:12:31 [fantasai]: jdaggett: Helps fulfil requirements on some font licenses
20:12:46 [fantasai]: jdaggett: There's a large issue if this should be by default requiring same-origin
20:13:30 [fantasai]: jdaggett: In <canvas> if you display an image from a different server, it taints the canvas and disables APIs that would read information from the canvas
20:13:38 [fantasai]: jdaggett: There are problems related to same-origins
20:13:48 [fantasai]: jdaggett: If it's loaded cross-domain, it will tain the canvas
20:14:20 [fantasai]: jdaggett: But it's really... there are some people that would suggest not allowing cross-domain use unless it's explicitly marked as cross-domain
20:14:25 [fantasai]: jdaggett: Most resources on the Web are not
20:14:33 [fantasai]: jdaggett: We can't go back and retroactively reset those
20:14:42 [fantasai]: jdaggett: because much of the Web has been built on that
20:14:52 [fantasai]: jdaggett: The spec as written includes this restriction
20:15:01 [fantasai]: jdaggett: So there's this kind of dependencies that are all jumbled up
20:15:10 [fantasai]: jdaggett: The CSS3 Fonts spec defines what a same-origin restriction is
20:15:22 [fantasai]: jdaggett: Since it needs to be defined with the loading mechanism, which is @font-face
20:15:32 [fantasai]: jdaggett: Apple and Opera have objected and want to have instead a different mechanism
20:15:39 [fantasai]: jdaggett: Where the mechanism is opt-in instead of opt-out
20:15:55 [fantasai]: jdaggett: Where the server would say that this resource is restricted to the same domain
20:16:10 [fantasai]: jdaggett: Then you could say the same thing for images, say that the images can't be used cross-origin
20:16:20 [fantasai]: jdaggett: This would allow server admins to not e.g. sniff referrer tags
20:16:58 [fantasai]: jdaggett: The WOFF team has decided that we're going to mark that aspect as at-risk, and there's a potential for dropping this restriction and this other mechanism can come in and replace it
20:17:04 [fantasai]: jdaggett: I don't know if that will work
20:17:10 [fantasai]: howcome: I think you've presented it in a fair manner.
20:17:21 [fantasai]: howcome: From Opera's perspective, our concern is the Web architecture
20:17:35 [fantasai]: howcome: We would like one mechanism that can be used for the whole Web, and not just specific to @font-face
20:17:47 [fantasai]: howcome: I don't have a strong opinion, but some others in Opera do
20:18:00 [fantasai]: howcome: Anne has written up a proposal for a From-Origin spec
20:18:24 [fantasai]: howcome: I don't think this should be in a font-specific spec, but in a generic spec that is not tilted towards a particular media type
20:18:35 [fantasai]: howcome: I also think the default value should be the same throughout the Web
20:18:55 [fantasai]: jdaggett: I don't think it's in-scope for this WG
20:19:14 [fantasai]: jdaggett: to tackle that question
20:19:22 [fantasai]: jdaggett: But we have to reference this issue somehow
20:19:41 [fantasai]: dbaron: Lunch has now be cut to 40 min because we have a hard stop for end of lunch because of QA at 1pm
20:20:07 [fantasai]: plinss: This is an important issue, being discussed at other leves, WebApps and TAG are looking at this
20:20:19 [fantasai]: jdaggett: How do I get my spec not stuck in limbo for 3 years?
20:20:26 [fantasai]: plinss: Mark the feature at-risk.
20:21:32 [Bert]: (I don't think we should say anything about specific mechanisms in CSS, even if we *do* have a good idea of what the mechanism might eventually be; just drop appendix A.)
20:22:08 [fantasai]: jdaggett: Would like to resolve publishing another WD
20:23:03 [fantasai]: RESOLVED: Publish updated WD, with changes marked above (adding issue notes), and list of font matching changes from 2.1
20:23:09 [fantasai]: whew!
20:23:27 [fantasai]: dbaron: Q&A session after lunch, will have a remote video link, but only Mozilla employees
20:23:28 [johnjan]: that was amazing to watch on IRC
20:23:28 [cslye]: cslye has left #css
20:23:50 [fantasai]: :)
20:24:04 [fantasai]: <br type="lunch">
20:47:21 [glazou]: glazou has joined #css
21:06:22 [hober]: hober has joined #css
21:09:18 [dbaron]: dbaron has joined #css
21:11:08 [howcome]: howcome has joined #css
21:25:51 [smfr]: smfr has joined #css
21:54:02 [macpherson]: macpherson has joined #css
21:54:25 [Bert]: (About sending to www-style, as Tab recommended: www-style was the busiest mailing list in W3C in 2010. Only public-html gets close...)
21:55:04 [plinss_]: plinss_ has joined #css
21:55:07 [macpherson]: macpherson has joined #css
21:56:43 [glazou]: glazou has joined #css
21:58:05 [bradk]: bradk has joined #css
21:59:12 [hober]: hober has joined #css
22:00:29 [fantasai]: Topic: CSS2.1
22:01:37 [plinss_]: http://wiki.csswg.org/spec/css2.1#issue-242
22:01:44 [Jay]: Jay has joined #CSS
22:02:06 [plinss_]: http://lists.w3.org/Archives/Public/www-style/2011Mar/0179.html
22:02:08 [TabAtkins_]: TabAtkins_ has joined #css
22:02:59 [Kazutaka]: Kazutaka has joined #CSS
22:03:42 [fantasai]: "(es) (even if either side is empty)
22:03:42 [fantasai]: "
22:03:51 [arno1]: arno1 has joined #css
22:04:59 [dbaron]: (and any block-level siblings that are consecutive or separated by only ignorable whitespace or out-of-flow elements)
22:05:26 [dbaron]: probably s/by only/only by/
22:05:39 [fantasai]: s#or#and/or#
22:05:40 [fantasai]: :)
22:06:46 [dbaron]: are broken around the block-level box (and any block-level siblings that are consecutive or separated only by ignorable whitespace and/or out-of-flow elements), splitting the inline box into two boxes (even if either side is empty), one on each side of the block-level box.
22:07:14 [dbaron]: are broken around the block-level box (and any block-level siblings that are consecutive or separated only by collapsible whitespace and/or out-of-flow elements), splitting the inline box into two boxes (even if either side is empty), one on each side of the block-level box.
22:07:43 [fantasai]: RESOLVED: proposal above accepted
22:09:16 [fantasai]: http://wiki.csswg.org/spec/css2.1#issue-243http://lists.w3.org/Archives/Public/www-style/2011Mar/0180.html
22:09:21 [fantasai]: http://wiki.csswg.org/spec/css2.1#issue-243
22:09:24 [fantasai]: http://lists.w3.org/Archives/Public/www-style/2011Mar/0180.html
22:11:56 [fantasai]: RESOLVED: Proposal accepted.
22:12:43 [fantasai]: http://wiki.csswg.org/spec/css2.1#issue-227
22:13:39 [fantasai]: RESOLVED: fix error
22:13:47 [jdaggett]: jdaggett has joined #css
22:14:54 [dbaron]: http://wiki.csswg.org/spec/css2.1#issue-238
22:16:51 [fantasai]: RESOLVED: defer to CSS3 Fonts
22:16:55 [dbaron]: http://wiki.csswg.org/spec/css2.1#issue-246
22:18:47 [fantasai]: RESOLVED: defer to css3
22:18:50 [dbaron]: http://wiki.csswg.org/spec/css2.1#issue-249
22:21:10 [fantasai]: RESOLVED: next editorial revision
22:21:18 [dbaron]: http://wiki.csswg.org/spec/css2.1#issue-251
22:21:31 [fantasai]: RESOLVED: errata
22:21:46 [dbaron]: http://wiki.csswg.org/spec/css2.1#issue-258
22:22:58 [fantasai]: RESOLVED: Add note
22:23:04 [fantasai]: s/add/revise/
22:24:42 [fantasai]: http://lists.w3.org/Archives/Public/www-style/2011Jan/0074.html
22:25:02 [plinss_]: Note that COMMENT tokens cannot occur within other tokens:
22:25:02 [plinss_]: thus, "url(/*x*/pic.png)" denotes the URI "/*x*/pic.png",
22:25:02 [plinss_]: not "pic.png".
22:25:34 [fantasai]: CSS2.1 issues all resolved.
22:25:43 [fantasai]: s/issues/LC issues/
22:25:52 [sylvaing]: sylvaing has joined #css
22:25:56 [johnjan]: w00t
22:26:01 [fantasai]: plinss: Next is responding to all these emails and writing the disposition of comments
22:26:16 [johnjan]: Arron has one test case to discuss. IT's the last one though.
22:27:21 [fantasai]: block-in-inline-relpos-000
22:27:31 [Arron]: http://test.csswg.org/suites/css2.1/nightly-unstable/html4/block-in-inline-relpos-002.htm
22:28:28 [dbaron]: When an inline box contains an in-flow block-level box, the inline box (and its inline ancestors within the same line box) are broken around the block-level box, dividing the inline box into two pieces (even if either side is empty). The line boxes before the break and after the break are enclosed in anonymous block boxes, and the block-level box becomes a sibling of those anonymous boxes. When such an inline box is affected by relative positioning, the relati
22:28:29 [dbaron]: ve positioning also affects the block-level box contained in the inline box.
22:28:30 [dbaron]: in 9.2.1.1
22:36:06 [fantasai]: discussion of block-in-inline-relpos-002 and why it's failing and on which impls its failing
22:37:48 [homata_]: homata_ has joined #CSS
22:39:42 [fantasai]: Arron: Opera and WebKit fail because they don't move the block at all
22:39:50 [fantasai]: Arron: IE moves the floats
22:43:56 [fantasai]: dbaron and arron investigate
22:44:22 [fantasai]: fantasai thinks we should just make it undefined, and then spec whatever we have interop on later
22:44:29 [hyatt]: that's hard in webkit
22:44:35 [hyatt]: for our implementation to do
22:44:57 [hyatt]: since the block isn't contained inside the inline from a tree perspective
22:45:03 [hyatt]: so we lose the knowledge of the relative positioning
22:45:16 [hyatt]: other things won't work either like opacity
22:45:27 [hyatt]: i don't know maybe other browsers just hacked only relpositioning to work
22:45:32 [hyatt]: and didn't handle cases like opacity
22:45:38 [shonda]: shonda has joined #css
22:46:11 [fantasai]: fantasai: Let's make whether floats inside the relpos are translated be undefined
22:48:46 [fantasai]: ...
22:49:08 [fantasai]: dbaron: This might be the only test in the test suite that's testing this other really important concept that FF3.6 got wrong
22:49:31 [fantasai]: dbaron: Concept that if you have inlines, block, inlines, block, inlines you do two splits
22:50:00 [johnjan]: if we edited the test to only be that one part, would there be two passes?
22:51:27 [fantasai]: fantasai: This test uses out-of-flows, not inlines, in the middle of that sandwich
22:52:40 [fantasai]: dbaron: So the clarifying edit we made earlier this morning makes this testcase invalid
22:53:08 [fantasai]: fantasai: Didn't you change this testcase, it was originally matching the other interpretation
22:54:22 [Arron]: http://test.csswg.org/suites/css2.1/20110111/html4/block-in-inline-relpos-002.htm
22:54:31 [fantasai]: Arron: We have two passes on the old version of the test
22:55:42 [fantasai]: fantasai: dbaron, wrt our implementation, when bz and I split nsBlockFrame, changing this behavior call fall out of that refactoring. I don't think it will be hard.
22:55:51 [fantasai]: RESOLVED: Revert test, no changes to spec for block-in-inline-relpos
22:56:02 [fantasai]: plinss: So, who is going to help us respond to issues?
22:56:06 [johnjan]: There are now 24 edits remaining that are assigned to Bert (most very small). If both Arron and Elika help edit, along with helping write the disposition of comments, and getting the 9 blocking tests taken care of, it won't take very long at all.
22:56:28 [johnjan]: I can help as well (either edit or DOCs).
22:56:36 [johnjan]: but I would need to get permissions to edit.
22:56:52 [dbaron]: test reverted
22:56:56 [fantasai]: you probably don't want to edit :) but helping with responses / DOC would be nice
22:57:13 [fantasai]: dbaron: I had specific actions to respond to specific posts
22:57:25 [johnjan]: I definitely don't want to edit, but I want to help any way I can :-).
22:57:34 [johnjan]: David, I have you marked as having only one of those left.
22:57:43 [dbaron]: we need to link to responses in the wiki page
22:57:49 [johnjan]: issue 234
22:57:55 [dbaron]: (reverting of test is r1991)
22:58:32 [fantasai]: If, as you're responding to issues, you run across an editorial edit that we rejected, assign the issue to me
22:58:36 [fantasai]: =fantasai= respond
22:58:37 [Bert]: Most of the work wil be responding. Looks like the edits will take me half a day.
22:58:54 [fantasai]: That way I can fold those edits into a diff for the next revision
22:59:12 [Bert]: But getting you an edit account is a good idea anyway.
22:59:45 [szilles]: szilles has joined #css
22:59:59 [fantasai]: So plan is, Arron &co will respond to all substantive issues and any issus that were accepted
23:00:03 [bradk]: bradk has joined #css
23:00:05 [johnjan]: I agree Bert. Let's talk about that after the next conf call.
23:00:07 [fantasai]: fantasai will respond to editorial issues that were rejected
23:00:42 [johnjan]: Sounds like a good plan.
23:00:59 [johnjan]: When can we finish? (both the edits and the DOC) - tomorrow?
23:01:02 [johnjan]: Today?
23:01:06 [johnjan]: It's only 3 :-)
23:01:16 [fantasai]: Arron: Plan to finish by next conference call (in 3 weeks)
23:01:25 [fantasai]: johnjan, you are way enthusiastic :)
23:01:30 [fantasai]: s/3 weeks/2 weeks/
23:01:58 [fantasai]: When you respond to an issue, put a link to your response in the Wiki
23:02:11 [fantasai]: That's really important! we need it to compile the DoC
23:02:18 [fantasai]: Topic: Charter
23:02:23 [fantasai]: jdaggett: Charter is up March 31st
23:02:26 [johnjan]: I am enthusiastic, that's true. 2 weeks seems really late balanced against the expiration of our charter
23:03:09 [fantasai]: Steve: Given where we are, I'm sure the directory would be happy to extend the charter for 2 months or so
23:03:32 [fantasai]: jdaggett: So what's the status of the charter? Is Chris Lilley going to get to it? Do we have a Plan B?
23:03:39 [fantasai]: jdaggett: Can Bert help?
23:03:51 [fantasai]: jdaggett: We have a draft, and we have a proposal, and it needs editing.
23:04:06 [fantasai]: Bert: Chris is on holiday this week. He was supposed to have a draft ready
23:04:16 [fantasai]: Bert: But he hasn't sent it yet
23:04:34 [fantasai]: jdaggett: Can we give him a specific deadline to send it?
23:04:45 [fantasai]: jdaggett: And have somebody else take over if he can't do it?
23:05:08 [fantasai]: RESOLVED: Discuss new charter at next telecon
23:05:24 [fantasai]: Topic: CSS3 Text
23:06:20 [johnjan]: I'm really hoping we can get the DOC and edits done in less than two weeks.
23:06:39 [johnjan]: Why not schedule a 'special conf call' to get this done.
23:07:05 [johnjan]: we just did some amazing work over the last three days to get here, and I hate to lose that momentum.
23:07:47 [fantasai]: johnjan, a lot of people are going to be at sxsw,
23:08:07 [Bert]: I'll the edits done before next Wednesday, with an updated (public) editor's draft.
23:08:23 [Bert]: I'll *have*
23:09:23 [johnjan]: even better. Then we're all in the same time zone (except glazou apparently). :-)
23:10:03 [TabAtkins_]: Topic: CSS3 Text
23:10:18 [TabAtkins_]: fantasai: There's a bunch of marked issues, so we'll scroll through them and try to resolve.
23:10:23 [smfr]: http://dev.w3.org/csswg/css3-text/
23:11:00 [TabAtkins_]: fantasai: For text-transform, we're adding "fullwidth" and "large-kana".
23:11:05 [TabAtkins_]: fantasai: [explains the two values]
23:11:40 [TabAtkins_]: jdaggett: I think the name here is bad.
23:11:55 [TabAtkins_]: jdaggett: "large" implies incorrect size - there's really just "normal" and "small" kana.
23:12:05 [TabAtkins_]: jdaggett: I think "fullsized-kana" would be better.
23:12:31 [johnjan]: final comment on it from johnjan: I propose that if Bert is able to get the edits done by next wed and Elika finds time during SXSW to do her part, we have the conf call next wed. I realize it's a long shot.
23:12:37 [johnjan]: And I'll be quiet now.
23:13:00 [TabAtkins_]: jdaggett: You're sort of pointing at various unicode documents, and there's too much ambiguity.
23:13:04 [TabAtkins_]: fantasai: What's the delta you want?
23:14:19 [TabAtkins_]: jdaggett: Frex, for fullwidth, this should probably only apply to the chars in the Unicode database marked with Y, and only to letters and numbers.
23:14:24 [TabAtkins_]: fantasai: Okay.
23:14:37 [dbaron]: letters and numbers, and not punctuation and whitespace.
23:14:48 [TabAtkins_]: jdaggett: the idea is that you want to take text that appears with halfwidth chars in horizontal text, and do fullwidths in vertical text.
23:15:32 [TabAtkins_]: jdaggett: So (1) have a specific algorithm, identifying the characters this should apply to
23:15:44 [TabAtkins_]: kojiishi: It's already defined in unicode, right?
23:15:54 [arno]: arno has joined #css
23:15:58 [TabAtkins_]: jdaggett: A lot of things are defined in unicode. We need to be specific about what is being talked about here.
23:16:17 [TabAtkins_]: jdaggett: I don't think you want *all* halfwidths to change to fullwidth - only letter and numbers, not punctuation and whitespace
23:16:29 [TabAtkins_]: kojiishi: No, we want all halfwidths to map to fullwidth
23:16:50 [TabAtkins_]: kojiishi: primary use-case is use in vertical text flow, to ensure that every alphabetic and punctuation character to take up the full sapce
23:17:47 [TabAtkins_]: jdaggett: Unicode doesn't define the transformation algorithm, it just identifies the classes. You need to define the transform.
23:17:58 [TabAtkins_]: jdaggett: If you want to transform all of them, then say so explicitly.
23:18:24 [TabAtkins_]: fantasai: So you want a codepoint-to-codepoint transformation algorithm. I'll mark an issue about it.
23:18:53 [TabAtkins_]: szilles: I'd like a note about this, because I wouldn't think a priori that you'd transform whitespace and punctuation.
23:18:56 [TabAtkins_]: jdaggett: Yes.
23:19:10 [TabAtkins_]: kojiishi: What's the use-case? I've done some interviews in Japan, and nobody has requested different treatment for those classes.
23:19:26 [TabAtkins_]: jdaggett: When you're going between horizontal and vertical, you want the fullwidth in vert.
23:19:46 [TabAtkins_]: jdaggett: Ideally we want the author to write using the standard codepoints, but it displays with teh fullwidth forms in vertical text.
23:20:21 [TabAtkins_]: jdaggett: But if you mark a span with this, and it transforms the punctuation, but other parts of your text aren't being transformed, it'll be different.
23:20:36 [TabAtkins_]: fantasai: I think the question of which should be done is a question for the jlreq people, not us.
23:20:59 [fantasai]: jdaggett's concern is that punctuation forms won't match between fullwith and halfwidth forms used in the same paragraph
23:21:11 [TabAtkins_]: szilles: Under orientation, we said upright.
23:21:28 [TabAtkins_]: fantasai: Right, but it doesn't change the glyph shape or the linebreaking behavior.
23:21:45 [TabAtkins_]: fantasai: If you don't want the changed shape and behavior, just use text-orientation.
23:22:22 [TabAtkins_]: fantasai: [gives use-case for why both options are useful]
23:22:38 [TabAtkins_]: szilles: But in Korean they're happy breaking arbitrarily
23:22:49 [TabAtkins_]: fantasai: That's handled with word-break, for breaking arbitrarily in normal text
23:22:56 [TabAtkins_]: fantasai: But that won't get you fullwidth glyph shapes.
23:25:21 [TabAtkins_]: [discussion about use-cases]
23:26:51 [dsinger]: dsinger has joined #css
23:27:05 [TabAtkins_]: jdaggett: So, last comment, this just needs to be tightened up a lot.
23:28:07 [TabAtkins_]: fantasai: In whitespace processing, the issue is control characters.
23:28:36 [TabAtkins_]: fantasai: Ones other than tab, line feed, space, and bidi formatting chars, 2.1 says to treat them as characters to render in the same way as normal chars.
23:28:42 [TabAtkins_]: fantasai: But what does that mean?
23:28:53 [TabAtkins_]: jdaggett: Render as missing character if it doesn't exist.
23:29:07 [TabAtkins_]: Arron: Almost all browsers treat them as zero-width characters.
23:30:16 [TabAtkins_]: fantasai: So I have three options
23:30:26 [TabAtkins_]: fantasai: (1) render them as unknown chars if the font doesn't have them
23:30:40 [TabAtkins_]: fantasai: (2) treat them as zero-width all the time
23:30:46 [TabAtkins_]: fantasai: (3) Allow both
23:31:06 [TabAtkins_]: dbaron: If so, you should be explicit in what char classes you're talking about.
23:31:13 [TabAtkins_]: Arron: I would prefer zero-width.
23:31:39 [TabAtkins_]: szilles: I'd prefer something that makes it not useful for people to have put them in.
23:31:50 [dbaron]: Seems to be character class Cc
23:31:52 [TabAtkins_]: szilles: Rendering them as zero-width has *some* use, but it's close enough to useless.
23:32:17 [TabAtkins_]: fantasai: Okay, (2) it is.
23:32:37 [TabAtkins_]: fantasai: Next is white-space-collapsing property
23:32:43 [TabAtkins_]: fantasai: In a lot of flux
23:33:41 [TabAtkins_]: fantasai: I think we'll probably wind up dropping down to just the first four values, but I've temporarily got a larger list to collect ideas.
23:33:47 [TabAtkins_]: fantasai: The main issue for me is that I think the name sucks.
23:34:27 [TabAtkins_]: szilles: Was this inherited from XSL?
23:34:31 [TabAtkins_]: fantasai: This is different.
23:34:34 [TabAtkins_]: szilles: Why is
23:34:43 [TabAtkins_]: szilles: Why is 'collapse' better than 'collapsing'?
23:34:51 [TabAtkins_]: fantasai: Parallel naming with our other properties.
23:37:19 [TabAtkins_]: [name bikeshedding]
23:37:52 [fantasai]: RESOLVED: rename white-space-collapsing to bikeshedding
23:38:18 [stearns]: :)
23:39:16 [TabAtkins_]: szilles: I think tab-size is a bad idea.
23:39:28 [TabAtkins_]: jdaggett: Wait, this is for tab-stops, not a transform on tabs themselves?
23:40:37 [TabAtkins_]: bradk: Can we implement a length?
23:40:52 [TabAtkins_]: dbaron: It would be trivial to use a length.
23:41:53 [TabAtkins_]: Bert: Why do we need this?
23:42:05 [TabAtkins_]: TabAtkins_: Because tabs in preformatted text are super-huge by default.
23:43:22 [dbaron]: https://bugzilla.mozilla.org/show_bug.cgi?id=517882
23:43:22 [TabAtkins_]: glazman: I'll use this immediately in my source-view of my editor.
23:43:41 [glazou]: glazou has joined #css
23:44:46 [TabAtkins_]: dbaron: For the record, Moz implemented this to change the size of tabs in our view-source
23:44:47 [Bert]: (It's useful to have tab stops and align the start of a SPAN to it, e.g., in a ToC, but tab-size won't do that.)
23:45:12 [TabAtkins_]: fantasai: Now, 'line-break'.
23:45:19 [TabAtkins_]: fantasai: [describes the values]
23:45:47 [TabAtkins_]: szilles: How do you get interop on these?
23:45:58 [TabAtkins_]: fantasai: There are recommendations, but it doesnt' cover all cases.
23:46:19 [TabAtkins_]: fantasai: We don't cover line-breaking anyway, which is apparently okay, and I'm not going to solve this problem by June.
23:46:22 [Arron]: I think tab-stop should allow '0' as a valid value
23:46:27 [TabAtkins_]: szilles: How will you exit CR?
23:46:36 [TabAtkins_]: fantasai: There's enough there to test, and the rest is undefined.
23:46:41 [TabAtkins_]: fantasai: [describes word-break]
23:47:31 [TabAtkins_]: fantasai: We may drop the 'keep-words' value.
23:47:40 [TabAtkins_]: fantasai: [describes the hyphenation property]
23:48:59 [TabAtkins_]: smfr: [question about displaying soft hyphens in an editting environment]
23:49:06 [TabAtkins_]: fantasai: I think we should drop the 'all' value.
23:49:31 [TabAtkins_]: fantasai: Or I can mark this as at-risk.
23:49:48 [TabAtkins_]: szilles: Does this show the soft-hyphens, or what the dict would have given me as hypenation opportunities?
23:49:51 [TabAtkins_]: fantasai: Both.
23:49:57 [TabAtkins_]: szilles: And I can't tell which is which?
23:49:59 [TabAtkins_]: fantasai: Right.
23:50:14 [TabAtkins_]: fantasai: Okay, I'm marking as at-risk.
23:50:28 [TabAtkins_]: fantasai: Now, hyphenate-character property.
23:50:37 [TabAtkins_]: fantasai: Do we need the second hyphenation character?
23:50:53 [TabAtkins_]: szilles: I thought there was osme language where the "beginning of line" hyphenation char is used.
23:51:02 [TabAtkins_]: fantasai: I dunno, I don't have any examples of it being used.
23:51:25 [TabAtkins_]: Bert: This may have come from some languages where, when you break words, you replace certain characters. But that's a different concept.
23:51:50 [homata]: homata has joined #CSS
23:51:55 [TabAtkins_]: fantasai: Okay, I'm dropping the second character.
23:52:07 [TabAtkins_]: fantasai: [describes the hyphenate-limit properties]
23:52:40 [TabAtkins_]: jdaggett: Are these different ways of controlling hyphenation? Would you use these all together?
23:52:46 [TabAtkins_]: fantasai: No idea. They are indeed different, though.
23:53:55 [stearns]: I think they would be used together
23:54:32 [TabAtkins_]: jdaggett: Trying to understand the algorithm here.
23:54:44 [TabAtkins_]: jdaggett: Where's the language sensitivity, and where's the dictionary come from?
23:54:47 [TabAtkins_]: fantasai: That's further down.
23:55:16 [stearns]: you might only specify one or two that you're really concerned with, but some authors would apply values for all
23:55:25 [TabAtkins_]: bradk: Can we combine the hyphenate-limit properties into one?
23:55:41 [TabAtkins_]: fantasai: I think -zone should be separate, but -before and -after are combinable.
23:56:38 [johnjan]: I don't think they should be combined. I don't know why you would ever want them combined.
23:56:44 [TabAtkins_]: fantasai: There was a proposal on the list to add a hyphenate-limit-* property that would limit the length of the word.
23:57:07 [johnjan]: That was from Christian Stockwell, a PM on the IE team.
23:57:54 [johnjan]: ah, like hyphenate-limit: 4 5; ?
23:59:21 [fantasai]: jdaggett: asks what the priority is among the various limit properties
23:59:22 [TabAtkins_]: [discussion about how the properties work together]
23:59:38 [fantasai]: fantasai, plinss: The limits combine: as soon as one limit applies, you can't break there
23:59:53 [fantasai]: jdaggett: Is that good enough? Do we need priorities of some kind?
00:00:00 [fantasai]: jdaggett: Would that overconstrain?
00:00:03 [fantasai]: Steve: ...
00:00:10 [fantasai]: Steve: In practice it doesn't overconstrain
00:00:50 [fantasai]: fantasai^: There was also a proposal on www-style for a control to limit the size of the word that gets hyphenated, so for example if I set that to 5, "modal" would not break
00:00:54 [fantasai]: but "unconditional" would
00:01:04 [fantasai]: ...
00:01:09 [stearns]: that would be quite useful
00:01:28 [fantasai]: Alex: Knuth's paper says that once you do optimial paragraph breaking, the hyphenation controls don't really make much of a differenc
00:01:31 [fantasai]: e
00:03:55 [johnjan]: I think optimal paragraph is orthogonal to this conversation.
00:04:18 [TabAtkins_]: [argument about whether to combine -before and -after]
00:04:36 [stearns]: could combine minimum, before and after
00:05:24 [stearns]: I don't know of a use case where one would vary while keeping the others set
00:06:37 [fantasai]: dbaron: I don't think other systems have the same concept of properties that CSS has
00:09:22 [fantasai]: ScribeNick: fantasai
00:10:02 [fantasai]: ScribeNick: TabAtkins_
00:10:35 [fantasai]: plinss: I think we should combine them and mark it as an issue. If someone responds with a use case and says "no I really want them separate", then we split them again
00:10:44 [fantasai]: fantasai: Should we include the word limit in there?
00:11:02 [fantasai]: arron: The word limit sounds very useful
00:11:21 [stearns]: If we do, a suggested value for 'auto' is 5, going by InDesign's defaults
00:11:25 [TabAtkins_]: <br duration=10min>
00:11:31 [johnjan]: I've been trying to come up with a use case, but have not been able to. It feels weird to me, but I'm ok with combining.
00:11:42 [bradk]: bradk has joined #css
00:12:07 [johnjan]: InDesign's default sounds good. (for word limit, right?)
00:12:14 [stearns]: right
00:13:48 [johnjan]: I believe my use case is to set word limit, before and after to consistent values, so it's highly unlikely one would change at all, let alone independent of the others.
00:16:01 [fantasai]: Arron: It would be nice to put a note that
00:16:14 [fantasai]:  in a word disables auto-hyphenation in favor of that breakpoint
00:16:27 [fantasai]: since that would be the best way to do word-by-word tweaks
00:16:45 [stearns]: ^
00:17:22 [johnjan]: also explicit hypens would disable auto-hypenation as well. (in addition to )
00:17:53 [fantasai]: johnjan: I'm less sure of that
00:17:59 [fantasai]: s/:/,/
00:18:08 [fantasai]: johnjan, since hyphens are part of the spelling of a word
00:18:15 [fantasai]: johnjan, they're not there to control hyphenation
00:19:26 [johnjan]: if I use the word 'auto-hypenate' (even if I say limit-before: 6;) I'd expect you to break on auto-
00:19:42 [johnjan]: s/hypenate/hyphenate
00:21:35 [stearns]: back to hyphenate-character, unicode.org mentions the possibility of putting a hyphen at the beginning of the line, but does not provide an example
00:21:54 [stearns]: http://unicode.org/reports/tr14/tr14-14.html
00:26:06 [johnjan]: < leaving to catch a bus
00:26:33 [stearns]: Another possible note could be that  at the beginning of a word disables hyphenation altogether for that word
00:26:34 [bradk]: bradk has joined #css
00:26:52 [bradk]: test 123
00:27:02 [fantasai]: hyphenation-limit-word
00:27:42 [fantasai]: fantasai: So question on hyphenation-limit-zone was should it be relative to line box or block?
00:27:51 [fantasai]: howcome: Line box
00:28:07 [fantasai]: RESOLVED: Make percentages on hyphenation-limit-zone relative to line box
00:28:39 [TabAtkins_]: fantasai: We also talked about -before and -after, and someone suggested a minimum word length as well.
00:28:56 [TabAtkins_]: fantasai: [explains why this can't just be done through -zone]
00:29:46 [TabAtkins_]: howcome: Christian proposed something that sounded like -zone.
00:30:03 [TabAtkins_]: fantasai: [draws a pretty picture explaining why you can't do it through -zone]
00:30:07 [bradk]: hyphenation-limit-chars:<before> <min> <after>
00:31:57 [bradk]: hyphenation-limit-character-count:<before> <min> <after>
00:32:30 [TabAtkins_]: Bert: -zone sounds like it may be capturing the wrong concept - you want something that measures more the tension imposed by justification - with less spaces, you should be stricter about pulling words up.
00:33:11 [TabAtkins_]: fantasai: I think that'll be much harder to calculate.
00:33:31 [TabAtkins_]: Bert: Doing -zone assumes that every line has about the same number of spaces, which may not be the case.
00:33:35 [TabAtkins_]: fantasai: Yes.
00:34:31 [TabAtkins_]: Bert: Also, if on the preceding line all the spaces were stretched, you don't want to shrink the next line's spaces.
00:34:43 [bradk]: I think all these properties should begin with hyfN8- instead of hyphenation- so that we don't have to type as much.
00:34:50 [stearns]: ideally it should be relative to the line's measure (how many characters fit). I would specify using ems
00:35:04 [fantasai]: stearns, we have % defined to do that
00:35:10 [TabAtkins_]: howcome: This gets into the micro-typography issue that we don't want to get into, too, where you might want to change the shape of letters to better fit things to the line.
00:35:12 [fantasai]: % is relative to the size of the line
00:35:19 [fantasai]: s/size/measure/
00:36:20 [stearns]: hy8n - hy(8 characters)n
00:36:21 [TabAtkins_]: Bert: Perhaps the badness-factor can be captured with the number of spaces in the line, and the number of successive hyphenated lines.
00:37:08 [TabAtkins_]: fantasai: This sounds very complicated. For now let's just keep the hyphens property.
00:37:14 [TabAtkins_]: fantasai: And maybe drop the rest for now.
00:37:58 [TabAtkins_]: howcome: I was happy with the state of this section at the time it transferred into this draft.
00:38:21 [fantasai]: fantasai: we could mark everything at risk and see what ppl implement
00:38:34 [TabAtkins_]: howcome: About hyphenate resource, it seems there are two formats.
00:38:49 [TabAtkins_]: howcome: Kew has done some work cleaning up the dictionaries used.
00:38:55 [TabAtkins_]: howcome: There is a set of freely-available dictionaries.
00:39:02 [TabAtkins_]: howcome: The format isn't described anywhere.
00:39:42 [TabAtkins_]: howcome: They're derived from TeX macros.
00:39:56 [TabAtkins_]: howcome: Does Apple have their own format?
00:40:00 [dbaron]: he was trying to clean them up so they didn't depend on TeX macros
00:40:10 [fantasai]: s/macros/'s format, without the macros/
00:40:15 [TabAtkins_]: smfr: We use built-in system resources, but don't plan on implementing hyphenation-resource soon.
00:40:44 [TabAtkins_]: smfr: I think we just purely go off the lang of the element.
00:40:56 [TabAtkins_]: howcome: Yeah, often you want to attach this to lang.
00:41:11 [TabAtkins_]: howcome: Though often when comparing content that's hyphenated, you want to compare different dictionaries.
00:41:37 [TabAtkins_]: howcome: What I'm arguing against is to hinge this off the @lang attribute.
00:42:22 [TabAtkins_]: howcome: If you're laying out a book, frex, you want to lay it out, same content, with two different hyphenations and compare.
00:42:39 [TabAtkins_]: TabAtkins_: Since you're just debugging, can't you just tag one with a bogus language or something?
00:42:56 [TabAtkins_]: jdaggett: What about topic-specific things?
00:43:12 [TabAtkins_]: szilles: And shouldn't you want to key it off of lang?
00:43:32 [TabAtkins_]: howcome: Yes, definitely, so by default authors should use :lang(). They just shoulnd't be limited to only using :lang().
00:43:43 [TabAtkins_]: smfr: I think it's okay for CSS to point to a dict, as long as we agree on a description of the format.
00:43:57 [TabAtkins_]: smfr: We're fine with the built-in resources for now, though.
00:44:14 [TabAtkins_]: jdaggett: I suspect you'll need it when, say, iBooks needs to display a medical textbook.
00:45:34 [TabAtkins_]: fantasai: [something about formats]
00:45:47 [TabAtkins_]: jdaggett: Just glancing over the TeX dict, it looked like there were some subtle important details in there.
00:46:27 [TabAtkins_]: jdaggett: Didn't AH point to a TeX dictionary?
00:46:40 [TabAtkins_]: jdaggett: If you follow the indirections in their reference, it's TeX-based.
00:47:25 [fantasai]: Do we want to use a format key, like @font-face? Because a lot of these formats are similar but not quite the same, so if you tried doing content-sniffing, you'd probably slurp up the dictionary and choke on something later because it's not quite the format you expected.
00:47:31 [TabAtkins_]: howcome: The TeX algorithm is widely described, and there are impls of it.
00:47:43 [TabAtkins_]: jdaggett: If it's a straightforward thing for someone to look at the format and implement, that's fine.
00:48:15 [TabAtkins_]: howcome: [comment about the format describing weights]
00:48:23 [TabAtkins_]: jdaggett: Right, and that makes implications about how to implement it.
00:48:33 [TabAtkins_]: howcome: I think a reference to TeX would be okay.
00:48:50 [TabAtkins_]: jdaggett: Without a format and the semantics for it defined, this entire property can't be interoperable.
00:49:09 [TabAtkins_]: howcome: You could similarly argue for OT, which has parts that aren't well-described.
00:49:23 [TabAtkins_]: jdaggett: You're talking about language handling? Yeah, but that's just specific areas of OT, not the entire spec itself.
00:50:07 [TabAtkins_]: howcome: I think if we try to describe this directly, instead of just referring to TeX, it'll be a lot of work.
00:50:23 [TabAtkins_]: szilles: So you're proposing we referenc the spec. Is it a book, or a stable website, or...?
00:50:34 [dbaron]: http://www.tug.org/docs/liang/
00:50:44 [TabAtkins_]: howcome: It's called [TeX algorithm], and it's published in a collection of algorithms called "Digital Typography".
00:51:02 [TabAtkins_]: szilles: The general rule is that references must be a public document that people can follow.
00:51:11 [TabAtkins_]: howcome: It's a research paper.
00:51:22 [TabAtkins_]: szilles: That's probably okay. I just suggest you do the homework to get us that reference.
00:51:33 [bradk]: open office has this list that includes teX based hyphenation dictionaries: http://wiki.services.openoffice.org/wiki/Dictionaries
00:51:55 [TabAtkins_]: fantasai: So the format we're standardizing on is the TeX hyphenation format, along with macros?
00:51:58 [TabAtkins_]: howcome: Not macros.
00:52:07 [TabAtkins_]: fantasai: Okay, then we need to specify that.
00:52:19 [TabAtkins_]: howcome: Okay. But this should be a soft recommendation, not a strict requirement.
00:52:40 [TabAtkins_]: fantasai: Okay, we just need a way to specify what exactly is being requested to be implemented.
00:52:47 [bradk]: GNU LGPL license is OK for hyphenation dictionaries?
00:53:05 [TabAtkins_]: jdaggett: If we're describing something where every impl uses their own format, we should just throw out this property and let UAs do what they want.
00:53:28 [TabAtkins_]: howcome: I think we just need to put into writing the principles used when Kew & others were cleaning up the TeX files.
00:54:06 [TabAtkins_]: smfr: Another problem - you'll get a flash of unhyphenated text before the dict is downloaded, and people may want control over the timeout here.
00:54:15 [TabAtkins_]: howcome: We've discussed this relative to font-face, right?
00:54:17 [TabAtkins_]: smfr: Yes.
00:54:32 [fantasai]: ACTION howcome Come up with a precise spec (reference or reference + prose) for the hyphenation format
00:54:33 [trackbot]: Created ACTION-313 - Come up with a precise spec (reference or reference + prose) for the hyphenation format [on Håkon Wium Lie - due 2011-03-17].
00:54:39 [TabAtkins_]: howcome: I think we decided then not to do anything, and we shouldn't do anything here.
00:54:58 [TabAtkins_]: howcome: If you're concerned, you could just download the dicts in the stylesheet before displaying anything.
00:55:04 [TabAtkins_]: Arron: No, they can take a long time.
00:55:12 [TabAtkins_]: fantasai: I think it should be an impl pref.
00:55:17 [fantasai]: s/impl/user/
00:55:19 [TabAtkins_]: howcome: I agree; it's a user thing.
00:56:31 [TabAtkins_]: fantasai: next is whether to do @hyphenate-resource or 'hyphenate-resource'. Advantage of former is less storage, and maybe more intelligent langauge mapping.
00:57:06 [TabAtkins_]: fantasai: [shows example of using multiple dicts in @hy-res]
00:57:50 [TabAtkins_]: jdaggett: I think the common case is authors within a single language needing multiple dicts for specialized texts.
00:58:11 [TabAtkins_]: fantasai: Right, you can juts provide multiple dictionaries, so medical texts would have words in the first dict.
00:58:51 [TabAtkins_]: fantasai: The issue here is how you bind the dict to the element.
00:59:51 [TabAtkins_]: howcome: Impls, if there isn't a value for the prop on an element, they don't use space for it.
00:59:54 [TabAtkins_]: fantasai: Yes they do.
01:00:34 [TabAtkins_]: howcome: Not a ton of space.
01:00:51 [TabAtkins_]: plinss_: Is there a need to specify a dict on a per-element basis?
01:00:57 [TabAtkins_]: howcome: Yes, for example when debugging.
01:01:46 [fantasai]: Tab: Debugging doesn't need to be elegant, just possible.
01:01:59 [TabAtkins_]: szilles: I think there are valid reasons to use different technical dicts on different things in the same language.
01:02:04 [TabAtkins_]: fantasai: Generally you'd just concat the dictionaries.
01:02:20 [TabAtkins_]: fantasai: Only case wher eyou need per-element is when you want to hyphenate a single word differently based on the context.
01:02:34 [TabAtkins_]: fantasai: You can soft-hyphenate that, or specify it as a variant language.
01:03:07 [TabAtkins_]: szilles: I guess I can live with it, because I can't think of any othe property to control hyphenation with.
01:03:18 [TabAtkins_]: szilles: Besides, you can open separate windows anyway (for debugging).
01:03:53 [TabAtkins_]: howcome: I just think it's too much of a restriction to key off the lang.
01:04:04 [TabAtkins_]: fantasai: You want the @lang anyway, so UAs can do lang-specific stuff anyway.
01:04:51 [TabAtkins_]: howcome: Medical, technical things.
01:05:22 [TabAtkins_]: plinss_: I think if you can find examples where you actually need this, find them and bring them back in.
01:05:39 [TabAtkins_]: howcome: We already have impls. Why are we changing this?
01:06:04 [TabAtkins_]: fantasai: Space savings, frex. @-rule is relative to the size of the table only, while another per-element rule is more memory per element.
01:06:46 [TabAtkins_]: [discussion about how much space would be saved]
01:06:53 [stearns]: as far as I know, medical and legal dictionaries are more about spelling than hyphenation
01:07:07 [TabAtkins_]: smfr: I thought @hy-res would be like @font-face, which would describe the resource only, and then we link it to elements.
01:07:29 [TabAtkins_]: fantasai: The reason you fold them together is because there's generally no need for the additional targetting.
01:09:09 [TabAtkins_]: howcome: You don't necessarily want to run through every dictionary to hyphenate normal words.
01:09:44 [TabAtkins_]: TabAtkins_: Do we actually think that imlementing hyphenation is going to involve walking a linear list for every word?
01:10:00 [TabAtkins_]: dbaron: [talking about the dict format that TeX uses]
01:10:13 [dbaron]: at least as documented in http://www.tug.org/docs/liang/
01:11:41 [TabAtkins_]: [architectural argument about property vs @-rule]
01:12:31 [TabAtkins_]: howcome: We already have implemenations, Prince does it with the property.
01:12:38 [TabAtkins_]: kojiishi: I dunno what AH does.
01:12:47 [TabAtkins_]: jdaggett: What does Adobe think about this?
01:12:54 [TabAtkins_]: szilles: I've sent an email to try and find an answer.
01:13:12 [TabAtkins_]: szilles: My belief is that we're lacking somewhat in experience in the room for some of these questions.
01:13:39 [TabAtkins_]: jdaggett: Okay. i think it would be useful ot have feedback from adobe
01:13:58 [TabAtkins_]: szilles: Yes. And MS, too, as they have publishing stuff.
01:14:10 [fantasai]: fantasai: btw, Antenna House supports custom dictionaries, but not via hyphenation-resource
01:15:04 [TabAtkins_]: plinss_: We have spent too much time on this, and aren't coming to a conclusion. We need to table this for now and come back with information later.
01:15:53 [TabAtkins_]: plinss_: We'll leave this open for now.
01:16:06 [TabAtkins_]: fantasai: Next is 'text-wrap'
01:16:22 [TabAtkins_]: fantasai: I can't find a usecase for 'unrestricted' so far. Thinking of removing it.
01:16:56 [TabAtkins_]: dbaron: How is this different from word-wrap: break-word?
01:17:08 [TabAtkins_]: fantasai: That's only for emergency breaking. This is all-the-time breaking.
01:17:20 [TabAtkins_]: dbaron: Might be useful for ancient greek or roman, but I don't think I care.
01:17:34 [fantasai]: plinss: Might be useful for URLs
01:17:47 [TabAtkins_]: dbaron: That's emergency breaking, with word-wrap.
01:18:29 [TabAtkins_]: bradk: How does this interact with white-space?
01:18:40 [TabAtkins_]: fantasai: white-space is now a shorthand property for text-wrap and white-space-collapse
01:19:06 [johnjan]: johnjan has joined #css
01:20:01 [TabAtkins_]: szilles: It would be nice to point out that one of the line-breaking rules was controlled by the word-break property.
01:20:11 [TabAtkins_]: fantasai: i can point that out.
01:20:48 [fantasai]: RESOLVED: drop unrestricted value from text-wrap
01:21:09 [TabAtkins_]: fantasai: next is the word-wrap property. This is emergency-wrapping.
01:21:40 [TabAtkins_]: fantasai: We could add a 'hyphenate' value that turns on hyphenation only for emergency breaking.
01:21:54 [TabAtkins_]: smfr: If word-wrap breaks a word, do you insert a hyphen?
01:22:32 [TabAtkins_]: fantasai: Not with break-word. Yes with theoretical hyphenate value.
01:22:58 [TabAtkins_]: Arron: If the hyphen isn't selectable, I think the 'hyphenate' value is okay.
01:23:49 [TabAtkins_]: bradk: Seems to be confusing with word-break and this.
01:24:01 [TabAtkins_]: fantasai: Seems that way only because of the names. This should be called 'emergency-wrap'
01:24:07 [TabAtkins_]: (Emergency rap)
01:24:20 [smfr]: in-case-of-emergency-wrap-word
01:24:26 [TabAtkins_]: (For when you absolutely need to stop and hammer-time.)
01:24:49 [TabAtkins_]: plinss_: Did this property go to CR?
01:25:10 [TabAtkins_]: fantasai: No, but there are tons of unprefixed impls unfortunately.
01:25:19 [TabAtkins_]: dbaron: I think IE had this since IE4...
01:25:30 [dbaron]: IE4 or something else old
01:26:16 [TabAtkins_]: fantasai: other question is whether to have a keyword that starts turning off the break restrictions in emergency.
01:26:51 [TabAtkins_]: fantasai: Usually you want to break when absolutely necessary, but if you really really want overflow...
01:27:16 [TabAtkins_]: szilles: 'hyphenate' makes sense, because it just says "if you can do a better-than-arbitrary job, do so"
01:28:06 [fantasai]: arron: note in the spec that hyphenation hyphen isn't selectable
01:28:43 [TabAtkins_]: bradk: I can't think of when you'd want 'none'.
01:29:25 [TabAtkins_]: fantasai: It's when, frex, you have hyphenation turned on, but limits are preventing a break. 'normal' would relax these limits, but maybe you want to still honor them.
01:29:47 [TabAtkins_]: [talk about priority]
01:30:09 [TabAtkins_]: resolved: add 'hyphenate', don't add 'none'
01:30:17 [TabAtkins_]: fantasai: next is text-align
01:30:39 [TabAtkins_]: fantasai: There was request to specify first line separately from rest, for spanish poetry, for example
01:31:05 [TabAtkins_]: dbaron: We're doing first-line align in text-aling, but last-line in a new property?
01:31:13 [TabAtkins_]: fantasai: yes, because... [trails off]
01:31:22 [TabAtkins_]: szilles: We can do this with ::first-line
01:31:29 [TabAtkins_]: fantasai: Ooh, maybe.
01:32:49 [fantasai]: fantasai: Ok, so the problem with that is
01:33:12 [fantasai]: fantasai: 1. The primarily alignment is the first-line alignment, the rest of the lines wrapping around are a fallback case.
01:34:15 [fantasai]: fantasai: If you specify text-align: end; text-align-first: start; then old UAs end align everything, which is not what you want
01:34:50 [fantasai]: fantasai: 2. Other issue is that this affects the first line and every line after a hard break: only wrapped lines get the fallback alignment
01:35:10 [TabAtkins_]: fantasai: Also, I pulled in <string> alignment.
01:35:24 [TabAtkins_]: jdaggett: I don't see a good use-case for <string> alignment
01:35:48 [TabAtkins_]: dbaron: This makes the table-width calculation algorithm substantially more expensive.
01:36:28 [TabAtkins_]: smfr: You want to align the decimal point to a length, not necessarily the center, right?
01:36:45 [TabAtkins_]: dbaron: In most cases, the whole column will have this, and so it won't matter - then its width will be shrink-to-fit.
01:37:08 [TabAtkins_]: fantasai: And I put the default to be right-align
01:37:33 [TabAtkins_]: dbaron: Often in tables you'll have a long header, and then many short numbers which should be aligned and centered.
01:37:44 [TabAtkins_]: fantasai: You can do that by also specifying 'center'.
01:38:53 [TabAtkins_]: plinss_: If there are multiple instances of the string, which is aligne?
01:38:57 [TabAtkins_]: fantasai: The first one.
01:39:44 [TabAtkins_]: szilles: Particularly the "N/A" in the example is very useful, and matches what spreadsheets do.
01:39:58 [TabAtkins_]: dbaron: This affects preferred width of table columns. Open question of whether it should affect min-width, and how.
01:40:58 [TabAtkins_]: fantasai: I think the cost there becomes a CR issue - if people don't implement due to this, we'll drop it.
01:41:04 [TabAtkins_]: fantasai: But I think this is well-specified and good.
01:41:25 [TabAtkins_]: dbaron: [describes passage in his intrinsic-with paper concerning this]
01:41:41 [TabAtkins_]: dbaron: I don't think you can compute a min-width.
01:41:50 [TabAtkins_]: dbaron: I think the dfn is wrong in the case where there's not enough room.
01:42:00 [TabAtkins_]: dbaron: I think your def assumes there is enough room to do the alignment.
01:42:13 [TabAtkins_]: dbaron: If may be there is no wrapping of text, but simultaneously not enough room to align all of it.
01:42:37 [TabAtkins_]: fantasai: Spec says that in that case the alignment is undefined.
01:43:09 [TabAtkins_]: szilles: Undefined, or stop aligning?
01:43:30 [TabAtkins_]: dbaron: You'd prefer continuous behavior when possible, not just it suddenly dropping the alignment when the cell gets too small.
01:44:27 [TabAtkins_]: [discussion about min-width support on cells]
01:46:12 [TabAtkins_]: dbaron: Maybe the min-width computation needs even more controls...
01:46:44 [TabAtkins_]: howcome: I'd like to talk about match-parent.
01:46:52 [TabAtkins_]: howcome: Seems like a slim use-case.
01:46:56 [TabAtkins_]: fantasai: No, it's significant.
01:47:23 [TabAtkins_]: fantasai: Say you have a list, or <select>, and they're mixed direction, typically you want them all aligned to a consistent side, based on the nearest lang.
01:47:50 [dbaron]: It would split pref-width into three different values (pref before alignment, pref of alignment marker (zero when none present), and pref after alignment)
01:48:01 [TabAtkins_]: fantasai: So 'match-parent' is like 'start', but computes against the parents direction, and computes to 'left' or 'right' to keep children on the same side.
01:48:09 [dbaron]: and it would split min-width into four, those three for cells that are unbreakable and then a fourth for cells that have breakpoints in them
01:48:53 [TabAtkins_]: howcome: Why not 'inherit'?
01:49:15 [TabAtkins_]: fantasai: That will inherit 'start' from its parent, which gives us the same problem.
01:49:29 [TabAtkins_]: howcome: So adding 'start' and 'end' caused the problem that we're solving with 'match-parent'?
01:49:46 [TabAtkins_]: fantasai: 'start' is the default value in 2.1, it's just not stated.
01:50:01 [TabAtkins_]: howcome: how about ol:lang(en) > li, and set the property using that selector?
01:50:14 [TabAtkins_]: fantasai: I don't htink that works. One of the cases is the defualt UA stylesheet for <option>.
01:50:32 [TabAtkins_]: fantasai: In that case you don't know what the direction property of <select> will be, or the language.
01:51:18 [TabAtkins_]: fantasai: You can't make a list of all the languages. The i18n group said that directly.
01:51:37 [TabAtkins_]: fantasai: So you just can't write a selector in the UA stylesheet that will get you the right behavior here.
01:51:49 [TabAtkins_]: fantasai: next is text-align-last
01:52:19 [TabAtkins_]: fantasai: It's also used when you can't justify a line.
01:53:05 [TabAtkins_]: szilles: thing that's not clear, if I have an anonymous block, the last line in that gets this property?
01:53:11 [TabAtkins_]: fantasai: Yes, any time the break isn't a soft wrap.
01:53:39 [TabAtkins_]: szilles: Feedback I got was that text-align-justify is complicated, but not sufficiently useful.
01:53:52 [TabAtkins_]: fantasai: I've changed some things since I got that feedback. More specific problems?
01:54:12 [TabAtkins_]: szilles: The JL task force cam eu pwith a way to scribe, for japanese, how they would end up justifying things.
01:54:32 [TabAtkins_]: fantasai: You have japanese, latin, and various punctuation.
01:54:40 [TabAtkins_]: fantasai: Punctuation is ua-defined and special.
01:54:47 [TabAtkins_]: fantasai: But this tells you how to prioritize other things.
01:55:06 [TabAtkins_]: szilles: But yo uhavne't gone far enough to get reasonable results.
01:55:44 [TabAtkins_]: fantasai: [explanation of using the values]
01:56:38 [TabAtkins_]: howcome: What if you specify one of the cjk values on non-cjk content?
01:56:44 [TabAtkins_]: fantasai: You get what it says on the tin.
01:56:54 [TabAtkins_]: fantasai: It's specified in the table in the spec.
01:57:42 [TabAtkins_]: fantasai: If you don't put any punctuation in your paragraph, you'll get interoperable results.
01:57:48 [TabAtkins_]: fantasai: Unfortunately, that's the best I can do.
01:58:00 [TabAtkins_]: fantasai: What I have are the main ways of prioritizing things.
01:58:11 [TabAtkins_]: fantasai: Please send specific comments to www-style.
01:58:49 [TabAtkins_]: szilles: So this property is just talking about different prioritizations of a number of techniques that could be used.
01:59:00 [TabAtkins_]: szilles: That's fine, but the exact details of who punctuation interacts still arent' defined.
01:59:16 [TabAtkins_]: fantasai: Yeah, because punctuation has all kinds of crazy special behavior in some languages (like japanese).
01:59:32 [TabAtkins_]: howcome: If we can't define this behavior, we shouldn't have these values in.
01:59:44 [TabAtkins_]: fantasai: There are valid distinctions to be made, which are captured here.
01:59:54 [TabAtkins_]: fantasai: I could take out the descriptions and just say "figure out what these mean".
02:00:11 [TabAtkins_]: howcome: We need to get interop, though.
02:00:29 [TabAtkins_]: szilles: I don't think we should prevent good typesetting just because we can't get exact interop.
02:00:47 [TabAtkins_]: fantasai: What you're tweaking is described . The things that we won't get interop on aren't describe.
02:00:54 [TabAtkins_]: jdaggett: Can't we infer this from content?
02:00:56 [TabAtkins_]: fantasai: How?
02:01:11 [TabAtkins_]: jdaggett: I don't see a clear path to implementation here.
02:01:31 [TabAtkins_]: jdaggett: You still need to define the bounds of where UAs need to be consistent.
02:01:38 [TabAtkins_]: fantasai: I did. If you'd like to improve that...
02:02:03 [TabAtkins_]: howcome: I think it's possible to do fine typography when you encoutner languages. But by putting these knobs in, we're raising the bar for implementors.
02:02:19 [TabAtkins_]: szilles: We need a way to distinguish english-in-japanese and japanese-in-english.
02:02:34 [TabAtkins_]: szilles: We can sorta say "what's the lang on the paragraph", but that's a weak approximation.
02:03:30 [TabAtkins_]: fantasai: I'd like to get to text-decoration before we wrap up this meeting.
02:03:48 [TabAtkins_]: szilles: Can you stick an issue in the spec here about "Maybe give better advice?"
02:03:57 [TabAtkins_]: fantasai: I can mark an issue for the WG to review and come up with suggestions.
02:04:16 [TabAtkins_]: Action to WG: Review the text-justify section for improvements.
02:04:16 [trackbot]: Sorry, couldn't find user - to
02:04:44 [TabAtkins_]: fantasai: There was a request to do each-line indentation, for source code or poetry.
02:05:32 [TabAtkins_]: fantasai: For text-decoration, I copies over the lines from XSL.
02:05:40 [TabAtkins_]: fantasai: People want to turn off decoration in descendants.
02:06:20 [TabAtkins_]: fantasai: I put in a rule that a text can have at most one of each type of line.
02:07:25 [TabAtkins_]: szilles: If you have transparent colors, you can tell which is done.
02:07:34 [TabAtkins_]: fantasai: yeah, or if the font-size is differnt
02:07:42 [TabAtkins_]: dbaron: Or the baseline is different, like superscripts
02:08:02 [TabAtkins_]: dbaron: With an underlined superscript in an underlined link, you don't want to break the link's underline where the superscript happens.
02:08:54 [TabAtkins_]: fantasai: then we have controls over style, color, and which line, controlled separately.
02:09:12 [TabAtkins_]: fantasai: What if you wanted to inhibit your ancestor's decoration, but add your own?
02:09:24 [TabAtkins_]: fantasai: Like ou wanted to stop the underline and create your own.
02:09:53 [TabAtkins_]: dbaron: Just allow all the stuff. "underline no-underline" to inhibit the parent's, and then draw your own.
02:10:25 [TabAtkins_]: szilles: You can do it yourself with nested spans.
02:10:30 [TabAtkins_]: szilles: So might as well do it here.
02:10:43 [TabAtkins_]: howcome: I don't like the combination of names.
02:11:24 [TabAtkins_]: [discussion about a keyword that kills all three decorations at once]
02:11:54 [fantasai]: cancel
02:13:06 [TabAtkins_]: Arron: Is cancel per-decoration, or all of them?
02:13:10 [TabAtkins_]: fantasai: I think you want to do both.
02:13:14 [dbaron]: cancel, cancel-underline, cancel-overline, cancel-strike-through
02:13:34 [TabAtkins_]: fantasai: next is text-decoration-skip
02:13:57 [TabAtkins_]: fantasai: Controls whether it's painted on images or spaces, or on top of glyph ink.
02:14:08 [TabAtkins_]: fantasai: Do we need one that doesn't skip margins and padding? They're skipped by default.
02:14:31 [TabAtkins_]: Arron: Don't see a use for that.
02:15:11 [TabAtkins_]: fantasai: next is text-underline-position
02:15:21 [TabAtkins_]: fantasai: alphabetic is default, then we have below-left and below-right
02:16:23 [TabAtkins_]: szilles: For rotated vertical test, I say "below right"...
02:16:27 [bradk]: text-decoration: dashed([<dash-width>,<dash-space>]+[,<dash-width>,<dash-space>]*)
02:16:29 [TabAtkins_]: fantasai: You do below.
02:17:29 [TabAtkins_]: dbaron: Why is this a pair of keywords and not just a hyphenated keyword?
02:17:57 [TabAtkins_]: dbaron: random naming question - text-underline-style: wave or wavy?
02:18:57 [TabAtkins_]: fantasai: I have no opinion.
02:19:16 [Xaxio]: noun or adjective? text-decoration: underline is a noun, so I'd vote for noun
02:20:18 [TabAtkins_]: fantasai: [overview of text-emphasis]
02:20:37 [TabAtkins_]: szilles: The feedback I got is "draw marks", with the implication that this is done as a graphic process.
02:21:13 [TabAtkins_]: szilles: So rather than "draw small circles as marks", say "use XXX character"
02:21:21 [TabAtkins_]: fantasai: The UA is allowed to use other characters.
02:21:40 [TabAtkins_]: smfr: We ipmlement this, but use the chars.
02:21:45 [TabAtkins_]: szilles: So require using the chars.
02:22:04 [TabAtkins_]: fantasai: [points out passage talking about glyph usage]
02:22:48 [TabAtkins_]: szilles: Given that text, just say to use XXX character and then the prose overrides that when necessary.
02:23:20 [fantasai]: s/Draw/Display/
02:23:33 [TabAtkins_]: szilles: that's better, but I want to emphasize using the glyph
02:23:52 [TabAtkins_]: fantasai: [describes text-emphasis-position]
02:24:53 [TabAtkins_]: fantasai: Something to address is that epub has ruby-position, which isn't in this module.
02:25:01 [TabAtkins_]: fantasai: It's the one thing from Ruby that epub needs.
02:25:16 [TabAtkins_]: fantasai: And they'll put it in, prefixed, if necessary.
02:25:31 [TabAtkins_]: fantasai: If we're planning to change things here with ruby, that conversation needs to happen sooner rather than later.
02:26:21 [TabAtkins_]: fantasai: Koji and I noticed that 'before' and 'after' aren't accurate on ruby-poistion here, due to rotate glyphs.
02:26:33 [howcome]: howcome has joined #css
02:26:47 [TabAtkins_]: jdaggett: I think bopomofo is peculiar.
02:26:52 [TabAtkins_]: fantasai: yeah, I disagree with that change.
02:27:44 [TabAtkins_]: szilles: I recommend 'inter-character'
02:27:54 [TabAtkins_]: RESOLVED: use 'inter-character' instead of 'bopomofo'.
02:27:55 [homata_]: homata_ has joined #CSS
02:28:12 [TabAtkins_]: fantasai: and Koji and I think we should use the text-emphasis-position values for ruby-position as well.
02:28:23 [TabAtkins_]: szilles: If you have emphasis and ruby, do you stack or not, and in what order?
02:28:38 [TabAtkins_]: fantasai: Some pubs will stack it, some will swap the sides one is on, and some will drop one or the other.
02:28:57 [TabAtkins_]: Arron: I think we shouldn't worry about this today.
02:29:20 [TabAtkins_]: szilles: Let's just note that there may be a need for a control here.
02:29:50 [jdaggett]: yes
02:30:15 [TabAtkins_]: szilles: I'd like to see an example of underlines in mongolian.
02:30:32 [TabAtkins_]: fantasai: The problem is putting chinese in mongolian, which is surprisingly common
02:30:52 [TabAtkins_]: [talk about underlines in chinese/mongolian]
02:32:37 [TabAtkins_]: howcome: There seem to be some general properties here that apply to every language.
02:32:50 [TabAtkins_]: howcome: And then there are some that apply to only a few languages (important ones, but still)
02:33:05 [TabAtkins_]: howcome: I suggest we separate out the script-specific stuff from the generic stuff.
02:33:31 [TabAtkins_]: szilles: That's not fantastically attractive because the bidi and vertical issues aren't script-specific, but they're driven by non-western usage.
02:34:38 [TabAtkins_]: fantasai: It would be a ton of work for little benefit.
02:35:20 [TabAtkins_]: [talk about relative value]
02:38:18 [fantasai]: howcome: I think we should split the spec
02:38:25 [fantasai]: plinss: I challenge howcome to come up with the split
02:38:36 [kojiishi]: kojiishi has joined #css
02:39:23 [fantasai]: plinss: One way we can split is to mark them all at-risk and push to CR, see if we get implementations
02:39:30 [fantasai]: jdaggett: I'm concerned that they'll get implemented, but implemented wrong
02:40:01 [fantasai]: Steve: You've got to have an architectural base into which to put things
02:44:03 [howcome]: The scope of this spec is very large, and goes to great depths in some areas, while shallow in others. I suggest splitting out the script- or language-specific issues into separate modules. This will also allow us to address other languages, like Mongolian, in the future.
02:45:10 [fantasai]: Meeting closed.
04:00:02 [dsinger]: dsinger has joined #css
04:50:18 [arno]: arno has joined #css
05:07:36 [kennyluck]: kennyluck has joined #CSS
05:27:13 [plinss_]: plinss_ has joined #css
05:38:00 [plinss__]: plinss__ has joined #css
05:57:51 [plinss_]: plinss_ has joined #css
06:06:20 [homata__]: homata__ has joined #CSS
06:11:25 [plinss_]: plinss_ has joined #css
06:30:05 [jdaggett]: jdaggett has joined #css
07:49:48 [anne]: anne has joined #css
08:32:48 [plinss_]: plinss_ has joined #css
08:38:02 [homata]: homata has joined #CSS
08:56:53 [plinss_]: plinss_ has joined #css
09:24:36 [anne]: anne has joined #css
10:11:43 [homata_]: homata_ has joined #CSS
11:20:20 [arronei]: arronei has joined #CSS
11:33:06 [plinss_]: plinss_ has joined #css
13:00:31 [kennyluck]: kennyluck has joined #CSS
13:36:17 [karl]: karl has joined #CSS
14:18:06 [jdaggett]: jdaggett has joined #css
15:30:52 [plinss_]: plinss_ has joined #css
15:53:17 [Arron]: Arron has joined #css
15:53:47 [Arron]: Arron has joined #css
15:54:47 [Arron]: Arron has joined #css
15:55:25 [arronei_]: arronei_ has joined #css
16:16:29 [Martijnc]: Martijnc has joined #css
16:22:35 [szilles]: szilles has joined #css
16:25:21 [shonda]: shonda has joined #css
16:25:32 [myakura]: myakura has joined #css
16:27:34 [szilles]: szilles has joined #css
16:39:24 [TabAtkins_]: TabAtkins_ has joined #css
16:58:09 [dsinger]: dsinger has joined #css
17:13:58 [plinss_]: plinss_ has joined #css
17:31:11 [TabAtkins_]: TabAtkins_ has joined #css
17:34:10 [arno]: arno has joined #css
18:47:53 [jdaggett]: jdaggett has joined #css
18:54:59 [dbaron]: dbaron has joined #css
19:02:12 [arno]: arno has joined #css
19:19:08 [TabAtkins_]: TabAtkins_ has joined #css
20:33:03 [dbaron]: ok, I have patches for uri-016.xht that work
20:33:17 [dbaron]: though I broke a test related to unclose paretheses that's probably a simple fix, but that's for after lunch
21:20:49 [arno]: arno has joined #css
21:35:05 [shepazu]: shepazu has joined #css
21:52:07 [jdaggett]: jdaggett has joined #css
22:10:00 [plinss_]: plinss_ has joined #css
23:07:15 [johnjan]: johnjan has joined #css
23:18:14 [myakura]: myakura has joined #css
00:01:34 [arno]: arno has joined #css
00:35:50 [homata]: homata has joined #CSS
01:23:06 [plinss_]: plinss_ has joined #css