/irc-logs / w3c / #css / 2011-03-10 / end

Options:

# Session Start: Thu Mar 10 00:00:00 2011
# Session Ident: #css
# [00:00] <fantasai> plinss: So, who is going to help us respond to issues?
# [00:00] <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.
# [00:00] <johnjan> I can help as well (either edit or DOCs).
# [00:00] <johnjan> but I would need to get permissions to edit.
# [00:00] <dbaron> test reverted
# [00:00] <fantasai> you probably don't want to edit :) but helping with responses / DOC would be nice
# [00:01] <fantasai> dbaron: I had specific actions to respond to specific posts
# [00:01] <johnjan> I definitely don't want to edit, but I want to help any way I can :-).
# [00:01] <johnjan> David, I have you marked as having only one of those left.
# [00:01] <dbaron> we need to link to responses in the wiki page
# [00:01] <johnjan> issue 234
# [00:01] <dbaron> (reverting of test is r1991)
# [00:02] <fantasai> If, as you're responding to issues, you run across an editorial edit that we rejected, assign the issue to me
# [00:02] <fantasai> =fantasai= respond
# [00:02] <Bert> Most of the work wil be responding. Looks like the edits will take me half a day.
# [00:02] <fantasai> That way I can fold those edits into a diff for the next revision
# [00:03] <Bert> But getting you an edit account is a good idea anyway.
# [00:03] * Joins: szilles (chatzilla@63.245.220.224)
# [00:03] <fantasai> So plan is, Arron &co will respond to all substantive issues and any issus that were accepted
# [00:04] * Joins: bradk (bradk@63.245.220.224)
# [00:04] <johnjan> I agree Bert. Let's talk about that after the next conf call.
# [00:04] <fantasai> fantasai will respond to editorial issues that were rejected
# [00:04] <johnjan> Sounds like a good plan.
# [00:04] <johnjan> When can we finish? (both the edits and the DOC) - tomorrow?
# [00:05] <johnjan> Today?
# [00:05] <johnjan> It's only 3 :-)
# [00:05] <fantasai> Arron: Plan to finish by next conference call (in 3 weeks)
# [00:05] <fantasai> johnjan, you are way enthusiastic :)
# [00:05] <fantasai> s/3 weeks/2 weeks/
# [00:05] <fantasai> When you respond to an issue, put a link to your response in the Wiki
# [00:06] <fantasai> That's really important! we need it to compile the DoC
# [00:06] <fantasai> Topic: Charter
# [00:06] <fantasai> jdaggett: Charter is up March 31st
# [00:06] <johnjan> I am enthusiastic, that's true. 2 weeks seems really late balanced against the expiration of our charter
# [00:07] <fantasai> Steve: Given where we are, I'm sure the directory would be happy to extend the charter for 2 months or so
# [00:07] <fantasai> jdaggett: So what's the status of the charter? Is Chris Lilley going to get to it? Do we have a Plan B?
# [00:07] <fantasai> jdaggett: Can Bert help?
# [00:07] <fantasai> jdaggett: We have a draft, and we have a proposal, and it needs editing.
# [00:08] <fantasai> Bert: Chris is on holiday this week. He was supposed to have a draft ready
# [00:08] <fantasai> Bert: But he hasn't sent it yet
# [00:08] <fantasai> jdaggett: Can we give him a specific deadline to send it?
# [00:08] <fantasai> jdaggett: And have somebody else take over if he can't do it?
# [00:09] <fantasai> RESOLVED: Discuss new charter at next telecon
# [00:09] <fantasai> Topic: CSS3 Text
# [00:10] <johnjan> I'm really hoping we can get the DOC and edits done in less than two weeks.
# [00:10] <johnjan> Why not schedule a 'special conf call' to get this done.
# [00:11] <johnjan> we just did some amazing work over the last three days to get here, and I hate to lose that momentum.
# [00:11] <fantasai> johnjan, a lot of people are going to be at sxsw,
# [00:12] <Bert> I'll the edits done before next Wednesday, with an updated (public) editor's draft.
# [00:12] <Bert> I'll *have*
# [00:12] * glazou got a VIP invitation for the IE9 party at SXSW but won't be there...
# [00:13] <johnjan> even better. Then we're all in the same time zone (except glazou apparently). :-)
# [00:14] <TabAtkins_> Topic: CSS3 Text
# [00:14] <TabAtkins_> fantasai: There's a bunch of marked issues, so we'll scroll through them and try to resolve.
# [00:14] <smfr> http://dev.w3.org/csswg/css3-text/
# [00:14] <TabAtkins_> fantasai: For text-transform, we're adding "fullwidth" and "large-kana".
# [00:15] <TabAtkins_> fantasai: [explains the two values]
# [00:15] <TabAtkins_> jdaggett: I think the name here is bad.
# [00:15] <TabAtkins_> jdaggett: "large" implies incorrect size - there's really just "normal" and "small" kana.
# [00:15] * Quits: arno1 (arno@192.150.10.200) (Quit: Leaving.)
# [00:16] <TabAtkins_> jdaggett: I think "fullsized-kana" would be better.
# [00:16] <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.
# [00:16] <johnjan> And I'll be quiet now.
# [00:16] <TabAtkins_> jdaggett: You're sort of pointing at various unicode documents, and there's too much ambiguity.
# [00:17] <TabAtkins_> fantasai: What's the delta you want?
# [00:18] <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.
# [00:18] <TabAtkins_> fantasai: Okay.
# [00:18] <dbaron> letters and numbers, and not punctuation and whitespace.
# [00:18] <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.
# [00:19] <TabAtkins_> jdaggett: So (1) have a specific algorithm, identifying the characters this should apply to
# [00:19] <TabAtkins_> kojiishi: It's already defined in unicode, right?
# [00:19] * Joins: arno (arno@192.150.10.200)
# [00:19] <TabAtkins_> jdaggett: A lot of things are defined in unicode. We need to be specific about what is being talked about here.
# [00:20] <TabAtkins_> jdaggett: I don't think you want *all* halfwidths to change to fullwidth - only letter and numbers, not punctuation and whitespace
# [00:20] <TabAtkins_> kojiishi: No, we want all halfwidths to map to fullwidth
# [00:20] <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
# [00:21] <TabAtkins_> jdaggett: Unicode doesn't define the transformation algorithm, it just identifies the classes. You need to define the transform.
# [00:21] <TabAtkins_> jdaggett: If you want to transform all of them, then say so explicitly.
# [00:22] <TabAtkins_> fantasai: So you want a codepoint-to-codepoint transformation algorithm. I'll mark an issue about it.
# [00:22] <TabAtkins_> szilles: I'd like a note about this, because I wouldn't think a priori that you'd transform whitespace and punctuation.
# [00:22] <TabAtkins_> jdaggett: Yes.
# [00:23] <TabAtkins_> kojiishi: What's the use-case? I've done some interviews in Japan, and nobody has requested different treatment for those classes.
# [00:23] <TabAtkins_> jdaggett: When you're going between horizontal and vertical, you want the fullwidth in vert.
# [00:23] <TabAtkins_> jdaggett: Ideally we want the author to write using the standard codepoints, but it displays with teh fullwidth forms in vertical text.
# [00:24] <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.
# [00:24] <TabAtkins_> fantasai: I think the question of which should be done is a question for the jlreq people, not us.
# [00:24] <fantasai> jdaggett's concern is that punctuation forms won't match between fullwith and halfwidth forms used in the same paragraph
# [00:25] <TabAtkins_> szilles: Under orientation, we said upright.
# [00:25] <TabAtkins_> fantasai: Right, but it doesn't change the glyph shape or the linebreaking behavior.
# [00:25] <TabAtkins_> fantasai: If you don't want the changed shape and behavior, just use text-orientation.
# [00:26] <TabAtkins_> fantasai: [gives use-case for why both options are useful]
# [00:26] <TabAtkins_> szilles: But in Korean they're happy breaking arbitrarily
# [00:26] <TabAtkins_> fantasai: That's handled with word-break, for breaking arbitrarily in normal text
# [00:26] <TabAtkins_> fantasai: But that won't get you fullwidth glyph shapes.
# [00:29] <TabAtkins_> [discussion about use-cases]
# [00:29] * smfr suggests we move this discussion to www-style
# [00:30] * Joins: dsinger (dsinger@208.54.4.44)
# [00:31] <TabAtkins_> jdaggett: So, last comment, this just needs to be tightened up a lot.
# [00:32] <TabAtkins_> fantasai: In whitespace processing, the issue is control characters.
# [00:32] <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.
# [00:32] <TabAtkins_> fantasai: But what does that mean?
# [00:32] <TabAtkins_> jdaggett: Render as missing character if it doesn't exist.
# [00:33] <TabAtkins_> Arron: Almost all browsers treat them as zero-width characters.
# [00:34] <TabAtkins_> fantasai: So I have three options
# [00:34] <TabAtkins_> fantasai: (1) render them as unknown chars if the font doesn't have them
# [00:34] <TabAtkins_> fantasai: (2) treat them as zero-width all the time
# [00:34] <TabAtkins_> fantasai: (3) Allow both
# [00:35] <TabAtkins_> dbaron: If so, you should be explicit in what char classes you're talking about.
# [00:35] <TabAtkins_> Arron: I would prefer zero-width.
# [00:35] <TabAtkins_> szilles: I'd prefer something that makes it not useful for people to have put them in.
# [00:35] <dbaron> Seems to be character class Cc
# [00:35] <TabAtkins_> szilles: Rendering them as zero-width has *some* use, but it's close enough to useless.
# [00:36] <TabAtkins_> fantasai: Okay, (2) it is.
# [00:36] <TabAtkins_> fantasai: Next is white-space-collapsing property
# [00:36] <TabAtkins_> fantasai: In a lot of flux
# [00:37] <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.
# [00:37] <TabAtkins_> fantasai: The main issue for me is that I think the name sucks.
# [00:38] <TabAtkins_> szilles: Was this inherited from XSL?
# [00:38] <TabAtkins_> fantasai: This is different.
# [00:38] <TabAtkins_> szilles: Why is
# [00:38] <TabAtkins_> szilles: Why is 'collapse' better than 'collapsing'?
# [00:38] <TabAtkins_> fantasai: Parallel naming with our other properties.
# [00:41] * Quits: hyatt (hyatt@98.200.13.42) (Quit: hyatt)
# [00:41] <TabAtkins_> [name bikeshedding]
# [00:41] <fantasai> RESOLVED: rename white-space-collapsing to bikeshedding
# [00:42] <stearns> :)
# [00:43] <TabAtkins_> szilles: I think tab-size is a bad idea.
# [00:43] <TabAtkins_> jdaggett: Wait, this is for tab-stops, not a transform on tabs themselves?
# [00:44] <TabAtkins_> bradk: Can we implement a length?
# [00:44] * Quits: glazou (glazou@63.245.220.224) (Quit: glazou)
# [00:44] <TabAtkins_> dbaron: It would be trivial to use a length.
# [00:45] <TabAtkins_> Bert: Why do we need this?
# [00:46] <TabAtkins_> TabAtkins_: Because tabs in preformatted text are super-huge by default.
# [00:47] <dbaron> https://bugzilla.mozilla.org/show_bug.cgi?id=517882
# [00:47] <TabAtkins_> glazman: I'll use this immediately in my source-view of my editor.
# [00:47] * Joins: glazou (glazou@63.245.220.224)
# [00:48] <TabAtkins_> dbaron: For the record, Moz implemented this to change the size of tabs in our view-source
# [00:48] <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.)
# [00:49] <TabAtkins_> fantasai: Now, 'line-break'.
# [00:49] <TabAtkins_> fantasai: [describes the values]
# [00:49] <TabAtkins_> szilles: How do you get interop on these?
# [00:49] <TabAtkins_> fantasai: There are recommendations, but it doesnt' cover all cases.
# [00:50] <TabAtkins_> fantasai: We don't cover line-breaking anyway, which is apparently okay, and I'm not going to solve this problem by June.
# [00:50] <Arron> I think tab-stop should allow '0' as a valid value
# [00:50] <TabAtkins_> szilles: How will you exit CR?
# [00:50] <TabAtkins_> fantasai: There's enough there to test, and the rest is undefined.
# [00:50] <TabAtkins_> fantasai: [describes word-break]
# [00:51] <TabAtkins_> fantasai: We may drop the 'keep-words' value.
# [00:51] <TabAtkins_> fantasai: [describes the hyphenation property]
# [00:52] <TabAtkins_> smfr: [question about displaying soft hyphens in an editting environment]
# [00:53] <TabAtkins_> fantasai: I think we should drop the 'all' value.
# [00:53] <TabAtkins_> fantasai: Or I can mark this as at-risk.
# [00:53] <TabAtkins_> szilles: Does this show the soft-hyphens, or what the dict would have given me as hypenation opportunities?
# [00:53] <TabAtkins_> fantasai: Both.
# [00:53] <TabAtkins_> szilles: And I can't tell which is which?
# [00:53] <TabAtkins_> fantasai: Right.
# [00:54] <TabAtkins_> fantasai: Okay, I'm marking as at-risk.
# [00:54] <TabAtkins_> fantasai: Now, hyphenate-character property.
# [00:54] <TabAtkins_> fantasai: Do we need the second hyphenation character?
# [00:54] <TabAtkins_> szilles: I thought there was osme language where the "beginning of line" hyphenation char is used.
# [00:55] <TabAtkins_> fantasai: I dunno, I don't have any examples of it being used.
# [00:55] <TabAtkins_> Bert: This may have come from some languages where, when you break words, you replace certain characters. But that's a different concept.
# [00:55] * Joins: homata (homata@58.158.182.50)
# [00:55] <TabAtkins_> fantasai: Okay, I'm dropping the second character.
# [00:56] <TabAtkins_> fantasai: [describes the hyphenate-limit properties]
# [00:56] <TabAtkins_> jdaggett: Are these different ways of controlling hyphenation? Would you use these all together?
# [00:56] <TabAtkins_> fantasai: No idea. They are indeed different, though.
# [00:57] <stearns> I think they would be used together
# [00:58] <TabAtkins_> jdaggett: Trying to understand the algorithm here.
# [00:58] <TabAtkins_> jdaggett: Where's the language sensitivity, and where's the dictionary come from?
# [00:58] <TabAtkins_> fantasai: That's further down.
# [00:59] <stearns> you might only specify one or two that you're really concerned with, but some authors would apply values for all
# [00:59] <TabAtkins_> bradk: Can we combine the hyphenate-limit properties into one?
# [00:59] <TabAtkins_> fantasai: I think -zone should be separate, but -before and -after are combinable.
# [01:00] <johnjan> I don't think they should be combined. I don't know why you would ever want them combined.
# [01:00] <TabAtkins_> fantasai: There was a proposal on the list to add a hyphenate-limit-* property that would limit the length of the word.
# [01:01] <johnjan> That was from Christian Stockwell, a PM on the IE team.
# [01:01] * TabAtkins_ johnjan We mean specifying them both in one property, rather than having them cascading together.
# [01:01] * TabAtkins_ johnjan, not providing a single value that means both.
# [01:01] * TabAtkins_ I mean cascading separately.
# [01:01] <johnjan> ah, like hyphenate-limit: 4 5; ?
# [01:02] * TabAtkins_ johnjan, yeah.
# [01:03] <fantasai> jdaggett: asks what the priority is among the various limit properties
# [01:03] <TabAtkins_> [discussion about how the properties work together]
# [01:03] <fantasai> fantasai, plinss: The limits combine: as soon as one limit applies, you can't break there
# [01:03] <fantasai> jdaggett: Is that good enough? Do we need priorities of some kind?
# [01:03] <fantasai> jdaggett: Would that overconstrain?
# [01:04] <fantasai> Steve: ...
# [01:04] <fantasai> Steve: In practice it doesn't overconstrain
# [01:04] <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
# [01:04] <fantasai> but "unconditional" would
# [01:05] <fantasai> ...
# [01:05] <stearns> that would be quite useful
# [01:05] <fantasai> Alex: Knuth's paper says that once you do optimial paragraph breaking, the hyphenation controls don't really make much of a differenc
# [01:05] <fantasai> e
# [01:07] <johnjan> I think optimal paragraph is orthogonal to this conversation.
# [01:08] <TabAtkins_> [argument about whether to combine -before and -after]
# [01:08] <stearns> could combine minimum, before and after
# [01:08] * fantasai thinks so too, steve zilles is not agreed
# [01:09] <stearns> I don't know of a use case where one would vary while keeping the others set
# [01:10] <fantasai> dbaron: I don't think other systems have the same concept of properties that CSS has
# [01:13] <fantasai> ScribeNick: fantasai
# [01:14] <fantasai> ScribeNick: TabAtkins_
# [01:14] <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
# [01:14] <fantasai> fantasai: Should we include the word limit in there?
# [01:15] <fantasai> arron: The word limit sounds very useful
# [01:15] <stearns> If we do, a suggested value for 'auto' is 5, going by InDesign's defaults
# [01:15] <TabAtkins_> <br duration=10min>
# [01:15] * Quits: bradk (bradk@63.245.220.224) (Quit: Computer has gone to sleep)
# [01:15] <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.
# [01:15] * Joins: bradk (bradk@63.245.220.224)
# [01:16] <johnjan> InDesign's default sounds good. (for word limit, right?)
# [01:16] <stearns> right
# [01:16] * Quits: bradk (bradk@63.245.220.224) (Quit: Computer has gone to sleep)
# [01:17] <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.
# [01:20] <fantasai> Arron: It would be nice to put a note that
# [01:20] <fantasai>  in a word disables auto-hyphenation in favor of that breakpoint
# [01:20] <fantasai> since that would be the best way to do word-by-word tweaks
# [01:20] <stearns> ^
# [01:21] <johnjan> also explicit hypens would disable auto-hypenation as well. (in addition to )
# [01:21] <fantasai> johnjan: I'm less sure of that
# [01:21] <fantasai> s/:/,/
# [01:22] <fantasai> johnjan, since hyphens are part of the spelling of a word
# [01:22] <fantasai> johnjan, they're not there to control hyphenation
# [01:23] <johnjan> if I use the word 'auto-hypenate' (even if I say limit-before: 6;) I'd expect you to break on auto-
# [01:23] <johnjan> s/hypenate/hyphenate
# [01:25] <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
# [01:25] <stearns> http://unicode.org/reports/tr14/tr14-14.html
# [01:30] <johnjan> < leaving to catch a bus
# [01:30] * Quits: johnjan (qw3birc@128.30.52.28) (Quit: Page closed)
# [01:30] <stearns> Another possible note could be that  at the beginning of a word disables hyphenation altogether for that word
# [01:30] * Joins: bradk (bradk@63.245.220.224)
# [01:30] <bradk> test 123
# [01:31] <fantasai> hyphenation-limit-word
# [01:31] <fantasai> fantasai: So question on hyphenation-limit-zone was should it be relative to line box or block?
# [01:31] <fantasai> howcome: Line box
# [01:32] <fantasai> RESOLVED: Make percentages on hyphenation-limit-zone relative to line box
# [01:32] <TabAtkins_> fantasai: We also talked about -before and -after, and someone suggested a minimum word length as well.
# [01:32] <TabAtkins_> fantasai: [explains why this can't just be done through -zone]
# [01:33] <TabAtkins_> howcome: Christian proposed something that sounded like -zone.
# [01:34] <TabAtkins_> fantasai: [draws a pretty picture explaining why you can't do it through -zone]
# [01:34] <bradk> hyphenation-limit-chars:<before> <min> <after>
# [01:34] * Quits: arno (arno@192.150.10.200) (Ping timeout)
# [01:35] * fantasai really really likes bradk's proposal!
# [01:35] <bradk> hyphenation-limit-character-count:<before> <min> <after>
# [01:35] * fantasai would put <min> first, though, so you can make <before> and <after> the same easily
# [01:36] <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.
# [01:36] * Quits: alexmog (qw3birc@128.30.52.28) (Ping timeout)
# [01:37] <TabAtkins_> fantasai: I think that'll be much harder to calculate.
# [01:37] <TabAtkins_> Bert: Doing -zone assumes that every line has about the same number of spaces, which may not be the case.
# [01:37] <TabAtkins_> fantasai: Yes.
# [01:38] <TabAtkins_> Bert: Also, if on the preceding line all the spaces were stretched, you don't want to shrink the next line's spaces.
# [01:38] <bradk> I think all these properties should begin with hyfN8- instead of hyphenation- so that we don't have to type as much.
# [01:38] <stearns> ideally it should be relative to the line's measure (how many characters fit). I would specify using ems
# [01:39] <fantasai> stearns, we have % defined to do that
# [01:39] <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.
# [01:39] <fantasai> % is relative to the size of the line
# [01:39] <fantasai> s/size/measure/
# [01:40] <stearns> hy8n - hy(8 characters)n
# [01:40] <TabAtkins_> Bert: Perhaps the badness-factor can be captured with the number of spaces in the line, and the number of successive hyphenated lines.
# [01:41] <TabAtkins_> fantasai: This sounds very complicated. For now let's just keep the hyphens property.
# [01:41] * sylvaing ...or we could have a badness-factor property !
# [01:41] <TabAtkins_> fantasai: And maybe drop the rest for now.
# [01:41] <TabAtkins_> howcome: I was happy with the state of this section at the time it transferred into this draft.
# [01:42] <fantasai> fantasai: we could mark everything at risk and see what ppl implement
# [01:42] <TabAtkins_> howcome: About hyphenate resource, it seems there are two formats.
# [01:42] <TabAtkins_> howcome: Kew has done some work cleaning up the dictionaries used.
# [01:42] <TabAtkins_> howcome: There is a set of freely-available dictionaries.
# [01:43] <TabAtkins_> howcome: The format isn't described anywhere.
# [01:43] <TabAtkins_> howcome: They're derived from TeX macros.
# [01:43] <TabAtkins_> howcome: Does Apple have their own format?
# [01:43] <dbaron> he was trying to clean them up so they didn't depend on TeX macros
# [01:44] <fantasai> s/macros/'s format, without the macros/
# [01:44] <TabAtkins_> smfr: We use built-in system resources, but don't plan on implementing hyphenation-resource soon.
# [01:44] <TabAtkins_> smfr: I think we just purely go off the lang of the element.
# [01:44] <TabAtkins_> howcome: Yeah, often you want to attach this to lang.
# [01:45] <TabAtkins_> howcome: Though often when comparing content that's hyphenated, you want to compare different dictionaries.
# [01:45] <TabAtkins_> howcome: What I'm arguing against is to hinge this off the @lang attribute.
# [01:46] <TabAtkins_> howcome: If you're laying out a book, frex, you want to lay it out, same content, with two different hyphenations and compare.
# [01:46] <TabAtkins_> TabAtkins_: Since you're just debugging, can't you just tag one with a bogus language or something?
# [01:46] <TabAtkins_> jdaggett: What about topic-specific things?
# [01:47] <TabAtkins_> szilles: And shouldn't you want to key it off of lang?
# [01:47] <TabAtkins_> howcome: Yes, definitely, so by default authors should use :lang(). They just shoulnd't be limited to only using :lang().
# [01:47] <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.
# [01:47] <TabAtkins_> smfr: We're fine with the built-in resources for now, though.
# [01:48] <TabAtkins_> jdaggett: I suspect you'll need it when, say, iBooks needs to display a medical textbook.
# [01:49] <TabAtkins_> fantasai: [something about formats]
# [01:49] <TabAtkins_> jdaggett: Just glancing over the TeX dict, it looked like there were some subtle important details in there.
# [01:50] <TabAtkins_> jdaggett: Didn't AH point to a TeX dictionary?
# [01:50] <TabAtkins_> jdaggett: If you follow the indirections in their reference, it's TeX-based.
# [01:51] <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.
# [01:51] <TabAtkins_> howcome: The TeX algorithm is widely described, and there are impls of it.
# [01:51] <TabAtkins_> jdaggett: If it's a straightforward thing for someone to look at the format and implement, that's fine.
# [01:52] <TabAtkins_> howcome: [comment about the format describing weights]
# [01:52] <TabAtkins_> jdaggett: Right, and that makes implications about how to implement it.
# [01:52] <TabAtkins_> howcome: I think a reference to TeX would be okay.
# [01:52] <TabAtkins_> jdaggett: Without a format and the semantics for it defined, this entire property can't be interoperable.
# [01:53] <TabAtkins_> howcome: You could similarly argue for OT, which has parts that aren't well-described.
# [01:53] <TabAtkins_> jdaggett: You're talking about language handling? Yeah, but that's just specific areas of OT, not the entire spec itself.
# [01:54] <TabAtkins_> howcome: I think if we try to describe this directly, instead of just referring to TeX, it'll be a lot of work.
# [01:54] <TabAtkins_> szilles: So you're proposing we referenc the spec. Is it a book, or a stable website, or...?
# [01:54] <dbaron> http://www.tug.org/docs/liang/
# [01:54] <TabAtkins_> howcome: It's called [TeX algorithm], and it's published in a collection of algorithms called "Digital Typography".
# [01:55] <TabAtkins_> szilles: The general rule is that references must be a public document that people can follow.
# [01:55] <TabAtkins_> howcome: It's a research paper.
# [01:55] <TabAtkins_> szilles: That's probably okay. I just suggest you do the homework to get us that reference.
# [01:55] <bradk> open office has this list that includes teX based hyphenation dictionaries: http://wiki.services.openoffice.org/wiki/Dictionaries
# [01:55] <TabAtkins_> fantasai: So the format we're standardizing on is the TeX hyphenation format, along with macros?
# [01:55] <TabAtkins_> howcome: Not macros.
# [01:56] <TabAtkins_> fantasai: Okay, then we need to specify that.
# [01:56] <TabAtkins_> howcome: Okay. But this should be a soft recommendation, not a strict requirement.
# [01:56] <TabAtkins_> fantasai: Okay, we just need a way to specify what exactly is being requested to be implemented.
# [01:56] <bradk> GNU LGPL license is OK for hyphenation dictionaries?
# [01:57] <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.
# [01:57] <TabAtkins_> howcome: I think we just need to put into writing the principles used when Kew & others were cleaning up the TeX files.
# [01:58] <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.
# [01:58] <TabAtkins_> howcome: We've discussed this relative to font-face, right?
# [01:58] <TabAtkins_> smfr: Yes.
# [01:58] <fantasai> ACTION howcome Come up with a precise spec (reference or reference + prose) for the hyphenation format
# [01:58] * trackbot noticed an ACTION. Trying to create it.
# [01:58] <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].
# [01:58] <TabAtkins_> howcome: I think we decided then not to do anything, and we shouldn't do anything here.
# [01:58] <TabAtkins_> howcome: If you're concerned, you could just download the dicts in the stylesheet before displaying anything.
# [01:59] <TabAtkins_> Arron: No, they can take a long time.
# [01:59] <TabAtkins_> fantasai: I think it should be an impl pref.
# [01:59] <fantasai> s/impl/user/
# [01:59] <TabAtkins_> howcome: I agree; it's a user thing.
# [01:59] * fantasai is impatient, would set it to a very short timeout :)
# [02:00] <TabAtkins_> fantasai: next is whether to do @hyphenate-resource or 'hyphenate-resource'. Advantage of former is less storage, and maybe more intelligent langauge mapping.
# [02:01] <TabAtkins_> fantasai: [shows example of using multiple dicts in @hy-res]
# [02:01] <TabAtkins_> jdaggett: I think the common case is authors within a single language needing multiple dicts for specialized texts.
# [02:02] <TabAtkins_> fantasai: Right, you can juts provide multiple dictionaries, so medical texts would have words in the first dict.
# [02:02] * Quits: glazou (glazou@63.245.220.224) (Quit: glazou)
# [02:02] <TabAtkins_> fantasai: The issue here is how you bind the dict to the element.
# [02:03] <TabAtkins_> howcome: Impls, if there isn't a value for the prop on an element, they don't use space for it.
# [02:03] <TabAtkins_> fantasai: Yes they do.
# [02:04] <TabAtkins_> howcome: Not a ton of space.
# [02:04] <TabAtkins_> plinss_: Is there a need to specify a dict on a per-element basis?
# [02:04] <TabAtkins_> howcome: Yes, for example when debugging.
# [02:05] <fantasai> Tab: Debugging doesn't need to be elegant, just possible.
# [02:05] <TabAtkins_> szilles: I think there are valid reasons to use different technical dicts on different things in the same language.
# [02:06] <TabAtkins_> fantasai: Generally you'd just concat the dictionaries.
# [02:06] <TabAtkins_> fantasai: Only case wher eyou need per-element is when you want to hyphenate a single word differently based on the context.
# [02:06] <TabAtkins_> fantasai: You can soft-hyphenate that, or specify it as a variant language.
# [02:07] <TabAtkins_> szilles: I guess I can live with it, because I can't think of any othe property to control hyphenation with.
# [02:07] <TabAtkins_> szilles: Besides, you can open separate windows anyway (for debugging).
# [02:07] <TabAtkins_> howcome: I just think it's too much of a restriction to key off the lang.
# [02:08] <TabAtkins_> fantasai: You want the @lang anyway, so UAs can do lang-specific stuff anyway.
# [02:08] <TabAtkins_> howcome: Medical, technical things.
# [02:09] <TabAtkins_> plinss_: I think if you can find examples where you actually need this, find them and bring them back in.
# [02:09] <TabAtkins_> howcome: We already have impls. Why are we changing this?
# [02:10] <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.
# [02:10] <TabAtkins_> [discussion about how much space would be saved]
# [02:10] <stearns> as far as I know, medical and legal dictionaries are more about spelling than hyphenation
# [02:11] <TabAtkins_> smfr: I thought @hy-res would be like @font-face, which would describe the resource only, and then we link it to elements.
# [02:11] <TabAtkins_> fantasai: The reason you fold them together is because there's generally no need for the additional targetting.
# [02:13] <TabAtkins_> howcome: You don't necessarily want to run through every dictionary to hyphenate normal words.
# [02:13] <TabAtkins_> TabAtkins_: Do we actually think that imlementing hyphenation is going to involve walking a linear list for every word?
# [02:13] <TabAtkins_> dbaron: [talking about the dict format that TeX uses]
# [02:14] <dbaron> at least as documented in http://www.tug.org/docs/liang/
# [02:15] <TabAtkins_> [architectural argument about property vs @-rule]
# [02:16] <TabAtkins_> howcome: We already have implemenations, Prince does it with the property.
# [02:16] <TabAtkins_> kojiishi: I dunno what AH does.
# [02:16] <TabAtkins_> jdaggett: What does Adobe think about this?
# [02:16] <TabAtkins_> szilles: I've sent an email to try and find an answer.
# [02:17] <TabAtkins_> szilles: My belief is that we're lacking somewhat in experience in the room for some of these questions.
# [02:17] <TabAtkins_> jdaggett: Okay. i think it would be useful ot have feedback from adobe
# [02:17] <TabAtkins_> szilles: Yes. And MS, too, as they have publishing stuff.
# [02:18] <fantasai> fantasai: btw, Antenna House supports custom dictionaries, but not via hyphenation-resource
# [02:19] <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.
# [02:19] <TabAtkins_> plinss_: We'll leave this open for now.
# [02:20] <TabAtkins_> fantasai: Next is 'text-wrap'
# [02:20] <TabAtkins_> fantasai: I can't find a usecase for 'unrestricted' so far. Thinking of removing it.
# [02:20] <TabAtkins_> dbaron: How is this different from word-wrap: break-word?
# [02:21] <TabAtkins_> fantasai: That's only for emergency breaking. This is all-the-time breaking.
# [02:21] <TabAtkins_> dbaron: Might be useful for ancient greek or roman, but I don't think I care.
# [02:21] <fantasai> plinss: Might be useful for URLs
# [02:21] <TabAtkins_> dbaron: That's emergency breaking, with word-wrap.
# [02:22] <TabAtkins_> bradk: How does this interact with white-space?
# [02:22] <TabAtkins_> fantasai: white-space is now a shorthand property for text-wrap and white-space-collapse
# [02:23] * Joins: johnjan (qw3birc@128.30.52.28)
# [02:23] * Quits: johnjan (qw3birc@128.30.52.28) (Quit: Page closed)
# [02:24] <TabAtkins_> szilles: It would be nice to point out that one of the line-breaking rules was controlled by the word-break property.
# [02:24] <TabAtkins_> fantasai: i can point that out.
# [02:24] <fantasai> RESOLVED: drop unrestricted value from text-wrap
# [02:25] <TabAtkins_> fantasai: next is the word-wrap property. This is emergency-wrapping.
# [02:25] <TabAtkins_> fantasai: We could add a 'hyphenate' value that turns on hyphenation only for emergency breaking.
# [02:25] <TabAtkins_> smfr: If word-wrap breaks a word, do you insert a hyphen?
# [02:26] <TabAtkins_> fantasai: Not with break-word. Yes with theoretical hyphenate value.
# [02:26] <TabAtkins_> Arron: If the hyphen isn't selectable, I think the 'hyphenate' value is okay.
# [02:27] <TabAtkins_> bradk: Seems to be confusing with word-break and this.
# [02:27] <TabAtkins_> fantasai: Seems that way only because of the names. This should be called 'emergency-wrap'
# [02:28] <TabAtkins_> (Emergency rap)
# [02:28] <smfr> in-case-of-emergency-wrap-word
# [02:28] <TabAtkins_> (For when you absolutely need to stop and hammer-time.)
# [02:28] <TabAtkins_> plinss_: Did this property go to CR?
# [02:29] <TabAtkins_> fantasai: No, but there are tons of unprefixed impls unfortunately.
# [02:29] <TabAtkins_> dbaron: I think IE had this since IE4...
# [02:29] <dbaron> IE4 or something else old
# [02:30] <TabAtkins_> fantasai: other question is whether to have a keyword that starts turning off the break restrictions in emergency.
# [02:30] <TabAtkins_> fantasai: Usually you want to break when absolutely necessary, but if you really really want overflow...
# [02:31] <TabAtkins_> szilles: 'hyphenate' makes sense, because it just says "if you can do a better-than-arbitrary job, do so"
# [02:32] <fantasai> arron: note in the spec that hyphenation hyphen isn't selectable
# [02:32] * Quits: dsinger (dsinger@208.54.4.44) (Quit: dsinger)
# [02:32] <TabAtkins_> bradk: I can't think of when you'd want 'none'.
# [02:33] <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.
# [02:33] <TabAtkins_> [talk about priority]
# [02:34] <TabAtkins_> resolved: add 'hyphenate', don't add 'none'
# [02:34] <TabAtkins_> fantasai: next is text-align
# [02:34] <TabAtkins_> fantasai: There was request to specify first line separately from rest, for spanish poetry, for example
# [02:35] <TabAtkins_> dbaron: We're doing first-line align in text-aling, but last-line in a new property?
# [02:35] <TabAtkins_> fantasai: yes, because... [trails off]
# [02:35] <TabAtkins_> szilles: We can do this with ::first-line
# [02:35] <TabAtkins_> fantasai: Ooh, maybe.
# [02:36] <fantasai> fantasai: Ok, so the problem with that is
# [02:37] <fantasai> fantasai: 1. The primarily alignment is the first-line alignment, the rest of the lines wrapping around are a fallback case.
# [02:38] <fantasai> fantasai: If you specify text-align: end; text-align-first: start; then old UAs end align everything, which is not what you want
# [02:38] <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
# [02:39] <TabAtkins_> fantasai: Also, I pulled in <string> alignment.
# [02:39] <TabAtkins_> jdaggett: I don't see a good use-case for <string> alignment
# [02:39] <TabAtkins_> dbaron: This makes the table-width calculation algorithm substantially more expensive.
# [02:40] <TabAtkins_> smfr: You want to align the decimal point to a length, not necessarily the center, right?
# [02:40] <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.
# [02:41] <TabAtkins_> fantasai: And I put the default to be right-align
# [02:41] <TabAtkins_> dbaron: Often in tables you'll have a long header, and then many short numbers which should be aligned and centered.
# [02:41] <TabAtkins_> fantasai: You can do that by also specifying 'center'.
# [02:42] <TabAtkins_> plinss_: If there are multiple instances of the string, which is aligne?
# [02:42] <TabAtkins_> fantasai: The first one.
# [02:43] * Quits: stearns (stearns@192.150.22.5) (Quit: stearns)
# [02:43] <TabAtkins_> szilles: Particularly the "N/A" in the example is very useful, and matches what spreadsheets do.
# [02:43] <TabAtkins_> dbaron: This affects preferred width of table columns. Open question of whether it should affect min-width, and how.
# [02:44] <TabAtkins_> fantasai: I think the cost there becomes a CR issue - if people don't implement due to this, we'll drop it.
# [02:45] <TabAtkins_> fantasai: But I think this is well-specified and good.
# [02:45] <TabAtkins_> dbaron: [describes passage in his intrinsic-with paper concerning this]
# [02:45] <TabAtkins_> dbaron: I don't think you can compute a min-width.
# [02:45] <TabAtkins_> dbaron: I think the dfn is wrong in the case where there's not enough room.
# [02:45] <TabAtkins_> dbaron: I think your def assumes there is enough room to do the alignment.
# [02:46] <TabAtkins_> dbaron: If may be there is no wrapping of text, but simultaneously not enough room to align all of it.
# [02:46] <TabAtkins_> fantasai: Spec says that in that case the alignment is undefined.
# [02:47] <TabAtkins_> szilles: Undefined, or stop aligning?
# [02:47] <TabAtkins_> dbaron: You'd prefer continuous behavior when possible, not just it suddenly dropping the alignment when the cell gets too small.
# [02:48] <TabAtkins_> [discussion about min-width support on cells]
# [02:50] <TabAtkins_> dbaron: Maybe the min-width computation needs even more controls...
# [02:50] <TabAtkins_> howcome: I'd like to talk about match-parent.
# [02:50] <TabAtkins_> howcome: Seems like a slim use-case.
# [02:50] <TabAtkins_> fantasai: No, it's significant.
# [02:51] <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.
# [02:51] <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)
# [02:51] <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.
# [02:52] <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
# [02:52] <TabAtkins_> howcome: Why not 'inherit'?
# [02:53] <TabAtkins_> fantasai: That will inherit 'start' from its parent, which gives us the same problem.
# [02:53] <TabAtkins_> howcome: So adding 'start' and 'end' caused the problem that we're solving with 'match-parent'?
# [02:53] <TabAtkins_> fantasai: 'start' is the default value in 2.1, it's just not stated.
# [02:53] <TabAtkins_> howcome: how about ol:lang(en) > li, and set the property using that selector?
# [02:54] <TabAtkins_> fantasai: I don't htink that works. One of the cases is the defualt UA stylesheet for <option>.
# [02:54] <TabAtkins_> fantasai: In that case you don't know what the direction property of <select> will be, or the language.
# [02:55] <TabAtkins_> fantasai: You can't make a list of all the languages. The i18n group said that directly.
# [02:55] <TabAtkins_> fantasai: So you just can't write a selector in the UA stylesheet that will get you the right behavior here.
# [02:55] <TabAtkins_> fantasai: next is text-align-last
# [02:56] <TabAtkins_> fantasai: It's also used when you can't justify a line.
# [02:57] <TabAtkins_> szilles: thing that's not clear, if I have an anonymous block, the last line in that gets this property?
# [02:57] <TabAtkins_> fantasai: Yes, any time the break isn't a soft wrap.
# [02:57] <TabAtkins_> szilles: Feedback I got was that text-align-justify is complicated, but not sufficiently useful.
# [02:57] <TabAtkins_> fantasai: I've changed some things since I got that feedback. More specific problems?
# [02:58] <TabAtkins_> szilles: The JL task force cam eu pwith a way to scribe, for japanese, how they would end up justifying things.
# [02:58] <TabAtkins_> fantasai: You have japanese, latin, and various punctuation.
# [02:58] <TabAtkins_> fantasai: Punctuation is ua-defined and special.
# [02:58] <TabAtkins_> fantasai: But this tells you how to prioritize other things.
# [02:59] <TabAtkins_> szilles: But yo uhavne't gone far enough to get reasonable results.
# [02:59] <TabAtkins_> fantasai: [explanation of using the values]
# [03:00] <TabAtkins_> howcome: What if you specify one of the cjk values on non-cjk content?
# [03:00] <TabAtkins_> fantasai: You get what it says on the tin.
# [03:00] <TabAtkins_> fantasai: It's specified in the table in the spec.
# [03:01] <TabAtkins_> fantasai: If you don't put any punctuation in your paragraph, you'll get interoperable results.
# [03:01] <TabAtkins_> fantasai: Unfortunately, that's the best I can do.
# [03:01] <TabAtkins_> fantasai: What I have are the main ways of prioritizing things.
# [03:02] <TabAtkins_> fantasai: Please send specific comments to www-style.
# [03:02] <TabAtkins_> szilles: So this property is just talking about different prioritizations of a number of techniques that could be used.
# [03:02] <TabAtkins_> szilles: That's fine, but the exact details of who punctuation interacts still arent' defined.
# [03:03] <TabAtkins_> fantasai: Yeah, because punctuation has all kinds of crazy special behavior in some languages (like japanese).
# [03:03] <TabAtkins_> howcome: If we can't define this behavior, we shouldn't have these values in.
# [03:03] <TabAtkins_> fantasai: There are valid distinctions to be made, which are captured here.
# [03:03] <TabAtkins_> fantasai: I could take out the descriptions and just say "figure out what these mean".
# [03:04] <TabAtkins_> howcome: We need to get interop, though.
# [03:04] <TabAtkins_> szilles: I don't think we should prevent good typesetting just because we can't get exact interop.
# [03:04] <TabAtkins_> fantasai: What you're tweaking is described . The things that we won't get interop on aren't describe.
# [03:04] <TabAtkins_> jdaggett: Can't we infer this from content?
# [03:04] <TabAtkins_> fantasai: How?
# [03:05] <TabAtkins_> jdaggett: I don't see a clear path to implementation here.
# [03:05] <TabAtkins_> jdaggett: You still need to define the bounds of where UAs need to be consistent.
# [03:05] <TabAtkins_> fantasai: I did. If you'd like to improve that...
# [03:06] <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.
# [03:06] <TabAtkins_> szilles: We need a way to distinguish english-in-japanese and japanese-in-english.
# [03:06] <TabAtkins_> szilles: We can sorta say "what's the lang on the paragraph", but that's a weak approximation.
# [03:07] <TabAtkins_> fantasai: I'd like to get to text-decoration before we wrap up this meeting.
# [03:07] <TabAtkins_> szilles: Can you stick an issue in the spec here about "Maybe give better advice?"
# [03:07] <TabAtkins_> fantasai: I can mark an issue for the WG to review and come up with suggestions.
# [03:08] <TabAtkins_> Action to WG: Review the text-justify section for improvements.
# [03:08] * trackbot noticed an ACTION. Trying to create it.
# [03:08] <trackbot> Sorry, couldn't find user - to
# [03:08] <TabAtkins_> fantasai: There was a request to do each-line indentation, for source code or poetry.
# [03:09] <TabAtkins_> fantasai: For text-decoration, I copies over the lines from XSL.
# [03:09] <TabAtkins_> fantasai: People want to turn off decoration in descendants.
# [03:10] <TabAtkins_> fantasai: I put in a rule that a text can have at most one of each type of line.
# [03:11] <TabAtkins_> szilles: If you have transparent colors, you can tell which is done.
# [03:11] <TabAtkins_> fantasai: yeah, or if the font-size is differnt
# [03:11] <TabAtkins_> dbaron: Or the baseline is different, like superscripts
# [03:12] <TabAtkins_> dbaron: With an underlined superscript in an underlined link, you don't want to break the link's underline where the superscript happens.
# [03:12] <TabAtkins_> fantasai: then we have controls over style, color, and which line, controlled separately.
# [03:13] <TabAtkins_> fantasai: What if you wanted to inhibit your ancestor's decoration, but add your own?
# [03:13] <TabAtkins_> fantasai: Like ou wanted to stop the underline and create your own.
# [03:13] <TabAtkins_> dbaron: Just allow all the stuff. "underline no-underline" to inhibit the parent's, and then draw your own.
# [03:14] <TabAtkins_> szilles: You can do it yourself with nested spans.
# [03:14] <TabAtkins_> szilles: So might as well do it here.
# [03:14] <TabAtkins_> howcome: I don't like the combination of names.
# [03:15] * Quits: homata (homata@58.158.182.50) (Quit: Leaving...)
# [03:15] <TabAtkins_> [discussion about a keyword that kills all three decorations at once]
# [03:15] <fantasai> cancel
# [03:17] * Quits: macpherson (macpherson@74.125.122.49) (Quit: macpherson)
# [03:17] <TabAtkins_> Arron: Is cancel per-decoration, or all of them?
# [03:17] <TabAtkins_> fantasai: I think you want to do both.
# [03:17] <dbaron> cancel, cancel-underline, cancel-overline, cancel-strike-through
# [03:17] <TabAtkins_> fantasai: next is text-decoration-skip
# [03:17] <TabAtkins_> fantasai: Controls whether it's painted on images or spaces, or on top of glyph ink.
# [03:18] <TabAtkins_> fantasai: Do we need one that doesn't skip margins and padding? They're skipped by default.
# [03:18] <TabAtkins_> Arron: Don't see a use for that.
# [03:19] <TabAtkins_> fantasai: next is text-underline-position
# [03:19] <TabAtkins_> fantasai: alphabetic is default, then we have below-left and below-right
# [03:20] <TabAtkins_> szilles: For rotated vertical test, I say "below right"...
# [03:20] <bradk> text-decoration: dashed([<dash-width>,<dash-space>]+[,<dash-width>,<dash-space>]*)
# [03:20] <TabAtkins_> fantasai: You do below.
# [03:21] <TabAtkins_> dbaron: Why is this a pair of keywords and not just a hyphenated keyword?
# [03:21] <TabAtkins_> dbaron: random naming question - text-underline-style: wave or wavy?
# [03:22] <TabAtkins_> fantasai: I have no opinion.
# [03:23] <Xaxio> noun or adjective? text-decoration: underline is a noun, so I'd vote for noun
# [03:23] * Quits: homata_ (homata_@58.158.182.50) (Client exited)
# [03:24] <TabAtkins_> fantasai: [overview of text-emphasis]
# [03:24] <TabAtkins_> szilles: The feedback I got is "draw marks", with the implication that this is done as a graphic process.
# [03:25] <TabAtkins_> szilles: So rather than "draw small circles as marks", say "use XXX character"
# [03:25] <TabAtkins_> fantasai: The UA is allowed to use other characters.
# [03:25] <TabAtkins_> smfr: We ipmlement this, but use the chars.
# [03:25] <TabAtkins_> szilles: So require using the chars.
# [03:26] <TabAtkins_> fantasai: [points out passage talking about glyph usage]
# [03:26] <TabAtkins_> szilles: Given that text, just say to use XXX character and then the prose overrides that when necessary.
# [03:27] <fantasai> s/Draw/Display/
# [03:27] <TabAtkins_> szilles: that's better, but I want to emphasize using the glyph
# [03:27] <TabAtkins_> fantasai: [describes text-emphasis-position]
# [03:28] <TabAtkins_> fantasai: Something to address is that epub has ruby-position, which isn't in this module.
# [03:28] <TabAtkins_> fantasai: It's the one thing from Ruby that epub needs.
# [03:29] <TabAtkins_> fantasai: And they'll put it in, prefixed, if necessary.
# [03:29] <TabAtkins_> fantasai: If we're planning to change things here with ruby, that conversation needs to happen sooner rather than later.
# [03:30] <TabAtkins_> fantasai: Koji and I noticed that 'before' and 'after' aren't accurate on ruby-poistion here, due to rotate glyphs.
# [03:30] * Joins: howcome (howcome@63.245.220.224)
# [03:30] <TabAtkins_> jdaggett: I think bopomofo is peculiar.
# [03:30] <TabAtkins_> fantasai: yeah, I disagree with that change.
# [03:31] <TabAtkins_> szilles: I recommend 'inter-character'
# [03:31] <TabAtkins_> RESOLVED: use 'inter-character' instead of 'bopomofo'.
# [03:31] * Joins: homata_ (homata_@58.158.182.50)
# [03:32] <TabAtkins_> fantasai: and Koji and I think we should use the text-emphasis-position values for ruby-position as well.
# [03:32] <TabAtkins_> szilles: If you have emphasis and ruby, do you stack or not, and in what order?
# [03:32] <TabAtkins_> fantasai: Some pubs will stack it, some will swap the sides one is on, and some will drop one or the other.
# [03:32] <TabAtkins_> Arron: I think we shouldn't worry about this today.
# [03:33] <TabAtkins_> szilles: Let's just note that there may be a need for a control here.
# [03:33] * Bert is at SFO. You're still meeting?
# [03:33] * TabAtkins_ Yes, Bert.
# [03:33] <jdaggett> yes
# [03:33] * TabAtkins_ O_o
# [03:34] <TabAtkins_> szilles: I'd like to see an example of underlines in mongolian.
# [03:34] * jdaggett elika and steve are trying to keep us here until 10pm, at which point the CSS3 Text sleepover starts
# [03:34] <TabAtkins_> fantasai: The problem is putting chinese in mongolian, which is surprisingly common
# [03:34] <TabAtkins_> [talk about underlines in chinese/mongolian]
# [03:34] * sylvaing shudders
# [03:34] * jdaggett mongolian pillow fight!!!
# [03:35] * sylvaing didn't know there was a CSS3 Text Sleepover module
# [03:36] <TabAtkins_> howcome: There seem to be some general properties here that apply to every language.
# [03:36] * Bert thinks that's the one with the Cascading Bed Sheets
# [03:36] <TabAtkins_> howcome: And then there are some that apply to only a few languages (important ones, but still)
# [03:37] <TabAtkins_> howcome: I suggest we separate out the script-specific stuff from the generic stuff.
# [03:37] * sylvaing bets that howcome is about to suggest text-replace again
# [03:37] * Quits: kojiishi (kojiishi@222.158.227.129) (Quit: Leaving...)
# [03:37] * jdaggett all problems can be resolved with text-replace
# [03:37] <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.
# [03:38] <TabAtkins_> fantasai: It would be a ton of work for little benefit.
# [03:39] <TabAtkins_> [talk about relative value]
# [03:39] * TabAtkins_ is dying.
# [03:40] * sylvaing interpreted 'from 8,000ft to below sea level' as 'GCPM'
# [03:42] <fantasai> howcome: I think we should split the spec
# [03:42] <fantasai> plinss: I challenge howcome to come up with the split
# [03:42] * Joins: kojiishi (kojiishi@222.158.227.129)
# [03:43] <fantasai> plinss: One way we can split is to mark them all at-risk and push to CR, see if we get implementations
# [03:43] <fantasai> jdaggett: I'm concerned that they'll get implemented, but implemented wrong
# [03:43] <fantasai> Steve: You've got to have an architectural base into which to put things
# [03:47] * Quits: smfr (smfr@63.245.220.224) (Quit: smfr)
# [03:48] <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.
# [03:48] * Quits: bradk (bradk@63.245.220.224) (Quit: Computer has gone to sleep)
# [03:48] * Quits: sylvaing (sylvaing@63.245.220.224) (Ping timeout)
# [03:49] <fantasai> Meeting closed.
# [03:49] * Quits: Jay (jay@63.245.220.224) (Quit: CHOCOA)
# [03:49] * Quits: plinss_ (plinss@63.245.220.224) (Quit: plinss_)
# [03:49] * Quits: shan (qw3birc@128.30.52.28) (Quit: Page closed)
# [03:49] * Quits: jdaggett (jdaggett@63.245.220.224) (Quit: jdaggett)
# [03:50] * Quits: dbaron (dbaron@63.245.220.240) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [03:51] * Quits: Kazutaka (yamamoto_k@63.245.220.224) (Quit: CHOCOA)
# [03:51] * Quits: Arron (arronei@63.245.220.224) (Ping timeout)
# [03:51] * Quits: TabAtkins_ (tabatkins@63.245.220.224) (Ping timeout)
# [03:52] * Quits: howcome (howcome@63.245.220.224) (Ping timeout)
# [03:56] * Quits: szilles (chatzilla@63.245.220.224) (Ping timeout)
# [03:56] * Quits: shonda (shonda@63.245.220.224) (Ping timeout)
# [05:04] * Joins: dsinger (dsinger@68.126.203.46)
# [05:41] * Quits: dsinger (dsinger@68.126.203.46) (Quit: dsinger)
# [05:54] * Joins: arno (arno@208.87.61.227)
# [06:10] * Quits: kennyluck (kennyluck@128.30.52.169) (Quit: kennyluck)
# [06:11] * Joins: kennyluck (kennyluck@128.30.52.169)
# [06:25] * Quits: arno (arno@208.87.61.227) (Quit: Leaving.)
# [06:31] * Joins: plinss_ (plinss@72.254.104.112)
# [06:41] * Joins: plinss__ (plinss@72.254.104.112)
# [06:41] * Quits: plinss_ (plinss@72.254.104.112) (Connection reset by peer)
# [06:58] * Quits: plinss__ (plinss@72.254.104.112) (Ping timeout)
# [07:01] * Joins: plinss_ (plinss@72.254.104.112)
# [07:04] * Quits: plinss_ (plinss@72.254.104.112) (Quit: plinss_)
# [07:10] * Joins: homata__ (homata_@58.158.182.50)
# [07:10] * Quits: homata_ (homata_@58.158.182.50) (Ping timeout)
# [07:15] * Joins: plinss_ (plinss@72.254.104.112)
# [07:21] * Quits: kojiishi (kojiishi@222.158.227.129) (Quit: Leaving...)
# [07:34] * Joins: jdaggett (jdaggett@70.36.214.37)
# [07:35] * Quits: kennyluck (kennyluck@128.30.52.169) (Quit: kennyluck)
# [07:54] * Quits: jdaggett (jdaggett@70.36.214.37) (Quit: jdaggett)
# [08:53] * Joins: anne (annevk@83.85.115.123)
# [09:02] * Quits: plinss_ (plinss@72.254.104.112) (Ping timeout)
# [09:36] * Joins: plinss_ (plinss@72.254.104.112)
# [09:42] * Joins: homata (homata@58.158.182.50)
# [09:52] * Quits: plinss_ (plinss@72.254.104.112) (Ping timeout)
# [10:00] * Joins: plinss_ (plinss@72.254.104.112)
# [10:22] * Quits: plinss_ (plinss@72.254.104.112) (Ping timeout)
# [10:28] * Quits: anne (annevk@83.85.115.123) (Client exited)
# [10:28] * Joins: anne (annevk@83.85.115.123)
# [11:15] * Joins: homata_ (homata@58.158.182.50)
# [11:18] * Quits: homata (homata@58.158.182.50) (Ping timeout)
# [12:18] * Quits: arronei (arronei@131.107.0.94) (Ping timeout)
# [12:23] * Quits: homata_ (homata@58.158.182.50) (Ping timeout)
# [12:24] * Joins: arronei (arronei@131.107.0.110)
# [12:37] * Joins: plinss_ (plinss@72.254.104.112)
# [14:04] * Joins: kennyluck (kennyluck@128.30.52.169)
# [14:23] * Quits: plinss_ (plinss@72.254.104.112) (Ping timeout)
# [14:40] * Joins: karl (karlcow@128.30.54.58)
# [15:10] * Quits: karl (karlcow@128.30.54.58) (Quit: Freedom - to walk free and own no superior.)
# [15:22] * Joins: jdaggett (jdaggett@70.36.214.37)
# [16:34] * Joins: plinss_ (plinss@72.254.60.85)
# [16:42] * Quits: plinss_ (plinss@72.254.60.85) (Ping timeout)
# [16:57] * Joins: Arron (arronei@64.168.229.50)
# [16:57] * Quits: Arron (arronei@64.168.229.50) (Quit: Arron)
# [16:57] * Joins: Arron (arronei@64.168.229.50)
# [16:58] * Quits: Arron (arronei@64.168.229.50) (Quit: Arron)
# [16:58] * Joins: Arron (arronei@64.168.229.50)
# [16:59] * Quits: Arron (arronei@64.168.229.50) (Quit: Arron)
# [16:59] * Joins: arronei_ (arronei@64.168.229.50)
# [17:20] * Joins: Martijnc (Martijnc@91.176.24.181)
# [17:26] * Joins: szilles (chatzilla@192.150.10.200)
# [17:29] * Joins: shonda (shonda@24.6.162.105)
# [17:29] * Joins: myakura (myakura@123.224.162.182)
# [17:30] * Quits: szilles (chatzilla@192.150.10.200) (Ping timeout)
# [17:31] * Joins: szilles (chatzilla@192.150.10.200)
# [17:41] * Quits: shonda (shonda@24.6.162.105) (Quit: Leaving...)
# [17:43] * Joins: TabAtkins_ (tabatkins@216.239.45.4)
# [17:46] * Quits: arronei_ (arronei@64.168.229.50) (Quit: arronei_)
# [17:49] * Quits: szilles (chatzilla@192.150.10.200) (Quit: ChatZilla 0.9.86 [Firefox 3.6.14/20110218125750])
# [18:02] * Joins: dsinger (dsinger@67.218.110.90)
# [18:11] * Quits: TabAtkins_ (tabatkins@216.239.45.4) (Ping timeout)
# [18:17] * Joins: plinss_ (plinss@64.168.229.50)
# [18:31] * Quits: dsinger (dsinger@67.218.110.90) (Quit: dsinger)
# [18:35] * Joins: TabAtkins_ (tabatkins@216.239.45.4)
# [18:38] * Joins: arno (arno@192.150.10.200)
# [18:55] * Quits: TabAtkins_ (tabatkins@216.239.45.4) (Ping timeout)
# [18:57] * Quits: plinss_ (plinss@64.168.229.50) (Quit: plinss_)
# [18:58] * Quits: jdaggett (jdaggett@70.36.214.37) (Quit: jdaggett)
# [19:51] * Joins: jdaggett (jdaggett@63.245.220.240)
# [19:58] * Quits: myakura (myakura@123.224.162.182) (Client exited)
# [19:58] * Joins: dbaron (dbaron@63.245.220.240)
# [20:03] * Quits: arno (arno@192.150.10.200) (Quit: Leaving.)
# [20:06] * Joins: arno (arno@192.150.10.200)
# [20:23] * Joins: TabAtkins_ (tabatkins@216.239.45.4)
# [21:02] * Quits: Martijnc (Martijnc@91.176.24.181) (Quit: Martijnc)
# [21:37] <dbaron> ok, I have patches for uri-016.xht that work
# [21:37] <dbaron> though I broke a test related to unclose paretheses that's probably a simple fix, but that's for after lunch
# [22:18] * Quits: arno (arno@192.150.10.200) (Ping timeout)
# [22:24] * Joins: arno (arno@192.150.10.200)
# [22:39] * Joins: shepazu (schepers@128.30.52.169)
# [22:53] * Quits: shepazu (schepers@128.30.52.169) (Quit: Core Breach)
# [22:55] * Quits: jdaggett (jdaggett@63.245.220.240) (Connection reset by peer)
# [22:56] * Joins: jdaggett (jdaggett@63.245.220.240)
# [23:13] * Joins: plinss_ (plinss@67.79.220.84)
# [23:51] * Quits: plinss_ (plinss@67.79.220.84) (Quit: plinss_)
# Session Close: Fri Mar 11 00:00:00 2011

The end :)