/irc-logs / w3c / #css / 2008-08-21 / end

Options:

# Session Start: Thu Aug 21 00:00:00 2008
# Session Ident: #css
# [00:00] * Joins: dbaron (dbaron@131.111.225.1)
# [00:04] * Quits: shepazu (schepers@128.30.52.30) (Ping timeout)
# [00:11] * Joins: MoZ (chatzilla@82.230.92.154)
# [00:19] * Quits: dbaron (dbaron@131.111.225.1) (Connection timed out)
# [00:19] * Joins: dbaron (dbaron@131.111.225.1)
# [00:36] * Quits: dbaron (dbaron@131.111.225.1) (Connection timed out)
# [00:36] * Joins: dbaron (dbaron@131.111.225.1)
# [00:45] * Quits: dbaron (dbaron@131.111.225.1) (Ping timeout)
# [00:49] * Quits: plinss_ (plinss_uk@217.41.49.207) (Ping timeout)
# [01:05] * Quits: MoZ (chatzilla@82.230.92.154) (Quit: ChatZilla 0.9.83 [Firefox 3.0.1/2008070206])
# [01:18] * Joins: melinda (melinda.gr@67.142.45.126)
# [01:40] * Quits: melinda (melinda.gr@67.142.45.126) (Connection reset by peer)
# [01:44] * Quits: jdaggett (jdaggett@131.111.225.1) (Quit: jdaggett)
# [04:04] * Joins: melinda (melinda.gr@67.142.45.126)
# [05:33] * Joins: shepazu (schepers@128.30.52.30)
# [06:07] * Quits: shepazu (schepers@128.30.52.30) (Ping timeout)
# [06:18] * Joins: shepazu (schepers@128.30.52.30)
# [06:34] * Quits: shepazu (schepers@128.30.52.30) (Ping timeout)
# [06:54] * Joins: jdaggett (jdaggett@131.111.225.1)
# [08:24] * Joins: dbaron (dbaron@131.111.225.1)
# [08:33] * Quits: dbaron (dbaron@131.111.225.1) (Ping timeout)
# [08:59] * Joins: alexmog (alexmog@78.25.227.21)
# [09:15] * Quits: arronei (arronei@131.107.0.71) (Ping timeout)
# [09:19] * Joins: shepazu (schepers@128.30.52.30)
# [09:20] * Joins: arronei (arronei@131.107.0.104)
# [09:34] * Quits: alexmog (alexmog@78.25.227.21) (Ping timeout)
# [09:47] * Quits: jdaggett (jdaggett@131.111.225.1) (Ping timeout)
# [09:54] * Joins: alexmog (alexmog@131.107.0.75)
# [10:11] * Joins: jdaggett (jdaggett@213.199.146.138)
# [10:15] * Joins: anne (annevk@213.199.146.138)
# [10:16] * Joins: glazou (daniel@213.199.146.138)
# [10:32] * Joins: dbaron (dbaron@213.199.146.138)
# [10:35] * Joins: plinss_ (plinss_uk@213.199.146.138)
# [10:36] <dbaron> RRSAgent, make logs public
# [10:36] <RRSAgent> I have made the request, dbaron
# [10:36] <dbaron> ScribeNick: dbaron
# [10:36] <dbaron> Meeting: CSS Working Group Face-to-Face
# [10:36] <dbaron> Topic: GCPM
# [10:38] <dbaron> Håkon: This draft is a clearinghouse for print-related features that didn't fit elsewhere.
# [10:40] <dbaron> Håkon: Until recently, it's mainly prince, but we've recently heard of another implementation.
# [10:40] * Joins: SaloniR (d5c78094@128.30.52.43)
# [10:41] * Joins: plh (plh@128.30.52.28)
# [10:41] <dbaron> Håkon: The draft has moved a bit recently. Posted a new editor's draft based on feedback.
# [10:41] <plh> rrsagent, where am I?
# [10:41] <RRSAgent> See http://www.w3.org/2008/08/21-css-irc#T08-36-48
# [10:41] <dbaron> Håkon: Stable parts: running headers/footers, leaders, footnotes, hyphenation, image resolution, cross-references, page marks, bookmarks.
# [10:41] <dbaron> Håkon: These have implementations and not many requests for changes.
# [10:42] <dbaron> s/bookmarks/bookmarks, CMYK colors/
# [10:42] * Joins: r12a (ishida@128.30.52.30)
# [10:42] <dbaron> Håkon: Developing parts: named page lists (page sequences), character substitution, page floats.
# [10:43] <dbaron> PLH: Intended only for print media?
# [10:43] <dbaron> Håkon: That's currently in the document that it's only intended for print media, but some could be reused outside of print.
# [10:43] <fantasai> Should be here: http://dev.w3.org/csswg/css3-gcpm (I'm still waiting for it to load)
# [10:44] * Joins: SteveZ (d5c7928a@128.30.52.43)
# [10:44] <glazou> fantasai: can't reach it
# [10:44] <fantasai> blame w3c IT
# [10:45] <fantasai> or MS IT
# [10:45] <glazou> eh
# [10:45] <dbaron> Alex: Most things in the spec could apply to interactive view. But some things wouldn't work well there. Do we want to look at this ignoring interactive view, or considering it?
# [10:45] <glazou> fantasai: http://www.w3.org/Style/Group/css3-src/css3-gcpm/Overview.html
# [10:45] <dbaron> Bert: Not for the module to say what's for what media type; that's for the profile.
# [10:46] <dbaron> Håkon: I don't want this to be a threat to, e.g., progressive rendering.
# [10:46] <plh> indeed, dev.w3.org is not responsive
# [10:46] <dbaron> Peter: I want browsers to support this when they're printing.
# [10:46] <dbaron> Håkon: absolutely
# [10:47] <dbaron> Alex: There are very few features that are only print-specific. So I'm not sure how much value is in ignoring interaction when we discuss this -- or can we get ourselves in trouble by making things that are hard to make interactive.
# [10:48] * plh notes that we had a cvs upgrade yesterday or the day before...
# [10:48] * plh it looks like the upgrade didn't go that well :(
# [10:48] * plh gets reports that webapps folks have similar issues
# [10:48] <dbaron> Elika: I think we probably want some pieces to move to other drafts.
# [10:49] <dbaron> (discussion about whether cmyk() is actually defined, etc.)
# [10:50] <dbaron> Steve: ICC probably has something that talks about CMYK, but I don't know what off the top of my head
# [10:50] <dbaron> Håkon: Another feature that can be reused is border-length.
# [10:51] <dbaron> Elika: We could reuse border-radius and have a border-corner-shape
# [10:51] <dbaron> Peter: Wouldn't that preclude rounded corders like that?
# [10:52] <dbaron> David: This seems separate from border-radius.
# [10:53] <dbaron> Elika: border-corner-shape: [ sides | corner ] || [ round | sharp ]
# [10:54] <dbaron> Alex: border-length is a little more intuitive
# [10:54] <dbaron> Håkon: What about covering only non-corners.
# [10:54] <dbaron> Steve: Concern about overloading radius.
# [10:54] <dbaron> Steve: Can't use radius for both amount to show and the curvature.
# [10:55] <dbaron> Håkon: Maybe syntax from border-radius, but on a new property?
# [10:56] <dbaron> Elika: But we'd want it to take percentages.
# [10:56] <dbaron> Elika: And you'd want to be able to invert it to take only the middle.
# [10:56] <dbaron> Bert: Do we really need all this, given border-image and SVG?
# [10:56] <dbaron> Håkon: This came out of a simple request for footnotes.
# [10:57] <dbaron> Håkon: But it seems to be reusable. I've seen all these limited borders since I started this.
# [10:58] <dbaron> ?: Can we put it in backgrounds and borders?
# [10:58] <dbaron> Elika: Yes... but we should mark it at risk.
# [10:58] <dbaron> Peter: Implementations?
# [10:58] <dbaron> Håkon: No
# [11:00] <dbaron> Håkon: So we want a new property like border-radius, plus another new property for the shape (e.g., for diagonal corner, or for inverted).
# [11:00] <dbaron> Alex: What happens when length is less than radius?
# [11:00] <dbaron> Steve: It's a mask.
# [11:00] <dbaron> Steve: I'd suggest calling it 'border-mask'.
# [11:00] <dbaron> David: That sounds like something else.
# [11:01] <dbaron> Steve: 'border-clip' ?
# [11:04] <dbaron> (drawings)
# [11:04] <dbaron> Daniel: This goes far beyond gcpm.
# [11:05] <dbaron> ?: to borders and backgrounds
# [11:05] <dbaron> Steve: Math people want adjustable brackets.
# [11:05] <dbaron> Elika: You don't want that with borders - you want a font.
# [11:07] <dbaron> Peter: What's the 'auto' value?
# [11:07] <dbaron> Håkon: 'auto' within lists copies from a different corner
# [11:08] <dbaron> Peter: Initial value should be a complete border.
# [11:08] <dbaron> Peter: Is that 'auto'?
# [11:08] <dbaron> Håkon: OK, 'auto' should be the initial value and mean the complete border is used.
# [11:09] <dbaron> David: You could make v/h %ages refer to width/height.
# [11:09] <dbaron> Alex: Then you can't get %ages square.
# [11:09] <dbaron> Håkon: Text replacement: necessary for printing to fix up quote characters.
# [11:10] <dbaron> Daniel: This is transformation, not style.
# [11:11] <dbaron> Daniel: Transformations of the document with a simple syntax are needed. I did that 10 years ago with STTS. But don't call that CSS.
# [11:11] <dbaron> Håkon: We should have a new content type?
# [11:11] <dbaron> Daniel: No, but put it in another spec.
# [11:12] <dbaron> Daniel: I have no problem mixing it with text/css, but put it in another spec.
# [11:12] <dbaron> Steve: If there were an element there, I could do it with 'content' and it would be style.
# [11:13] <dbaron> Steve: If the selectors allowed me to select a given textual string and make it a pseudo-element, then that would be consistent with the rest of the language.
# [11:13] <dbaron> Steve: The point here is that it's un-marked-up elements.
# [11:14] <dbaron> Håkon: This example (s/Soviet Union/Russia/) was meant to scare the kids.
# [11:14] <dbaron> Daniel: This should be a script that the printer driver offers you.
# [11:15] <dbaron> Steve: There's no reason I don't want to see this on the screen.
# [11:15] <dbaron> Daniel: Once we do this, people will want much more transformation.
# [11:16] <dbaron> Alex: Open quotes and close quotes are harder.
# [11:17] <dbaron> Daniel: Having transformations with CSS syntax has problems with the cascade.
# [11:17] <fantasai> Daniel: You can transform the document in ways that cause further transformations
# [11:18] <fantasai> Daniel: And you can get into a loop that way
# [11:18] <fantasai> Daniel: You want transformations as a sequence
# [11:18] <fantasai> Daniel: That is why I did not combine STTS with CSS
# [11:18] <fantasai> Steve: THis problem came up in XML and it was never simple
# [11:18] <fantasai> Howcome: THis doesn't change the structure of the document.
# [11:19] <fantasai> Bert, Fantasai, Daniel: Not yet.
# [11:20] <dbaron> Håkon: The replacements are applied sequentially.
# [11:20] <fantasai> Howcome: the text replacements are sequential according to the list in the text-replace property
# [11:20] <dbaron> David: Is it inherited?
# [11:21] <fantasai> Daniel: body { text-replace: "Soviet Union" "Russia"; } p { text-replace: "Russia" "Soviet Union"; } What happens?
# [11:21] <fantasai> Fantasai: It doesn't matter in this case
# [11:23] <fantasai> Daniel: If you want to solve the problem of circular transformation
# [11:23] <fantasai> Daniel: You can do that with a selector.
# [11:23] <fantasai> Daniel: If you have "Soviet Union" over two different elements, what is the result?
# [11:23] <fantasai> Howcome: In Prince you cannot make matches across element boundaries.
# [11:24] <fantasai> Alex: In case something in GCPM doesn't make it into CSS3 whatever, do we have a plan of what happens to it?
# [11:24] <fantasai> Alex: Is GCPM going to be a home for things we're not doing yet and pull out things like page floats that we find popular into other drafts?
# [11:25] <fantasai> Yes
# [11:25] <fantasai> Howcome: We should do that, but there are a core set of functionality like footnotes that are paged media specific
# [11:25] <fantasai> Peter, Alex: I don't think footnotes are paged-media specific
# [11:26] <fantasai> Daniel: back to text-replace. First, it's really underspecified.
# [11:26] * anne wonders if the footnotes stuff works together with the minimum HTML5 did for footnotes
# [11:26] <fantasai> Daniel: Second, I can agree on the usefulness. I want it in a standalone document. It does not belong to style.
# [11:27] <fantasai> Howcome: It's not going to get it's own document type.
# [11:27] <fantasai> Daniel: Why not
# [11:27] <fantasai> Bert mentions XSLT
# [11:28] <fantasai> Discussion about how this doesn't go far enough to be useful for some of the major use cases unless you have regex..
# [11:28] <fantasai> Steve: In the font capability we're thinking of extending the font feature to enable open-type features.
# [11:28] <fantasai> Steve: That would solve your quote problem.
# [11:28] <anne> (though I suppose you could match on ' "' and '."' or something
# [11:28] <anne> )
# [11:28] <fantasai> Steve: There are features in the font that allow you to trigger mappings of character to glyphs
# [11:29] <fantasai> John: For example, a lot of fonts enable a slashed zero. They have an alternate glyph, and you can enable that feature.
# [11:29] <fantasai> Howcome: That might turn out to be a solution. I personally cannot edit OpenType
# [11:29] <fantasai> John: You'd specify it through font-variant
# [11:29] <Bert> (I do need (and use daily) something of the power of XSLT. Would be nice if there were something with a better syntax, but I want people to have the choice to use XSLT as well. Hence we need to keep this separate from CSS.)
# [11:30] <fantasai> Peter: I think the thing you match against the original text.
# [11:31] <fantasai> David: Then you have to merge the replacements.
# [11:31] <fantasai> David: What happens if your replacements overlap? E.g. you replace "Soviet Union" and you replace "Union".
# [11:32] <fantasai> Howcome: You define a sequence. There's no infinite loop here.
# [11:32] <fantasai> Ishida: What is your use case here?
# [11:32] <fantasai> Ishida: You've got a document someone has written, and you want to print it?
# [11:33] <fantasai> Howcome: Or I wrote it. I don't want to type the long unicode sequences.
# [11:33] <fantasai> Peter: That's a very weak argument. If you're talking about a document you didn't write, then you have a use case.
# [11:33] <fantasai> Daniel: These are not something you are associating with the document anyway.
# [11:34] <fantasai> Daniel: So it is a local thing. You don't need a MIME type
# [11:34] <fantasai> Peter: I can see you using it in a collaborative process when someone scans text and posts it, someone else writes a style sheet for it.
# [11:35] <fantasai> fantasai: why can't it be a separate transformation sheet, like XSLT or STTS?
# [11:38] <fantasai> Daniel: body { text-replace: "Soviet" "Russia"; } p { text-replace: "Soviet" "CEI"; }
# [11:40] <dbaron> Håkon: The replacements on ancestors would happen before replacements on descendants.
# [11:41] <dbaron> Elika: This shouldn't be in CSS, so you don't have all the declarations apply rather than having them override each other by cascading and inheritance.
# [11:41] <fantasai> s/don't/can/
# [11:41] <dbaron> Steve: Should record: with the selector approach, you have the overlap problem.
# [11:42] <dbaron> *:text("Soviet") { content: "CEI"; }
# [11:43] <fantasai> David: If you make this an inherited property, then you have more overriding happening and you don't have these problems.
# [11:43] <fantasai> David: Only one text-replace value ever applies to a given run of text.
# [11:43] <dbaron> Håkon: I think we should take what we have two implementations of and make a spec of it.
# [11:44] <dbaron> Steve: I think this feature should be a separate document.
# [11:44] <dbaron> Peter: I think it depends on how this feature is defined.
# [11:44] <dbaron> Håkon: I'm happy to make a separate document out of it, as long as it's not taken out to be killed.
# [11:44] <dbaron> Steve: I think there are a number of options on the table, and making it a separate document lets us pursue those options.
# [11:45] <dbaron> Peter: My other concern there is that we're rechartering, and we have a small number of modules to make progress on.
# [11:45] <anne> (that should be ::text fwiw)
# [11:45] <anne> (though the board is indeed wrong)
# [11:45] <dbaron> Peter: I'm comfortable leaving it here until it's cooked; most of this seems like it can be moved into other modules.
# [11:45] <dbaron> Håkon: Bookmarks.
# [11:46] <dbaron> Håkon: This is a way to generate PDF bookmarks.
# [11:46] <dbaron> Håkon: It's modeled after what PDF can take.
# [11:46] <dbaron> Daniel: It's like a TOC.
# [11:46] <dbaron> Steve: It's a tree.
# [11:46] <dbaron> Daniel: It's a way of copying some element into a new special box?
# [11:47] <dbaron> Håkon: It's not a box, it's a logical structure.
# [11:47] <dbaron> Alex: Why not call it table-of-contents-level?
# [11:47] <dbaron> Anne: How is it stylistic?
# [11:47] <dbaron> Håkon: You need this when you generate PDF.
# [11:47] <dbaron> Anne: Can't HTML specify this?
# [11:48] <Bert> (<link rel=bookmark href="#sect5">)
# [11:48] <dbaron> Anne: The PDF generator should just extract it from the semantics of the document.
# [11:48] <dbaron> Steve: If it's an XML document, how do you do it?
# [11:48] * Joins: dsinger (dsinger@217.167.116.128)
# [11:48] <dbaron> Håkon: This is a pragmatic issue for CSS processors that want to create PDF files.
# [11:49] <anne> (If it's XML you convert it to XHTML.)
# [11:49] <fantasai> Alex: It's information used in another output format.
# [11:49] <fantasai> Alex: It doesn't have to be CSS if it doesn't have any rendering effect in CSS
# [11:50] <dbaron> Elika: It's adding semantic metadata to the document, not style.
# [11:51] <dbaron> Alex: You could also have the data in a META in the HTML.
# [11:51] <dbaron> Steve: But the selectors are more powerful.
# [11:52] <dbaron> Daniel: Why don't you use counters?
# [11:53] <dbaron> Elika: This is trying to do transformations and semantic tagging (using the power of selectors), which don't belong in style sheets.
# [11:53] <dbaron> Håkon: We're doing links and ??? in Opera ... we're not going to take that out.
# [11:54] <dbaron> Steve: We have electronic presentation forms, of which the bookmarks are a part.
# [11:54] <dbaron> Peter: I agree that this is a presentational issue.
# [11:55] <dbaron> Elika: Displaying the title of the document in the window title bar is similar, but we shouldn't do that in CSS.
# [11:55] <dbaron> Peter: I don't think this is absolutely out of scope.
# [11:56] <dbaron> Steve: If you want to claim CSS applies outside HTML, there's no way for an XML document to put something in the title.
# [11:56] <dbaron> Peter: Putting the window title in HTML is violating separation of presentation and content.
# [11:56] <dbaron> Elika: It's not about presentation; it's the title of the document.
# [11:56] <dbaron> Peter: These distinctions aren't always obvious.
# [11:57] <dbaron> Elika: You want to say "I am the title of the document", not "put me in the title bar".
# [11:57] * Quits: alexmog (alexmog@131.107.0.75) (Ping timeout)
# [11:57] <dbaron> Elika: That's semantic tagging.
# [11:57] * Joins: alexmog (alexmog@131.107.0.102)
# [11:57] <fantasai> Elika: The title is used for more than the title of the window, it's also used for bookmarking and in history
# [11:57] <dbaron> Peter: I don't want to kill it right off the bat.
# [11:57] <dbaron> Bert: No, let's kill it.
# [11:58] <fantasai> Elika: And other places in the UI
# [11:58] <fantasai> Elika: You want to do that with other XML formats, but you don't want to do it by saying "Put me in the title bar", you want to do it by saying "I am the title, present me appropriately". And that is semantic tagging, not styling.
# [11:59] <dbaron> Daniel: In Håkon's proposal, the bookmarks themselves cannot be styled.
# [11:59] <dbaron> Håkon: PDF can't do it.
# [11:59] <dbaron> ?: Although that doesn't mean a browser couldn't.
# [12:00] <dbaron> Håkon: This is a necessary feature for those of us who generate PDF files.
# [12:00] <dbaron> Steve: Where would you put it?
# [12:00] <dbaron> Elika: Some semantic tagging languag.
# [12:01] <dbaron> Håkon: Authors won't specify this.
# [12:01] <dbaron> David: It's in the user agent (e.g., style sheet... although preferably not).
# [12:01] <dbaron> Richard: ?
# [12:01] <dbaron> Anne: H1 would just be part of the document outline
# [12:01] <dbaron> Steve: What level of headings would you stop at?
# [12:01] <dbaron> Anne: Why would you stop?
# [12:02] <dbaron> Daniel: Limit depth.
# [12:02] <dbaron> Bert: Collapsable lists... leave that to the user.
# [12:03] <dbaron> Daniel: We see the power of doing this with CSS syntax, etc., but we don't agree it should be in CSS
# [12:03] <dbaron> Håkon: It's in GCPM, which is in a separate space.
# [12:03] * Quits: alexmog (alexmog@131.107.0.102) (Ping timeout)
# [12:04] * Joins: alexmog (alexmog@131.107.0.102)
# [12:05] <dbaron> Anne: Document outline is in HTML5.
# [12:06] <dbaron> Steve: Did you look at XSL-FO for bookmarks?
# [12:06] <dbaron> Håkon: I should.
# [12:06] <dbaron>
# [12:26] <fantasai> Extensions to the float property
# [12:27] <fantasai> Howcome: Discussed on the mailing list recently. Antenna House has lots of good ideas.
# [12:27] <fantasai> Howcome: There are four different alternatives.
# [12:27] <fantasai> Howcome: First we extend float with 'inside' and 'outside'.
# [12:27] <fantasai> Howcome: synonyms for left and right depending on which page you're on
# [12:27] <fantasai> Howcome: Then we add 'top' 'bottom
# [12:27] <fantasai> Howcome: for vertical
# [12:28] <fantasai> Thenw e have reference keywords: 'page', 'column', 'multi-column'
# [12:28] <fantasai> Howcome: Then we have conditional keywords: 'unless-room' | 'hide-unless'
# [12:28] <fantasai> Howcome: so that advertisers can use any unused whitespace on the page
# [12:28] <fantasai> Alex: you could have adverts of different size
# [12:29] <fantasai> s/hide-unless/hide-unless-room/
# [12:31] <fantasai> Howcome: float: top next page unless-room; Moves figure to top of next page unless room on current page
# [12:31] <fantasai> Alex: How is this different from the default behavior of floats?
# [12:32] <fantasai> Howcome draws on the whiteboard two pages
# [12:32] <fantasai> first page-half-filled with text
# [12:32] <fantasai> then a large image
# [12:32] <fantasai> that doesn't fit
# [12:32] <fantasai> normally it gets pushed to the next page
# [12:32] <fantasai> and text fills after the image
# [12:32] <fantasai> this would allow the image to shift over to the next page
# [12:32] <fantasai> bu the text to continue filling on the first page
# [12:32] <fantasai> Alex: Couldn't that just be regular float and clear?
# [12:34] <fantasai> top allows float to move above placeholder
# [12:34] <fantasai> Peter: that can get you into potential race conditions
# [12:34] <fantasai> Alex: that can be resolved
# [12:34] <Bert> ("float: top next page unless room" could be more compactly be called "float: here")
# [12:35] <fantasai> Bert: you want the image centered. You only float it if it doesn't fit: it's not floated to any side.
# [12:37] <fantasai> Howcome: you might want it to go to the bottom of the next page if it doesn't fit
# [12:37] <fantasai> Steve: There's two cases
# [12:37] <fantasai> Steve: It either fits on the page with the callout or it doesn't
# [12:37] <fantasai> Steve: If it fits on the page, there are subcases. It would fit at the top, the bottom, or somewhere near the callout
# [12:38] <fantasai> Steve: If it doesn't fit on the page, you may want to specify where it should go when it doesn't fit
# [12:38] <fantasai> Steve: You want to specify where to put it if it does fit, and where to put it if it doesn't fit.
# [12:39] * Quits: dsinger (dsinger@217.167.116.128) (Quit: dsinger)
# [12:40] <fantasai> Peter: Can this be done with page-break controls, or widow orphans, or something else
# [12:40] <fantasai> Howcome: This case ('here') is non-floating
# [12:40] <fantasai> fits or not?
# [12:40] <fantasai> yes -- top | here bottom
# [12:40] <fantasai> s/here bottom/here | bottom/
# [12:41] <fantasai> no --
# [12:41] <fantasai> ...
# [12:41] <fantasai> Alex: We want to allow multiple figures with columns... we have to communicate intent that this should be regular float that should be anchored
# [12:41] <Bert> (Or a fallback list, comma-separated, max. two items: 'float: here, top')
# [12:42] * Joins: dsinger (dsinger@217.167.116.128)
# [12:42] <fantasai> Howcome: There are some cases where you're not floating, but if there isn't room you want to float
# [12:43] * Quits: dsinger (dsinger@217.167.116.128) (Quit: dsinger)
# [12:44] <fantasai> Peter: Maybe you want to break out the notion of whether it fits.
# [12:44] <fantasai> Peter: Maybe you want to absolutely position the thing if it doesn't fits
# [12:45] <fantasai> Steve: So here's an example. If it fits on this page I want it at the bottom. If it doesn't fit on this page I want it at the top of the next page
# [12:45] <fantasai> Steve: other cases are it's not floated at all if it fits, but floated to next page if it doesn't
# [12:45] <fantasai> Steve: You don't want a break in the text. You just want it to flow.
# [12:47] <fantasai> Bert: I heard from Steve the use cases.
# [12:48] <fantasai> Bert: You place it this way if it fits, that way if it doesn't
# [12:48] <fantasai> Bert: Why not have a comma.
# [12:48] <fantasai> Bert: to separate the alternatives.
# [12:48] <fantasai> Bert: Then you don't have this unless keywords which ar so confusing.
# [12:49] <fantasai> Howcome: Suppose I have to floats that say 'top'. Are these floats both at the top, or does one go to the next page.
# [12:49] <fantasai> Howcome: so it can be at the top?
# [12:49] <fantasai> Steve: They're both floated to the top, show up in source order.
# [12:49] <fantasai> David: Pushing to the next page sounds like the clear property
# [12:49] <dbaron> Steve: Having 50% wide float then 100% wide float on top looks ugly
# [12:50] <dbaron> Håkon: With a very intelligent process you could fix that.
# [12:50] <dbaron> Alex: Grid positioning, with places in grid for bigger and smaller images.
# [12:50] <dbaron> Steve: Need a template.
# [12:50] <dbaron> Alex: With templates ... handle wanting at most one picture per page.
# [12:51] <dbaron> Håkon: float:top, clear: ?
# [12:51] <dbaron> David: clear:top ?
# [12:51] <fantasai> Alex: in this case you want just the float to clear, not the content that comes after
# [12:52] <dbaron> Steve: If you think it's complicated now...
# [12:52] <dbaron> Håkon: Maybe an argument for having separate vertical and horizontal floating properties?
# [12:52] <dbaron> Elika: Better in the same property for cascading, etc.
# [12:52] <dbaron> Elika: But maybe "unless-room", etc., could be a separate property.
# [12:53] <dbaron> David: What if float:left and v-float: top?
# [12:53] <dbaron> Steve, Alex: That's ok.
# [12:54] <fantasai> Bert writes:
# [12:54] <dbaron> Bert: float: left | right | here | top | bottom
# [12:54] <fantasai> Bert: float property can accept two comma-separated values
# [12:55] <dbaron> Bert: float: [left | right | none | top | bottom], [left | right | hidden | top | bottom]
# [12:56] <dbaron> (People discuss whether none is in the second list.)
# [12:56] <dbaron> float: none, * is the same as float: none
# [12:57] <dbaron> Steve: 'float: top, none' means top if it fits on the page, in-flow if it doesn't (and at the top of the next page)
# [12:57] * Quits: alexmog (alexmog@131.107.0.102) (Ping timeout)
# [12:57] <dbaron> Alex: I'd like to hear from a designer that they want this conditional fallback.
# [12:57] * Joins: myakura (myakura@118.8.102.216)
# [12:58] <fantasai> Elika: Should you need the 'page' keyword for these examples?
# [12:58] <fantasai> Howcome: that's another question, should 'top'/'bottom' imply 'page'?
# [12:58] * Joins: alexmog (alexmog@131.107.0.102)
# [12:58] <fantasai> Howcome: There's a use case for floating to the top of the containing block.
# [12:59] <fantasai> Elika: Designers really want that.
# [13:01] <dbaron> Alex: For float anywhere on the page, we need keywords for top, left, right, bottom, plus keywords for abs pos CB and for page.
# [13:01] <dbaron> Peter: I can see floating to an arbitrary grid line.
# [13:02] <fantasai> Elika: Can we assume that these floats never escape the block formatting context we're in?
# [13:04] <fantasai> Discussion of grid positioning
# [13:05] <fantasai> Alex: I'm used to the Word model where you position an element on the page and then set the text wrap
# [13:08] <dbaron> Alex: In terms of positioning (ignoring wrapping around them),there are some things that can be done with floats that can't be done with abs pos, and vice versa.
# [13:10] <Bert> (You can wrap text around abs. pos. element only if the coordinate system for positioning doesn't depend on the position/size of the element itself.)
# [13:13] <dbaron> (discussion of floating versus positioning)
# [13:16] <fantasai> Alex: just for reference, word allows positioning anywhere but not relative to auto-sized elements
# [13:17] <fantasai> Alex: so we'd get some very interesting issues if we have an auto-balanced multicol element with boxes floated to the bottom
# [13:19] <dbaron> Richard: Arabic books or Chinese books, where the page on the right face comes before the page on the left face...
# [13:20] <dbaron> Håkon: top is top, left is left, etc.
# [13:20] <dbaron> Richard: So in a vertical document, if I want a page float at the start of the text...
# [13:21] <dbaron> Alex: We consider 'top' and 'left' as synonyms given CSS2 floats that only go at the sides of the lines.
# [13:21] <dbaron> Peter, Alex: Do we want inside, outside, start, end?
# [13:22] <dbaron> ...before, after.
# [13:23] <dbaron> Håkon: I don't accept the requirement that the same style sheet should be used for Arabic and English.
# [13:23] <dbaron> Richard: I've spoken to people who translate to Arabic and find this very difficult.
# [13:25] <dbaron> (discussion of before, after, start, end, etc.)
# [13:25] <dbaron> Håkon: 'before page' is confusing
# [13:28] <dbaron> Elika: If you're designing a site that you know is going to be translated, you want to design the style sheet once.
# [13:30] <fantasai> Bert and Howcome don't think in a way that this makes sense
# [13:31] <fantasai> Alex: Approximately 50% of the people in this room see a legit use case for this
# [13:31] <fantasai> Peter: We have people in this room who specialize in internationalization and writing in different scripts, I think we should listen to them.
# [13:31] <fantasai> Richard: So Bert, you need to find people who back up your propositionin the Arabic and Hebrew-speaking world.
# [13:31] <fantasai> Richard: Let me be clear that sometimes you set left and you always want it to be left.
# [13:32] <fantasai> Richard: But oftentimes you want it to be the start of the line.
# [13:34] <fantasai> Steve: A long time ago we decided not to relativize left/right/top/bottom. It's confusing if left did not mean left anymore.
# [13:34] <fantasai> Richard: Maybe I don't mix up start and before because I've had to use those languages and I've had to learn what they mean.
# [13:34] <anne> (I was suggesting something like :root > main { float:left } :root:dir(rtl) > main { float:right }
# [13:34] <anne> )
# [13:34] <fantasai> David: I'd note that our localizers are the ones who care about this. And when I start up the Hebrew version of Firefox, I get this.
# [13:35] <fantasai> David: The localizers will go through the theme style sheets to make sure that the style sheets use the correct relative keywords
# [13:36] <fantasai> David shows a copy of Firefox whose UI looks mirrored from the English layout
# [13:37] <fantasai> Bert: Is see that you really have to think about it when you write the style sheet. It's not automatic whether it's left/right or start/end
# [13:38] <fantasai> some argument about how much thinking happens when deciding which keyword to pick
# [13:38] <fantasai> David explains to howcome that Mozilla has implemented start/end *-start/*-end internally
# [13:39] <fantasai>
# [13:40] * Joins: MoZ (chatzilla@82.230.92.154)
# [13:53] * Joins: dsinger (dsinger@217.167.116.128)
# [13:53] * Quits: myakura (myakura@118.8.102.216) (Quit: Leaving...)
# [14:20] * Quits: SaloniR (d5c78094@128.30.52.43) (Quit: CGI:IRC (EOF))
# [14:36] <anne> type is not a valid attribute for br people
# [14:36] <Bert>
# [14:36] <anne> that's invalid too in HTML
# [14:36] <anne> (in fact, it would get parsed as , which would mean another break, which works for me...)
# [14:39] <fantasai> Topic: Vertical text in IE
# [14:39] * Joins: SaloniR (d5c78094@128.30.52.43)
# [14:39] <fantasai> Alex: We waited for Beta2 to come out before we started talking about implementing vertical writing for Mongolian etc..
# [14:40] <fantasai> Alex: We have support for all eight text directions
# [14:40] <fantasai> Alex: We want that to be compatible with Text Layout spec
# [14:40] <fantasai> Alex: What we propose to do to Text Layout spec is two things
# [14:40] <fantasai> Alex; one we want to separate that
# [14:41] <fantasai> Alex: Currently there is vertical writing mode part
# [14:41] <fantasai> Alex: And there is a separate part about document character grid
# [14:42] <fantasai> Alex: We think that the text layout part of it is very well defined and appears to be complete
# [14:42] <fantasai> Alex: We propose to make that a separate spec and quickly bring it to completeness
# [14:42] <fantasai> Alex: For line grid and document grid, we are not sure how to define completeness
# [14:42] <fantasai> Alex: Because we don't have a requirements document.
# [14:42] <fantasai> Alex: We can't say whether this is complete or not complete. That should be a separate spec
# [14:43] <fantasai> Alex: We have a partial implementation of that as well, but we don't think that can move to REC as fast.
# [14:43] <fantasai> Alex: So we propose to separate that out and move it to low priority
# [14:43] <fantasai> Alex: but move vertical text to CR asap
# [14:43] <fantasai> Alex: The last thing that we want to do there is to add bottom-to-top writing mode
# [14:43] <fantasai> Alex: so that we have all eight directions.
# [14:44] <fantasai> Alex: I think we want to add it just because it is very well-defined what it does.
# [14:44] <fantasai> Alex: Use cases are marginal, but we don't see why we should undefine that when it is totally clear what it means.
# [14:44] <fantasai> Alex: I'm fine with making that optional
# [14:44] <fantasai> Alex: That's alll.
# [14:45] <fantasai> Alex: Once you've got Mongolian, you've got the hard part done.
# [14:45] <fantasai> Alex: Because in Mongolian your line bottom and paragraph bottom don't match.
# [14:47] <fantasai> Elika: So that sounds pretty good.
# [14:50] * Joins: jason_cranfordtea (jason_cran@64.236.128.12)
# [14:50] <fantasai> Elika: I say to take the vertical writing mode controls and combine them with the definitions from the Box Module
# [14:50] <fantasai> Elika: And make that a spec
# [14:51] <fantasai> Elika: Because the writing mode definitions are not enough to say how the new orientation maps to the calculations in CSS2.1 Chapter 10
# [14:54] <fantasai> Elika: And how nested differing writing modes interact
# [14:55] <dbaron> ScribeNick: dbaron
# [14:55] <Bert> Bert: But good thing about making text layout a CR is that it stabilizes the proeprty names.
# [14:55] <dbaron> Steve: So there's no objection to splitting out a piece of the text layout stuff?
# [14:56] <fantasai> ACTION: fantasai set up redirects
# [14:56] * trackbot noticed an ACTION. Trying to create it.
# [14:56] * RRSAgent records action 4
# [14:56] <trackbot> Created ACTION-94 - Set up redirects [on Elika Etemad - due 2008-08-28].
# [14:57] <dbaron> (side discussion about publishing documents in dev space vs. group space)
# [14:58] <dbaron> Elika: You didn't implement glyph-orientation or ? properties?
# [14:58] <dbaron> Alex: right
# [14:58] <dbaron> Alex: they're not in the spec anymore
# [14:58] <dbaron> Elika: I'd like to define terminology so that other specs can refer to terminology rather than referring to values of specific properties.
# [14:58] <dbaron> Bert: depends on context
# [14:59] <r12a> Richard: frustrated because can't ever be sure he's reviewing the right document because he can't always find the latest documents
# [14:59] <dbaron> Elika: I think we do have agreement on the part MS has implemented.
# [15:00] <dbaron> Elika: So I think direction, writing-mode, and block-progression should go in the trimmed box-model.
# [15:01] <fantasai> ACTION: Bert work out what is missing from Box Module and ask dbaron for it
# [15:01] * trackbot noticed an ACTION. Trying to create it.
# [15:01] * RRSAgent records action 5
# [15:01] <trackbot> Created ACTION-95 - Work out what is missing from Box Module and ask dbaron for it [on Bert Bos - due 2008-08-28].
# [15:02] <dbaron> Elika: spec should describe how vertical text works
# [15:03] <dbaron> Alex: I worry about describing completely. Vertical text alone isn't hard; orthogonal flows are hard.
# [15:04] <dbaron> Elika: Whether block-progression should have a prefix in IE depends only on syntax, since its behavior is already derived from writing-mode, and writing-mode is implemented un-prefixed for years.
# [15:05] <dbaron> Peter: If we merge things into other modules, I want to avoid blocking those modules for lack of implementation.
# [15:06] <dbaron> Saloni: Not really happy about moving from one draft to another -- want to progress it.
# [15:06] <dbaron> Elika: We can't progress without definitions.
# [15:07] <dbaron> Elika: Best is to review Bert's draft. Make sure it's consistent with what you're implementing and with CSS 2.1, then we can publish CR.
# [15:07] <dbaron> Saloni: We're willing to put in work to progress this part.
# [15:08] <fantasai> David: Can we avoid discussing how we split the modules until after those parts of the specs are CR-ready?
# [15:09] <fantasai> David: Because we keep switching what parts of the Box Module and Text Module should be together
# [15:09] <fantasai> Steve: So there are some parts of specs that are closely tied together
# [15:10] <fantasai> Steve: We could put the relevant bits of the Text Layout module in the Box Module
# [15:10] <fantasai> Steve: Or put the relevant bits of the Box Model into the Text Layout module
# [15:10] <fantasai> Steve: Or develop two modules, one Box Model Basic and one Text Layout Basic
# [15:11] <fantasai> Steve: I prefer the last option, as the easiest way to make progress.
# [15:11] <fantasai> Elika: That works for me. I just want to make sure we have the box module definitions and the syntax, not just one or the other
# [15:12] <fantasai> Elika: Because they are both needed for a complete dfinition of vertical text
# [15:12] <dbaron> Saloni: So what we're doing is pulling out 'writing-mode', ...
# [15:13] <dbaron> Saloni: ... into text layout basic module, and put in details and behavior there.
# [15:13] <dbaron> Elika: But also look at box module
# [15:13] <dbaron> Alex: ... and help Bert with parts of box model.
# [15:13] <dbaron> Alex: And then work on test cases corresponding to current state of both documents.
# [15:14] <dbaron> Elika: If ready for CR tomorrow, we could pull stuff out of box model and move to CR.
# [15:15] <fantasai> RESOLVED: Make writing mode part of Text Layout into an independent spec
# [15:15] <fantasai> ACTION: fantasai make that split and inform Bert
# [15:15] * trackbot noticed an ACTION. Trying to create it.
# [15:15] * RRSAgent records action 6
# [15:15] <trackbot> Created ACTION-96 - Make that split and inform Bert [on Elika Etemad - due 2008-08-28].
# [15:17] * Quits: shepazu (schepers@128.30.52.30) (Ping timeout)
# [15:18] * Joins: myakura (myakura@118.8.102.216)
# [15:18] <alexmog> link to text layout draft: http://dev.w3.org/csswg/css3-text-layout/
# [15:19] <alexmog> (it doesn't work for me now)
# [15:20] <myakura> hmm, dev.w3.org seems to be down
# [15:20] <anne> yeah, sucks
# [15:21] <myakura> no, now i'm getting the content
# [15:21] <fantasai> Steve: Someone should contact Murakami-san and point out what we're doing here and ask him whether they might have an implementation
# [15:21] <fantasai> Richard: We should also inform the JLTF
# [15:21] <fantasai> ACTION: Steve contact Murakami-san and JLTF about relevant developments here
# [15:21] * trackbot noticed an ACTION. Trying to create it.
# [15:21] * RRSAgent records action 7
# [15:21] <trackbot> Could not create new action - please contact sysreq with the details of what happened.
# [15:21] <plh> http://dev.w3.org/ was (still is) having troubles this morning. It has been reported but I'm fearing our system folks in the US didn't see that yet :(
# [15:22] <fantasai> Steve: Bert, are you willing to split the Box Model again?
# [15:22] <Bert> (Yes, dev.w3.org is extremely slow since a couple of hours, sys team knows, but doesn't seem to know why yet.)
# [15:22] <fantasai> Bert: Yes, but I'm having trouble making sure I don't lose anything everytime it splits and recombines :)
# [15:22] <fantasai> Alex: There's also a Ruby spec which could follow the same track.
# [15:23] <fantasai> Alex: I'm less concerned about that
# [15:23] <fantasai> Alex: As we only have partial implementation of Ruby spec
# [15:23] <fantasai> Elika: We don't have an editor for that right now
# [15:23] <fantasai> Anne: There are also some open issues
# [15:23] <anne> s/open issues/open ruby markup issues/
# [15:23] <fantasai> Alex: I wanted to mention that, but we don't have any current plans to advance that
# [15:24] <fantasai> John: We have two developers in Japan (for Mozilla) who want to implement it, but say the spec is dodgy
# [15:24] <fantasai> Anne: The markup subset that IE supports and is part of HTML5 is not really good at handling complex ruby
# [15:24] <fantasai> Richard: It doesn't handle complex ruby
# [15:24] <dbaron> ScribeNick: fantasai
# [15:25] <anne> ( http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level.html#the-ruby )
# [15:26] <fantasai> Steve: one last question, Paul, fantasai, and I proposed a text-orientation property that has a partial description
# [15:26] <fantasai> Steve: Clearly not implemented by MS, but..
# [15:27] <fantasai> Steve: We recognized that glyph-orientation is not what you want for a lot of cases
# [15:27] <fantasai> Steve: Since you want to operate on runs of text, not on glyphs
# [15:27] <fantasai> Steve: The simple thing is to take text and rotate it right.
# [15:27] <fantasai> Steve: which is what IE does
# [15:27] <fantasai> Steve: you want some way of controlling that, but glyph-orientation is not the right way to do that kind of thing
# [15:28] <fantasai> STeve: If you're going beyond the default behavior here then we want to consider text-orientation
# [15:29] <dsinger> sorry, you are rotating the glyphs and leaving the writing direction, or rotating the baselines (the bounding box and all)?
# [15:29] <fantasai> Elika: So we should keep text-orientation with the writing-mode definition
# [15:29] <fantasai> ELika: And just have the two values we really need, 'right' (the default, what IE has implemented) and 'upright'
# [15:29] <fantasai> Elika: We should be able to take that to CR.
# [15:29] <fantasai> Elika: Leave the complicated values like invert etc. for later
# [15:30] <fantasai> Elika: er.. actually the default was 'auto' which iwas do what glyph-orientation says if you implement that, otherwise do 'right'...
# [15:30] <fantasai> Topic: Vertical Layout Terminology
# [15:30] <dbaron> ScribeNick: dbaron
# [15:31] <dbaron> Elika: I think we need agreed-upon term for defining writing modes, directions, etc., for when we're writing our specs.
# [15:31] <dbaron> Elika: Avoid having to write out property-value pairs everywhere in definitions, and makes it easier to expand functionality in the future without doing as much editing.
# [15:32] <dbaron> Elika: I want to go over some concepts and pick the names for them. I volunteer to write a note that will define them so we can refer to them easily.
# [15:32] <dbaron> Elika: Also, we need to define start, end, before, after, etc., and lock down on names for writing-mode-related properties.
# [15:32] <fantasai> http://lists.w3.org/Archives/Public/www-style/2008Feb/0294.html
# [15:33] <dbaron> Elika: Paul, Steve, and I discussed in February and came up with names.
# [15:37] <dbaron> (discussion of logical width / logical height)
# [15:37] <dbaron> Bert: for the box model, I don't need those
# [15:37] <dbaron> David: you could use * length, e.g., "block length" and "inline length"
# [15:37] <dbaron> Bert: I need a term for the margins that collapse (top and bottom in horizontal)
# [15:38] <dbaron> Elika: Depending on how you're writing the specs, you might want or not want some of these.
# [15:39] <dbaron> Bert: I also want terms for rightwards, etc.
# [15:40] <dbaron> Alex, Saloni: We used logical width, logical height, logical left, etc.
# [15:40] <fantasai> RESOLVED: Dimensions use logical width & logical height, (physical) width & (physical) height
# [15:41] <dbaron> David: Does "inline direction" mean "rightwards" or "horizontally"?
# [15:41] <dbaron> Elika: rightwards
# [15:41] <fantasai> STeve: It's the direction in which you add characters on the line
# [15:42] <dbaron> David: dimension, direction, axis
# [15:43] <fantasai> Bert: I want a concept to refer to the left/right vs. top/bottom
# [15:43] <fantasai> Steve: direction is always an arrow
# [15:43] <fantasai> Steve: dimension is always a measure
# [15:44] <dbaron> Elika: (presents "Layout Modes" section of above)
# [15:45] <dbaron> Bert: sometimes I couldn't use "in vertical mode" because it mattered whether block direction was leftwards or rightwards.
# [15:45] <fantasai> "in top-to-bottom writing mode", "in left-to-right writing mode", "in right-to-left writing mode"
# [15:45] <fantasai> Richard: "in bottom-to-top writing mode"
# [15:46] <dsinger> block progression and inline progression are the two usual terms, no?
# [15:47] <dsinger> (going offline imminently)...
# [15:47] * Quits: dsinger (dsinger@217.167.116.128) (Quit: dsinger)
# [15:50] <dbaron> I don't like using the term "writing mode" such that "top-to-bottom writing mode" and "horizontal writing mode" mean the same thing.
# [15:53] * Joins: molly (mollyholzs@70.171.237.207)
# [16:00] <dbaron> (lots of discussion)
# [16:00] <dbaron> Saloni: Saying things like lr-* or *-tb worked well for us.
# [16:02] <dbaron> Elika: "rl block direction"?
# [16:02] <dbaron> Elika: We could adopt convention of "RL block direction" being uppercase
# [16:02] * plh thinks the Group is getting tired :)
# [16:03] * Joins: George (opera@213.236.208.22)
# [16:04] * Parts: George (opera@213.236.208.22)
# [16:05] <dbaron> (discussion of "progression" vs. "direction" vs. "progression direction")
# [16:06] <dbaron> Elika: (presents "Sides" section of document above)
# [16:06] <dbaron> Elika: people sometimes find before and after confusing
# [16:09] <dbaron> David: where "before" is ambiguous you can say "before-edge"
# [16:09] <dbaron> Elika: we also want these in "float: start", "margin-start", etc.
# [16:10] <dbaron> Elika: We're probably stuck with these for some cases.
# [16:11] <dbaron> Steve: Can I propose we use before and after unless someone comes with something better.
# [16:11] <dbaron> Håkon: OK in specs, but I don't want to allow these in values or properties.
# [16:11] <dbaron> Håkon: It's a disaster for float.
# [16:12] <dbaron>
# [16:13] <glazou>
# [16:19] * Joins: George (giorgic@84.215.42.108)
# [16:19] * Parts: George (giorgic@84.215.42.108)
# [16:31] <fantasai> Topic: Roadmap for Completion of CSS2.1
# [16:32] <fantasai> Notes from break: proposals for replacing before/after include fore/aft and head/tail
# [16:32] <fantasai> arronei joins via phone+irc
# [16:32] <fantasai> ScribeNick: fantasai
# [16:32] <fantasai> Peter: We need a plan for finishing CSS2.1
# [16:32] * anne was quite serious about the agenda...
# [16:32] <fantasai> Peter: main focus is getting test suite complete
# [16:32] * anne :/
# [16:32] <fantasai> Peter: where are we?
# [16:33] <fantasai> Arron: From our side we just released another 3000 tests roughly
# [16:33] <fantasai> Arron: I'm going to start submitting those in the next couple of weeks
# [16:33] <fantasai> Arron: You guys discussed the review process yesterday, Elika and I will work on getting the submission process working
# [16:33] <fantasai> Peter: I saw yesterday a nice map of how the test suite should be broken down
# [16:34] <fantasai> Peter: Do we have a map of what's being submitted and what's being worked on?
# [16:34] <fantasai> Arron: I can explain what we're doing
# [16:34] <fantasai> Arron: and where we're heading.
# [16:34] <fantasai> Arron: Might take me a week to pull that all together
# [16:34] <fantasai> Peter: Mozilla was going to submitting tests?
# [16:34] <fantasai> David: I have some tests. I have to figure out what to do with them
# [16:34] <fantasai> David: I have a few tests for some Chapter 10 stuff
# [16:35] <fantasai> David: I had some counters tests that I submitted long ago and are in the test suite now
# [16:35] <fantasai> David: I might be able to dig up some others
# [16:35] <fantasai> peter: My main concern, my goal is to get some timeframe on this
# [16:35] <fantasai> Peter: progress with some concrete milestones
# [16:35] <fantasai> Peter: What information do we have, what can we expect
# [16:36] <fantasai> Philippe: What's the goal of the test suite?
# [16:36] <fantasai> David: There are two
# [16:36] <fantasai> Peter: One is to measure conformance once we have a REC
# [16:36] <fantasai> Peter: First is demonstrate sufficient implementations to get to REC
# [16:36] <fantasai> David: Other one is to actually improve interoperability of CSS
# [16:38] <fantasai> Elika: When the test suite is complete enough for us to move to REC, we will take a snapshot and get implementation reports
# [16:38] <fantasai> Elika: We will continue to accept tests to increase coverage and drive interoperability
# [16:38] <fantasai> Peter: What's the measure for complete enough?
# [16:38] <fantasai> Philippe: Depends on the group, it's purely subjective
# [16:39] <fantasai> Steve: One piece is not subjective
# [16:39] <fantasai> Steve: Intended that all features be tested
# [16:39] <fantasai> Steve: Now what is a feature is subjective
# [16:39] <fantasai> Steve: but at least if the director asks "what is a feature", you need an answer
# [16:39] <fantasai> Daniel: You need at least one test per property-value combination
# [16:40] * melinda thinks you need one test per 'testable assertion'.
# [16:41] <fantasai> Elika: I think that once Microsoft has submitted all their tests, since they are writing a test for every property-value combination and every "rule" in the test
# [16:41] <fantasai> Elika: We will have a good baseline level of coverage of the spec
# [16:41] <fantasai> Elika: Add to that the more complex tests from Mozilla and Hixie
# [16:42] <fantasai> Elika: I think we will have a pretty good level of coverage for progressing to REC
# [16:42] <fantasai> Elika: At that point we should take a look, see if we have any obvious holes, plug them, and then take a snapshot and use that.
# [16:42] <fantasai> ...
# [16:43] * Bert (re Melinda): but if the statement is "for all elements satisfying X, do Y," that's one statement, but many tests.
# [16:43] <melinda> Exactly.
# [16:43] <fantasai> Peter: Were discussing making a task force for reviewing the tests
# [16:43] <fantasai> Arron: It sounds risky for the task force to do the review.
# [16:44] <fantasai> Arron: It would be better to have more of the task force to do a cursory review to see that it isn't blatantly wrong
# [16:44] <fantasai> Arron: And have a few people do the final review
# [16:44] <fantasai> peter: I'm not sure if that's a good idea to have a few peoplee review, because that becomes a bottleneck
# [16:45] <fantasai> Arron: We have currently four people who can do reviews
# [16:45] <fantasai> Elika: One problem is that we don't ahve a list of which tests need review
# [16:45] <fantasai> Elika: I can't say, come help review
# [16:45] <melinda> The problem is they're all real busy folks
# [16:45] <Bert> Elika: Too few people reveiwing.
# [16:46] <Bert> Elika: But not everybody can do the review.
# [16:46] <Bert> .
# [16:46] <fantasai> Elika: There are too few people qualified to do reviews right now
# [16:46] <Bert> Peter: Use the test harness and see what tests get inconsistent results.
# [16:47] <Bert> Peter: Those tests need review.
# [16:47] <Bert> Peter: Maybe flag tests in suite that are not stable
# [16:47] <melinda> It's more that you need to ensure the test is really testing what it purports to be testing.
# [16:47] <Bert> Plh: Different kinds of test suites, full suite for interoperability.
# [16:48] <Bert> Plh: Danger is if a test is in the test suite and is incorrent, people think tge test *defines* the behavior.
# [16:49] <Bert> Elika: People can always submit tests that show incompatibilities.
# [16:49] <Bert> Plh: Test that test multiple properties at same time?
# [16:49] <Bert> Daniel: Many cases where properties are correlated. Need to be tested.
# [16:50] <Bert> Plh: Can I submit Acid3 as a test.
# [16:50] <Bert> Several: Too many parts that don't apply to CSS.
# [16:50] <Bert> David: If you remove those parts, you're left with nothing.
# [16:50] <Bert> David: But som eparts of it can be truned into a good test.
# [16:50] <anne> (and from Opera!)
# [16:51] <Bert> Howcome: But still good to have it included.
# [16:51] <Bert> Elika: We need more review and system that makes it easy to review.
# [16:51] <Bert> David: Who are the reviewers right now?
# [16:52] <Bert> Elika: Anne, Hixie, Elika and David. Latter two most active and David less than Elika.
# [16:52] <Bert> Elika: Can get other person from MS to review. I don't know those people enough.
# [16:53] <Bert> Elika: Need to see Arron's work first, then I can say what he can review.
# [16:53] <Bert> Elika: I don't care about who is from what company.
# [16:54] <Bert> Elika: I'm not reviwing all 300 or so tests, but review a sample, and then trust him on the rest.
# [16:54] <Bert> s/300/3000/
# [16:54] <Bert> Elika: Already three people seeing all tests anyway.
# [16:54] <fantasai> at Microsoft
# [16:54] <Bert> Peter: When can we expect rest of tests from MS?
# [16:55] <Bert> Alex: Will keep workng on them,. Cannot say exactly.
# [16:55] <Bert> Alex: We are still developing new tests.
# [16:55] <Bert> Plh: A deadline until when to accept tests?
# [16:55] <Bert> Peter: A target date, but we may not have enough by then. End of year?
# [16:56] <Bert> Elika: End of year is good target.
# [16:56] <melinda> When MS submits their tests, what % coverage do we expect we'll have?
# [16:56] <fantasai> for a review of where we're at
# [16:56] <Bert> Arron: Agreed. Check again at 1st meeting in January.
# [16:56] * Joins: shepazu (schepers@128.30.52.30)
# [16:57] <Bert> Plh: is it reasonable time for Moz as well?
# [16:57] <Bert> David: Sure...
# [16:57] <Bert> Peter: Once we have a resaonably complete set, ready for review, can we set a regular review target, maybe 25% every quarter?
# [16:58] <Bert> Elika: Possible.
# [16:58] <Bert> Plh: Is the format frozen.
# [16:58] <Bert> Elika: yes:
# [16:58] <Bert> s/:/.
# [16:58] <Bert> Alex: Anybody can review. Give a 100 to each of us in this room.
# [16:58] <melinda> Why wait until we have a complete set to set review targets?
# [16:58] <Bert> Elika: We've been working on a process, with initial and final review.
# [16:59] <Bert> Elika: Final review looks at comments from initial review.
# [16:59] <Bert> Alex: use public mailing list for initial review?
# [16:59] <Bert> Elika: We do it, but not ideal.
# [16:59] <Bert> Elika: People not yet on the list don't have the history.
# [16:59] * Quits: SteveZ (d5c7928a@128.30.52.43) (Quit: CGI:IRC (Ping timeout))
# [17:00] <Bert> Peter: Do we have plan for building a system?
# [17:00] <Bert> Peter: Document management-like system. HP donated server to host repository.
# [17:00] <Bert> Peter: We are starting to implement. Would like help.
# [17:01] <Bert> Plh: Let people test with experimental suite and look at problems.
# [17:01] <Bert> Elika: That doesn;t tell you if the test tests what it says it tests.
# [17:02] <Bert> Elika: If a test fails, we need to look at it. If a test fails sometimes, we need to check that too. But that is only part of the work.
# [17:02] <Bert> Plh: We should tell people to look at the source if a test fails.
# [17:02] <Bert> Plh: Nothing will be perfect. Things fall thrugh the cracks always.
# [17:03] <Bert> Plh: I guess many CS authors will be happy to help.
# [17:03] <Bert> Elika: I want to get more involvement, volunteers and companies.
# [17:03] <Bert> Elika: A transparent system, easy to submit and report.
# [17:03] <Bert> Elika: Even if somebody cannot do final review, sending comments is still helpul.
# [17:04] <Bert> Plh: Can also organize an event where people comm together with their laptops and run the tests together.
# [17:04] <Bert> Elika: Or somethinglike a bug day, where people write tests.
# [17:04] <Bert> peter: We can spend part of our ftf for that.
# [17:04] <fantasai> peter: if we're not getting enough traction
# [17:04] <Bert> Arron: How about publishing another CSS 2.1 draft?
# [17:05] <Bert> Peter: I think so.
# [17:05] <Bert> Elika: When we reach 0 on issues list,w e can publish a WD.
# [17:05] <Bert> Elika: Cannot be CR, because of substantial changes.
# [17:06] <Bert> Elika: We have an errata list, but many people who read the spec forhet to read the errata.
# [17:06] <Bert> Plh: Substantial changes need WD, yes, but substantial is a subjctive term.
# [17:07] <Bert> Plh: Can say in last call where you made changes and set expectations for comments.
# [17:07] <Bert> Steve: Still takes time.
# [17:08] <Bert> David: Want to avoid WD. People send lot of comments.
# [17:08] <Bert> Discussion about shortest last call period.
# [17:09] <Bert> Steve: Can say that we take comments on unchanged parts and will reconsider them for level 3.
# [17:10] <Bert> Steve: If we say it explicitly up front, we have more arguments to reject comments.
# [17:10] <Bert> Discussion about how many comments expected. Hundreds?
# [17:11] <Bert> bert: Like to avoid moving back to WD.
# [17:12] <Bert> Steve: If changes modify an implementation, it's difficult to do them in a next version.
# [17:13] <Bert> Peter: don't want a CSS 2.2.
# [17:13] <Bert> Anne: Lets' get test suite first, before we publish anything.
# [17:14] <Bert> Elika: Definitely need a new WD.
# [17:14] <Bert> Elika: Question is when.
# [17:15] <Bert> Plh: Then how do you help people who miss the errata?
# [17:15] <Bert> Anne: We can have public editor's draft.
# [17:15] <Bert> Bert/Daniel: Those have no status.
# [17:16] <Bert> Peter: that can help us postpone republishing.
# [17:16] <Bert> Daniel: We are not helping people to understand what status of W3C documents is.
# [17:17] <Bert> Daniel: People see a document from the WG, from the W3C, don't understand how to interpret it.
# [17:17] <Bert> David: The document with the errata integrated is usefule for me as implementer.
# [17:18] <Bert> Peter: Public ED draft helps prublic to see progress.
# [17:19] <Bert> Steve: Don't get much comments on public ED drafts.
# [17:19] <Bert> Anne: I've had many comments.
# [17:21] <Bert> Daniel: Also OK with publishing on /TR, but it uses up resources.
# [17:21] <glazou> s/Daniel/David
# [17:21] <Bert> Bert: Pb with going to WD is (1) image problem, we're moving *backwards*, and (2) have to go to CR again.
# [17:21] <Bert> Plh: Short last call has been done, is possible.
# [17:22] <melinda> What changes have we made that can't be classed as 'minor corrections'?
# [17:22] <Bert> Steve: If CR leads to quaestions about rejected comments, can point to why they are rejected.
# [17:23] <Bert> Plh: Let people know that maintannce is going on?
# [17:23] <Bert> Steve: The CSS2 Rec has a not pointing forward to CSS 2.1.
# [17:24] <Bert> Plh: Publish a CR and say in it that there will be a WD before PR?
# [17:24] <Bert> Steve: Not possible in process.
# [17:24] <Bert> Daniel: Editor's draft gives impression that we don't want to follow the process.
# [17:25] <Bert> David: The process doesn't allow us to work the way we work. Process needs to change. We make incremnetal changes.
# [17:25] <Bert> Steve: Incremental changes, yes, up to the release date.
# [17:26] <Bert> David: This group essentially tries to reach perfection before we ship.
# [17:26] <Bert> Daniel: I've said that many times.
# [17:26] <Bert> David: We've essentially said we are never going to ship.
# [17:26] <glazou> Daniel: David, you're one of the people wanting perfection...
# [17:27] <Bert> David: We've said everyhting will go into CS3, so we're not going to change CSS2 anymore.
# [17:27] <Bert> Steve: Cannot publish errata. They have to be incorportated (eventually).
# [17:27] <Bert> Plh: "Edited Recommendation"
# [17:27] <Bert> Daniel: That's what we need.
# [17:28] <Bert> David: If we already had a test suite and already were in Rec, we could use PER, but we're not there yest and have to o through heavier process.
# [17:28] <Bert> Elika: We have spec and implementations, not tests yet.
# [17:29] <fantasai> Straw Poll: Do nothing, publish Editor's Draft (with note about expectations), publish LC/CR
# [17:29] <molly> Wait
# [17:30] <molly> this conversation has been completely confusing.
# [17:30] * Bert is not surprised :-)
# [17:30] <glazou> eheh
# [17:30] <fantasai> Molly!
# [17:30] <glazou> molly, that's because you have an hawaiian coktail in hand ?
# [17:30] <molly> can someone please put into lay terms exactly what benefits/deteriments each of those choices offer?
# [17:30] <molly> no, I'm at home now :)
# [17:30] <glazou> bad excuse :)
# [17:31] <molly> um, it's only 8:30 a.m.?
# [17:31] <molly> anyway, seriously
# [17:31] <fantasai> So, this is wrt CSS2.1 for which we have a lot of errata
# [17:31] * anne wants an option for moving the editing process to dev.w3.org
# [17:31] * anne would vote for that
# [17:31] <Bert> LC/CR will be when test suite is complete.
# [17:31] <fantasai> but the errata aren't incorporated into a public copy of CSS2.1
# [17:31] * Joins: SteveZ (d5c7928a@128.30.52.43)
# [17:31] <fantasai> just the internal copy
# [17:31] <fantasai> LC/CR has a lot of overhead
# [17:31] <Bert> Public editor's draft is regular, starting now.
# [17:31] <fantasai> Editor's Draft is unofficial
# [17:31] <fantasai> Howcome: no opnion
# [17:32] <fantasai> Elika: Editor's draft
# [17:32] <fantasai> David: Editor's draft
# [17:32] <fantasai> Daniel: Do nothing
# [17:32] <fantasai> Saloni: Editor's draft
# [17:32] <fantasai> John: Editor's draft
# [17:32] <fantasai> Steve: Editor's draft
# [17:32] <fantasai> Peter: Editor's draft
# [17:32] <fantasai> Ale: Editor's draft
# [17:32] <fantasai> s/Ale/Alex/
# [17:32] <fantasai> Bert: Do nothing
# [17:33] * molly whatever moves CSS 2.1 forward
# [17:33] <fantasai> Anne: Editor's draft
# [17:33] <fantasai> Arron: Editor's draft
# [17:33] * fantasai gives Molly a hug :)
# [17:33] <glazou> molly, that's the problem... forward according to us, to users, to W3C Process
# [17:33] <fantasai> RESOLUTION: Publish Editor's draft periodically
# [17:33] <fantasai> Topic: CSS3 Fonts
# [17:34] <anne> (for the record, I want editing to happen in public, either by porting the script, or comitting to dev.w3.org automatically or something)
# [17:34] * myakura wondering why not publishing another css-beijing wd, incorporating that note
# [17:35] * fantasai what note
# [17:35] * fantasai a note wouldn't solve the problem of people forgetting to check the errata when they look things up in the spec
# [17:35] <myakura> the one about expectations
# [17:35] * fantasai ah
# [17:35] <jason_cranfordtea> 703.2655801
# [17:35] <jason_cranfordtea> sorry
# [17:35] <jason_cranfordtea> should have sent my land line
# [17:35] <fantasai> RESOLUTION: Add note to Editor's draft about expectations for future publications
# [17:36] <fantasai> i.e. expectation to publish LC/PR once test suite is done
# [17:36] <jdaggett> http://people.mozilla.org/~jdaggett/css3fontspresentation.pdf
# [17:36] * melinda thinks it would be worthwhile identifying just which changes we think exceed 'clarifications' and 'minor corrections'
# [17:37] * glazou is always surprised by some UK accents when "okay" is pronounced "aykay"
# [17:37] <fantasai> John: The CSS3 Fonts spec I'm editing is based on the CSS2.1 spec with some additions
# [17:37] <fantasai> John: It combines the two CSS3 Fonts and Web Fonts sepcs
# [17:37] <fantasai> John: It's still an editor's draft.
# [17:38] <fantasai> John: server is flaky today
# [17:38] <fantasai> John: Slides posted to IRC
# [17:38] <fantasai> John: Tried to add more informative typogrpahy info
# [17:38] <fantasai> John: A lot of i18n things that a lot of people wouldn't be familiar with
# [17:38] <fantasai> john: Planning to add a note about how some of this relates to TrueType data
# [17:38] <fantasai> John: My goal is to iron out the @font-face definition
# [17:38] <fantasai> John: and then add more features
# [17:39] <fantasai> John: The themes are, mechanics of @font-face
# [17:39] <fantasai> John: font-matching algo improvments, enabling richer typography, and text-rendering effects
# [17:39] <fantasai> John: Fonts Toay
# [17:39] <fantasai> John: Covering where tech is today vs 10 years ago
# [17:39] <fantasai> John: Fonts are much richer today
# [17:39] <fantasai> John: Underlying platform APIs are much more complex
# [17:39] <fantasai> John: You have things like Uniscribe, Pango, CoreText
# [17:40] <fantasai> John: Far wider variety of scripts to be handled
# [17:41] <fantasai> John: Shows some examples
# [17:41] <fantasai> of different scripts
# [17:41] <fantasai> e.g. diacritics, cyrillic, Arabic shaping
# [17:42] <fantasai> Linear B which is written with surrogate pairs
# [17:42] <fantasai> MathML which needs specialized fonts
# [17:42] <fantasai> John: Evolution of True Type
# [17:43] <fantasai> John: Started as Apple format, it's a container format
# [17:43] <fantasai> John: early TrueType was scalable glyphs with quadratic splines
# [17:43] <fantasai> John: ...
# [17:43] <fantasai> John: Around early 90s, Apple developed TrueType GX
# [17:43] <fantasai> John: The extended TrueType by adding more tables
# [17:44] <fantasai> John: Added support for richer typographic variations and allows handling of complex scripts
# [17:44] <fantasai> JohN: but not shared with MS
# [17:44] <fantasai> John: So Microsoft creates TrueType Open
# [17:44] <fantasai> John: Adds tables
# [17:44] <fantasai> John: created OpenType with Adobe
# [17:44] <fantasai> John: Created two glyph formats, quadratic (.ttf) and cubic (.otf)
# [17:44] <fantasai> John: Apple changes TrueType GX name to AAT
# [17:44] <fantasai> John: Problems with TrueType
# [17:45] <fantasai> John: dual platform nature -- there are platform-specific data in the fonts
# [17:45] <fantasai> John: e.g. family names are per-platform
# [17:45] <fantasai> John: And font classification is different
# [17:45] <fantasai> John: Usually font vendor tries to make them match, but errors arise
# [17:45] <fantasai> John: e.g. weight is pulled from OS/2 table on Microsoft, Apple based on style name
# [17:46] <fantasai> John: Complex script handling is completely different
# [17:46] <fantasai> John: Apple is slowly adopting OpenType, so this difference will go away in the future but right now that's how it works
# [17:47] <fantasai> Some confusion about what formats are being discussed atm
# [17:48] <fantasai> John summarizes data in the TureType Name Table
# [17:48] <fantasai> Fmily, subfamily, full version, license
# [17:49] <fantasai> John: for each name, there are two platform names, n localizations
# [17:49] <fantasai> John: differnet style names for each weight
# [17:49] <fantasai> Style Linking
# [17:49] <fantasai> John: different processes for unifying a set of faces into a single font family
# [17:50] <fantasai> John: Apple says to use the same family name across all style variations
# [17:50] <fantasai> John: Microsoft spec restricts family name to only regular, bold, italic, bold italic
# [17:50] <fantasai> John: Has a "preferred family name" to group a larger set
# [17:50] <fantasai> John: "Savvy" apps use Preferred Family, then Family
# [17:51] <fantasai> John shows example of names for Kozuka Gothic Pro
# [17:51] <fantasai> On Macintosh you see one family with 6 weights
# [17:51] <fantasai> on Windows you see 6 families, 1 weight each
# [17:51] <fantasai> "savvy" apps can use the preferred family name
# [17:51] <fantasai> Implications?
# [17:52] <fantasai> John: Browsers need to become "savvy" apps on Windows
# [17:52] <fantasai> John: How to map "old-style" family names?
# [17:52] <fantasai> John: Luckily very few in actual use on web
# [17:52] <fantasai> John: But because of this, lots of spec bugs hidden by lack of style-linked families
# [17:53] <fantasai> John: Discussion yesterday of bolder vs lighter is an example of that: problem because people don't usually see more than two weights
# [17:53] <fantasai> John links to some further reading material
# [17:53] <fantasai> John: Interesting point, Microsoft has come up with their own version of font-matching
# [17:53] <fantasai> John: They do a lot of synthetic faces, etc.
# [17:54] <fantasai> Philippe: W3C is trying to set up group to do EOT. How does that effect this?
# [17:54] <fantasai> Steve: Don't ask that now.
# [17:54] <fantasai> John: So this is the font-matching algorithm for CSS2.1
# [17:54] <fantasai> John: You match the family name to a set of font faces
# [17:54] <fantasai> John: Match font-style, fallback on failure
# [17:54] <fantasai> John: Match font-variant, fallback if not synthesized (archaic)
# [17:55] <fantasai> John: In the past, e.g. smallcaps was a separate font. These days it's incorporated, so you don't need this
# [17:55] <fantasai> John: ....
# [17:55] <fantasai> John: Because of the way font-style is matched, font-style trums font-family in the spec
# [17:55] <fantasai> John: Reality is most user agents either synthesize italic
# [17:55] <fantasai> John: or ignore it
# [17:56] <fantasai> John: if they don't find italic
# [17:56] <anne> (I don't understand why smallcaps being incorperated obsoletes the need for font-variant...)
# [17:58] <anne> (Idea: make a small-caps variant or something for Ahem, to test this easily)
# [17:58] <fantasai> discussion about small-caps
# [17:59] <Bert> (Would be called "Ahem Pro" then :-) )
# [18:00] <fantasai> Howcome: on the small-caps issue, shouldn't that still be part of the font-matching? Because if you specified small-caps you want small-caps
# [18:00] <fantasai> Several people: you synthesize it
# [18:00] <fantasai> John: Many scripts have no concept of italics
# [18:00] <fantasai> John: in CSS3, suggest no fallback on italic, and no matching of font-variant
# [18:01] <fantasai> Howcome: What do you suggest should happen if there's no italic
# [18:01] <fantasai> John: dont' fallback on italic
# [18:01] <fantasai> John: say italic and oblique are equvalent unless both faces exist
# [18:02] <fantasai> Howcome: but then you synthesize it. Then I'm ok with it.
# [18:02] <fantasai> Peter: you might want a soft fallback
# [18:02] <fantasai> Peter: e.g. if there's an italic in the list, then fall back to it
# [18:02] <fantasai> Peter: if you fall back to the system font, then go back to the front and use synthesis
# [18:03] <fantasai> Jason: So if you specify italic, you fallback to oblique?
# [18:03] <fantasai> Peter: No, I'm saying that if you have a list of three fonts and your first font doesn't have an italic, but the second one does
# [18:03] <fantasai> Peter: then you use the second one
# [18:03] <fantasai> Peter: but if none of them have italic, then you go back to the first one and synthesize it
# [18:03] <fantasai> Jason: The author usually expect that you'd use one font throughout the spec
# [18:04] <fantasai> Steve; that's not true because the choice of fonts is on a fper-character basis in CSS.
# [18:04] <fantasai> John: Currently all browsers just synthesize an italic
# [18:05] <fantasai> Peter: Rather than synthesize an italic font, wouldn't it be better to fall back to another font that's specified that has an italic?
# [18:05] <fantasai> Ishida: In Cyrillic the italic shapes are radically different from non-italic
# [18:05] <fantasai> John: That's not unique to Cyrillic. There are fonts where that's true in Latin
# [18:06] <fantasai> John: Another problem in the spec is that italic and oblique are treated as if they can exist in the same font-family
# [18:06] <fantasai> John: And they almost never do
# [18:06] <r12a> s/the italic shapes/some italic shapes/
# [18:06] <fantasai> Bert: the case where these are different are Knuth's fonts
# [18:06] <fantasai> Bert: he uses them to mean different things
# [18:06] <fantasai> John: It's a very rare case
# [18:07] <fantasai> John: I want to clean up the archaic stuff in this spec
# [18:08] <fantasai> fantasai: I think Peter's double-fallback proposal is good to consider
# [18:08] <anne> (Can Ahem Pro do italic and obligue fancyness? Maybe we need several different Ahem Pro's to test accurately...)
# [18:08] <fantasai> Jason: One thing that I suggest is, Iknow from experience that most serious typographers would rather rip their arm off than have the UA synthesize an italic or oblique font
# [18:08] <fantasai> Jason: So I think we should have a way for italic to fall back to normal
# [18:09] <fantasai> John: I think it would make more sense for those typographers to use web fonts
# [18:09] <fantasai> Jason: until then
# [18:09] <fantasai> Peter: or if that doesn't work for whatever reason
# [18:09] <fantasai> John: So I propose a simplified Web Fonts deinition
# [18:09] <Bert> (Web Fonts allow you to specify a specific font for italic, it doesn't actually have to be an italic font.)
# [18:09] <fantasai> John: Trimmed down version of CSS2 @font-face spec
# [18:10] <fantasai> font-family, src url, src local
# [18:10] <fantasai> font attribute descriptors (font-weight, font style etc)
# [18:10] <fantasai> unicode-range for combining fonts
# [18:10] <fantasai> not attribute-base dfont substitution
# [18:10] <fantasai> s/not/no/
# [18:10] <fantasai> Safari already implements this, Moz and Opera coming soon
# [18:11] * Quits: myakura (myakura@118.8.102.216) (Quit: Leaving...)
# [18:11] <fantasai> John: I took font-variant out because it's a rendering-time thing, not a font-selection thing
# [18:11] <fantasai> John: You don't need it for descriptors
# [18:12] <fantasai> Bert: So I can't say I want to use this font for small-caps, I want it to be the same as for roman
# [18:12] <fantasai> ....
# [18:12] <fantasai> John: All the fonts are going to store that in the same font file, not a different one
# [18:13] <fantasai> Bert: I don't care where it's stored
# [18:13] * glazou wonders if all your fonts are belong to us
# [18:13] <fantasai> Bert: you're making it impossible to use the Computer Modern fonts
# [18:14] <fantasai> Bert: I'm concerned about every case where my roman doesn't have smallcaps
# [18:15] <fantasai> Bert: And I want to tell the browser where to find the smallcaps font
# [18:15] <fantasai> Steve: So let's go back and understand where the web font descripters are there for
# [18:15] <fantasai> John: Motivations
# [18:15] <fantasai> John: We want richer set of available fonts
# [18:15] <fantasai> John: Much tigher control over how content is rendered
# [18:15] <fantasai> John: Better support for international sites (e.g. BBC)
# [18:15] <fantasai> John: Domains with specialized font requirements sucha s MathML
# [18:16] <fantasai> John: Also allows us to improve integration of SVG fonts in HTML content
# [18:16] <fantasai> John: Need for restricted font formats is a separate discussion
# [18:17] <fantasai> John shows css3-fonts spec
# [18:17] <fantasai> John: This is an example using Gentium
# [18:17] <fantasai> John: The UA is using Gentium to render the text, but if for some reason the font is unavailable the serif font will be used
# [18:17] <fantasai> John: If Gentium is on the system, this rule will not use any fonts that are in the system
# [18:18] <fantasai> John: The reason you want to do that is that if you don't, you run into the situation where some user has the font that you're using
# [18:18] <fantasai> John: and not the font you want them to use
# [18:18] <fantasai> John: It is possible to set this up a different way
# [18:19] <fantasai> John: src: local(Gentium), url(/fonts/Gentium.ttf); will look for Gentium on the local system first
# [18:19] <fantasai> John: I originally wrote the spec the opposite way.
# [18:20] <fantasai> Howcome: I agree it's not clear which is the best
# [18:20] <fantasai> Howcome: But I'm leaning towards what you had in there first.
# [18:21] <fantasai> John: Then how do you turn that off, so that it's always downloaded?
# [18:21] <fantasai> Steve: Add a keyword like 'download'
# [18:22] <fantasai> Peter, Steve: Note the default behavior will always be to use the local version
# [18:22] <fantasai> David: The other possibility ..
# [18:23] <fantasai> David: You say that if local() is not in the list, then you assume it's at the beginning of the list
# [18:23] <fantasai> David: but if it is in the list, then you use its position at that location
# [18:24] <fantasai> David: That way if the author wants to say the local version is the lowest priority, then he has to specify it as lower priority. Otherwise it's implied at the front of the list.
# [18:27] <fantasai> Some arguing
# [18:28] <fantasai> fantasai: I don't think we should be wasting bandwidth by default
# [18:28] <fantasai> Steve: I think the behavior on down-level clients should be the default
# [18:28] <fantasai> Steve: down-level clients will always use the local copy if it exists
# [18:28] <fantasai> John shows last example of combining local() to make a shortcut for family names
# [18:29] <fantasai> John shows example of pulling out a font that otherwise would be inaccessible using CSS
# [18:30] <fantasai> John shows some examples of unicode-range
# [18:30] <fantasai> John: back to Steve's question
# [18:30] <fantasai> John: What do descriptors do?
# [18:30] <fantasai> John: Do descriptors define underlying attributes? or are they hints of what's in the font?
# [18:31] <fantasai> John: Problem is, if descriptor says the font-weight is bold but font says it's not what happens?
# [18:31] <fantasai> John: I think this is really confusing
# [18:32] <fantasai> John: I think the font-descriptor should override whatever's in the font
# [18:33] <fantasai> Steve: The notion of descriptors came from the idea that you build a table of fonts
# [18:33] <fantasai> Steve: with their attributes
# [18:33] <fantasai> Steve: the role of the descriptors was to build this table without having to download the fonts
# [18:35] <fantasai> John shows an example of two statements that use the same font name
# [18:35] <fantasai> Howcome, Bert: the assumption is that you assume both statements have all eights
# [18:35] <fantasai> s/eights/weight/s
# [18:37] * fantasai is not following this discussion
# [18:39] <fantasai> Steve: So the question is, how does that table get built if I have multiple font declarations that have overlapping definitions
# [18:39] <fantasai> Steve: My understanding is that I build my table
# [18:40] <fantasai> Steve: For the first declaration, I populate all 18 slots in my table (all weights and styles) with Bongo
# [18:40] <fantasai> Steve: pointing to that src
# [18:40] <fantasai> Steve: The second declaration updates the italic entries to point to the second src
# [18:41] <fantasai> ...
# [18:42] <fantasai> Steve: Most fonts today don't have all weights in the same file
# [18:44] <fantasai> Steve and John to talk offline
# [18:45] <fantasai> John: Security Issues
# [18:45] <dbaron> As far as I can tell, CSS2 was ambiguous about whether the descriptors override the font data.
# [18:46] <fantasai> John: There's a definite potential for intentionally corrupted fonts to become an attack vendor.
# [18:46] <Bert> Question was what is most useful default for a descriptor: all, or normal?)
# [18:46] <fantasai> John: Errors can occur with metrics, at drawing, etc.
# [18:46] <fantasai> John: You can do some validation, but not that much
# [18:46] <fantasai> Howcome; This is just battle-testing the font renderers. It's something they have to go through.
# [18:47] <fantasai> John: Note that fonts associated with one page should not affect rendering of another page.
# [18:47] <fantasai> John: Also you don't want to use downloaded fonts in a system fallback.
# [18:49] <fantasai> Howcome: if both pages point to the same src for the font, what then?
# [18:49] <fantasai> David: follow the HTTP cache headers
# [18:50] <fantasai> John: Last thing, Thank You to WebKit!
# [18:50] <fantasai> John: Their code sends a previously-secret special parameter that's necessary to implement this
# [18:51] <fantasai> :)
# [18:51] <fantasai> John: Size Adjustments
# [18:51] <fantasai> John: We reworked the description of font-size adjust
# [18:51] <fantasai> John: Tried to improve the explanation, not give a long list of aspect values
# [18:51] <fantasai> David: I wrote an explanation of it as well on MDC, you might be interested in looking at it
# [18:51] <fantasai> John shows an image from the spec that explains font-size adjust
# [18:52] <fantasai> John: I hope this draft incorporated the CSS2 errata on font-size-adjust
# [18:52] <fantasai> s/John/David/
# [18:53] <fantasai> David: It was dropped from CSS2.1, but we did make some corrections to it previously
# [18:53] <fantasai> Ishida: I have some real problems with Arabic etc.
# [18:53] <fantasai> John: Ok, yes I will say that this is very Western-centric.
# [18:53] <fantasai> John: There are definitely problems with rendering Latin with CJK
# [18:54] <fantasai> Steve wants to say why he really wants this to work with Arabic
# [18:54] <fantasai> but will wait til later
# [18:54] <fantasai> John: Beyond X-height Adjustments
# [18:54] <fantasai> John: Font-linking on CJK Windows..
# [18:55] <fantasai> John: Certain fonts like Tahoma have magical properties
# [18:55] <fantasai> John: that link to ther CJK fonts
# [18:55] <fantasai> John: On a fallback to CJK, resizing occurs
# [18:55] <fantasai> John: it will make the CJK characters bigger
# [18:56] <fantasai> John shows a screenshot
# [18:57] <fantasai> John: This is something that has been done for readability on Windows.
# [18:57] <fantasai> John: We should think about it for CSS
# [18:58] <fantasai> John: and whether it fits in with CSS
# [18:58] <fantasai> John: and/or how to address its use-cases
# [18:59] <fantasai> Alex: Michel Suignard would know all about this
# [19:00] <fantasai> John: There are other situations where this type of size adjustment would be interesting
# [19:00] <fantasai> John: Last thing I wanted to discuss is how to improve typographic features
# [19:00] <fantasai> John: based on the idea of exposing OpenType features
# [19:00] <fantasai> John: extending font-variant to support opentype features
# [19:01] <fantasai> John: e.g. ligatures, figure forms, other features
# [19:01] <jdaggett> http://lists.w3.org/Archives/Public/www-style/2008Jan/0380.html
# [19:02] <fantasai> John: I think the key here is picking out the features that are appropriate for a large audience, not necessarily all OpenType features
# [19:03] <fantasai> John shows some examples of ligatures
# [19:04] <fantasai> John shows some examples of digits
# [19:04] <fantasai> monospace digits vs proportional digits
# [19:04] <fantasai> monospaced digits are different glyphs, often used for tables
# [19:05] <fantasai> John shows example of alternate glyphs in Japanese
# [19:06] <fantasai> John: Lastly to wrap up, some rendering properties
# [19:06] <fantasai> John: text-fill-color, text-stroke-color, text-stroke-width
# [19:06] <fantasai> John: Need to think about how this works with SVG
# [19:07] * fantasai notes that the minute-taker is tired and hungry :)
# [19:07] <anne> ( http://www.urbandictionary.com/define.php?term=m(__)m )
# [19:08] <fantasai> Ishida asks about language features in OpenType fonts
# [19:08] <fantasai> Ishida: Does lang trigger the appropriate language features in the OpenType fonts?
# [19:08] <fantasai> John: I haven't looked deeply into that
# [19:09] <fantasai> more discussion of languages and features and mixed scripts
# [19:09] * Quits: alexmog (alexmog@131.107.0.102) (Ping timeout)
# [19:10] * Joins: alexmog (alexmog@131.107.0.74)
# [19:10] * Quits: glazou (daniel@213.199.146.138) (Quit: glazou)
# [19:12] * Quits: SaloniR (d5c78094@128.30.52.43) (Quit: CGI:IRC (EOF))
# [19:13] * Quits: shepazu (schepers@128.30.52.30) (Quit: shepazu)
# [19:14] * Quits: alexmog (alexmog@131.107.0.74) (Ping timeout)
# [19:16] <fantasai> Meeting closed fwiw
# [19:16] <fantasai> Molly, you still there?
# [19:19] * Quits: plinss_ (plinss_uk@213.199.146.138) (Quit: plinss_)
# [19:20] * Quits: r12a (ishida@128.30.52.30) (Client exited)
# [19:21] * Quits: plh (plh@128.30.52.28) (Quit: Ex-Chat)
# [19:23] * Parts: anne (annevk@213.199.146.138)
# [19:24] * Quits: jdaggett (jdaggett@213.199.146.138) (Quit: jdaggett)
# [19:24] * Quits: dbaron (dbaron@213.199.146.138) (Ping timeout)
# [19:24] * Quits: SteveZ (d5c7928a@128.30.52.43) (Quit: CGI:IRC (Ping timeout))
# [19:32] * Quits: MoZ (chatzilla@82.230.92.154) (Quit: ChatZilla 0.9.83 [Firefox 3.0.1/2008070206])
# [20:19] * Quits: jason_cranfordtea (jason_cran@64.236.128.12) (Quit: jason_cranfordtea)
# [21:49] * RRSAgent excuses himself; his presence no longer seems to be needed
# [21:49] * Parts: RRSAgent (rrs-loggee@128.30.52.30)
# [23:28] * Quits: melinda (melinda.gr@67.142.45.126) (Connection reset by peer)
# Session Close: Fri Aug 22 00:00:00 2008

The end :)