02:00:11 melinda has joined #CSS 03:28:36 shepazu has joined #css 04:14:07 shepazu has joined #css 04:50:23 jdaggett has joined #css 06:19:50 dbaron has joined #css 06:54:43 alexmog has joined #css 07:15:22 shepazu has joined #css 07:16:08 arronei has joined #CSS 07:50:25 alexmog has joined #css 08:06:53 jdaggett has joined #css 08:11:07 anne has joined #css 08:12:09 glazou has joined #css 08:28:06 dbaron has joined #css 08:30:46 plinss_ has joined #css 08:31:42 RRSAgent, make logs public 08:31:49 ScribeNick: dbaron 08:31:59 Meeting: CSS Working Group Face-to-Face 08:32:04 Topic: GCPM 08:33:35 Håkon: This draft is a clearinghouse for print-related features that didn't fit elsewhere. 08:36:01 SaloniR has joined #css 08:36:38 plh has joined #css 08:36:45 Håkon: The draft has moved a bit recently. Posted a new editor's draft based on feedback. 08:36:48 rrsagent, where am I? 08:36:48 See http://www.w3.org/2008/08/21-css-irc#T08-36-48 08:37:15 Håkon: Stable parts: running headers/footers, leaders, footnotes, hyphenation, image resolution, cross-references, page marks, bookmarks. 08:37:24 Håkon: These have implementations and not many requests for changes. 08:37:44 s/bookmarks/bookmarks, CMYK colors/ 08:37:44 r12a has joined #css 08:38:23 Håkon: Developing parts: named page lists (page sequences), character substitution, page floats. 08:38:53 PLH: Intended only for print media? 08:39:14 Håkon: That's currently in the document that it's only intended for print media, but some could be reused outside of print. 08:39:30 Should be here: http://dev.w3.org/csswg/css3-gcpm (I'm still waiting for it to load) 08:39:33 SteveZ has joined #css 08:40:10 fantasai: can't reach it 08:40:22 blame w3c IT 08:40:32 or MS IT 08:40:34 eh 08:40:35 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? 08:41:22 fantasai: http://www.w3.org/Style/Group/css3-src/css3-gcpm/Overview.html 08:41:29 Bert: Not for the module to say what's for what media type; that's for the profile. 08:41:41 Håkon: I don't want this to be a threat to, e.g., progressive rendering. 08:42:00 indeed, dev.w3.org is not responsive 08:42:15 Peter: I want browsers to support this when they're printing. 08:42:21 Håkon: absolutely 08:43:18 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. 08:44:23 Elika: I think we probably want some pieces to move to other drafts. 08:45:12 (discussion about whether cmyk() is actually defined, etc.) 08:45:46 Steve: ICC probably has something that talks about CMYK, but I don't know what off the top of my head 08:46:00 Håkon: Another feature that can be reused is border-length. 08:46:58 Elika: We could reuse border-radius and have a border-corner-shape 08:47:08 Peter: Wouldn't that preclude rounded corders like that? 08:47:31 David: This seems separate from border-radius. 08:49:23 Elika: border-corner-shape: [ sides | corner ] || [ round | sharp ] 08:49:31 Alex: border-length is a little more intuitive 08:50:08 Håkon: What about covering only non-corners. 08:50:14 Steve: Concern about overloading radius. 08:50:29 Steve: Can't use radius for both amount to show and the curvature. 08:51:25 Håkon: Maybe syntax from border-radius, but on a new property? 08:51:37 Elika: But we'd want it to take percentages. 08:51:55 Elika: And you'd want to be able to invert it to take only the middle. 08:52:14 Bert: Do we really need all this, given border-image and SVG? 08:52:23 Håkon: This came out of a simple request for footnotes. 08:52:39 Håkon: But it seems to be reusable. I've seen all these limited borders since I started this. 08:53:44 ?: Can we put it in backgrounds and borders? 08:53:50 Elika: Yes... but we should mark it at risk. 08:53:55 Peter: Implementations? 08:53:57 Håkon: No 08:55:41 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). 08:55:58 Alex: What happens when length is less than radius? 08:56:01 Steve: It's a mask. 08:56:09 Steve: I'd suggest calling it 'border-mask'. 08:56:24 David: That sounds like something else. 08:56:31 Steve: 'border-clip' ? 09:00:19 (drawings) 09:00:30 Daniel: This goes far beyond gcpm. 09:00:45 ?: to borders and backgrounds 09:00:54 Steve: Math people want adjustable brackets. 09:01:02 Elika: You don't want that with borders - you want a font. 09:02:50 Peter: What's the 'auto' value? 09:03:17 Håkon: 'auto' within lists copies from a different corner 09:03:31 Peter: Initial value should be a complete border. 09:03:41 Peter: Is that 'auto'? 09:03:53 Håkon: OK, 'auto' should be the initial value and mean the complete border is used. 09:04:33 David: You could make v/h %ages refer to width/height. 09:04:40 Alex: Then you can't get %ages square. 09:05:10 Håkon: Text replacement: necessary for printing to fix up quote characters. 09:05:57 Daniel: This is transformation, not style. 09:07:02 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. 09:07:21 Håkon: We should have a new content type? 09:07:27 Daniel: No, but put it in another spec. 09:07:41 Daniel: I have no problem mixing it with text/css, but put it in another spec. 09:08:11 Steve: If there were an element there, I could do it with 'content' and it would be style. 09:08:37 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. 09:08:46 Steve: The point here is that it's un-marked-up elements. 09:10:05 Håkon: This example (s/Soviet Union/Russia/) was meant to scare the kids. 09:10:25 Daniel: This should be a script that the printer driver offers you. 09:10:32 Steve: There's no reason I don't want to see this on the screen. 09:11:26 Daniel: Once we do this, people will want much more transformation. 09:12:08 Alex: Open quotes and close quotes are harder. 09:12:50 Daniel: Having transformations with CSS syntax has problems with the cascade. 09:13:23 Daniel: You can transform the document in ways that cause further transformations 09:13:31 Daniel: And you can get into a loop that way 09:13:40 Daniel: You want transformations as a sequence 09:13:52 Daniel: That is why I did not combine STTS with CSS 09:14:07 Steve: THis problem came up in XML and it was never simple 09:14:25 Howcome: THis doesn't change the structure of the document. 09:14:31 Bert, Fantasai, Daniel: Not yet. 09:16:17 Håkon: The replacements are applied sequentially. 09:16:21 Howcome: the text replacements are sequential according to the list in the text-replace property 09:16:22 David: Is it inherited? 09:16:53 Daniel: body { text-replace: "Soviet Union" "Russia"; } p { text-replace: "Russia" "Soviet Union"; } What happens? 09:17:15 Fantasai: It doesn't matter in this case 09:18:50 Daniel: If you want to solve the problem of circular transformation 09:18:58 Daniel: You can do that with a selector. 09:19:08 Daniel: If you have "Soviet Union" over two different elements, what is the result? 09:19:29 Howcome: In Prince you cannot make matches across element boundaries. 09:19:49 Alex: In case something in GCPM doesn't make it into CSS3 whatever, do we have a plan of what happens to it? 09:20:24 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? 09:20:50 Yes 09:21:18 Howcome: We should do that, but there are a core set of functionality like footnotes that are paged media specific 09:21:26 Peter, Alex: I don't think footnotes are paged-media specific 09:21:54 Daniel: back to text-replace. First, it's really underspecified. 09:22:11 Daniel: Second, I can agree on the usefulness. I want it in a standalone document. It does not belong to style. 09:22:38 Howcome: It's not going to get it's own document type. 09:22:44 Daniel: Why not 09:23:12 Bert mentions XSLT 09:23:40 Discussion about how this doesn't go far enough to be useful for some of the major use cases unless you have regex.. 09:23:59 Steve: In the font capability we're thinking of extending the font feature to enable open-type features. 09:24:04 Steve: That would solve your quote problem. 09:24:05 (though I suppose you could match on ' "' and '."' or something 09:24:06 ) 09:24:20 Steve: There are features in the font that allow you to trigger mappings of character to glyphs 09:24:35 John: For example, a lot of fonts enable a slashed zero. They have an alternate glyph, and you can enable that feature. 09:24:53 Howcome: That might turn out to be a solution. I personally cannot edit OpenType 09:25:07 John: You'd specify it through font-variant 09:25:30 (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.) 09:26:06 Peter: I think the thing you match against the original text. 09:26:43 David: Then you have to merge the replacements. 09:27:04 David: What happens if your replacements overlap? E.g. you replace "Soviet Union" and you replace "Union". 09:27:59 Howcome: You define a sequence. There's no infinite loop here. 09:28:04 Ishida: What is your use case here? 09:28:20 Ishida: You've got a document someone has written, and you want to print it? 09:28:39 Howcome: Or I wrote it. I don't want to type the long unicode sequences. 09:29:04 Peter: That's a very weak argument. If you're talking about a document you didn't write, then you have a use case. 09:29:23 Daniel: These are not something you are associating with the document anyway. 09:29:44 Daniel: So it is a local thing. You don't need a MIME type 09:30:29 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. 09:31:14 fantasai: why can't it be a separate transformation sheet, like XSLT or STTS? 09:33:54 Daniel: body { text-replace: "Soviet" "Russia"; } p { text-replace: "Soviet" "CEI"; } 09:36:20 Håkon: The replacements on ancestors would happen before replacements on descendants. 09:36:55 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. 09:37:08 s/don't/can/ 09:37:29 Steve: Should record: with the selector approach, you have the overlap problem. 09:37:42 *:text("Soviet") { content: "CEI"; } 09:38:35 David: If you make this an inherited property, then you have more overriding happening and you don't have these problems. 09:38:47 David: Only one text-replace value ever applies to a given run of text. 09:39:29 Håkon: I think we should take what we have two implementations of and make a spec of it. 09:39:35 Steve: I think this feature should be a separate document. 09:39:40 Peter: I think it depends on how this feature is defined. 09:40:01 Håkon: I'm happy to make a separate document out of it, as long as it's not taken out to be killed. 09:40:18 Steve: I think there are a number of options on the table, and making it a separate document lets us pursue those options. 09:40:40 Peter: My other concern there is that we're rechartering, and we have a small number of modules to make progress on. 09:40:51 (that should be ::text fwiw) 09:41:00 (though the board is indeed wrong) 09:41:20 Peter: I'm comfortable leaving it here until it's cooked; most of this seems like it can be moved into other modules. 09:41:24 Håkon: Bookmarks. 09:41:34 Håkon: This is a way to generate PDF bookmarks. 09:41:40 Håkon: It's modeled after what PDF can take. 09:41:57 Daniel: It's like a TOC. 09:42:08 Steve: It's a tree. 09:42:23 Daniel: It's a way of copying some element into a new special box? 09:42:31 Håkon: It's not a box, it's a logical structure. 09:42:39 Alex: Why not call it table-of-contents-level? 09:42:45 Anne: How is it stylistic? 09:42:53 Håkon: You need this when you generate PDF. 09:42:58 Anne: Can't HTML specify this? 09:43:45 () 09:43:52 Anne: The PDF generator should just extract it from the semantics of the document. 09:44:01 Steve: If it's an XML document, how do you do it? 09:44:14 dsinger has joined #css 09:44:20 Håkon: This is a pragmatic issue for CSS processors that want to create PDF files. 09:44:55 (If it's XML you convert it to XHTML.) 09:45:02 Alex: It's information used in another output format. 09:45:17 Alex: It doesn't have to be CSS if it doesn't have any rendering effect in CSS 09:46:29 Elika: It's adding semantic metadata to the document, not style. 09:47:08 Alex: You could also have the data in a META in the HTML. 09:47:16 Steve: But the selectors are more powerful. 09:48:00 Daniel: Why don't you use counters? 09:48:53 Elika: This is trying to do transformations and semantic tagging (using the power of selectors), which don't belong in style sheets. 09:49:14 Håkon: We're doing links and ??? in Opera ... we're not going to take that out. 09:49:34 Steve: We have electronic presentation forms, of which the bookmarks are a part. 09:49:41 Peter: I agree that this is a presentational issue. 09:50:50 Elika: Displaying the title of the document in the window title bar is similar, but we shouldn't do that in CSS. 09:51:04 Peter: I don't think this is absolutely out of scope. 09:51:41 Steve: If you want to claim CSS applies outside HTML, there's no way for an XML document to put something in the title. 09:52:00 Peter: Putting the window title in HTML is violating separation of presentation and content. 09:52:08 Elika: It's not about presentation; it's the title of the document. 09:52:20 Peter: These distinctions aren't always obvious. 09:52:47 Elika: You want to say "I am the title of the document", not "put me in the title bar". 09:52:53 Elika: That's semantic tagging. 09:53:19 alexmog has joined #css 09:53:25 Elika: The title is used for more than the title of the window, it's also used for bookmarking and in history 09:53:27 Peter: I don't want to kill it right off the bat. 09:53:30 Bert: No, let's kill it. 09:53:33 Elika: And other places in the UI 09:54:05 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. 09:55:08 Daniel: In Håkon's proposal, the bookmarks themselves cannot be styled. 09:55:17 Håkon: PDF can't do it. 09:55:23 ?: Although that doesn't mean a browser couldn't. 09:55:33 Håkon: This is a necessary feature for those of us who generate PDF files. 09:55:40 Steve: Where would you put it? 09:55:50 Elika: Some semantic tagging languag. 09:56:36 Håkon: Authors won't specify this. 09:56:48 David: It's in the user agent (e.g., style sheet... although preferably not). 09:56:56 Richard: ? 09:57:05 Anne: H1 would just be part of the document outline 09:57:14 Steve: What level of headings would you stop at? 09:57:17 Anne: Why would you stop? 09:57:42 Daniel: Limit depth. 09:57:48 Bert: Collapsable lists... leave that to the user. 09:58:50 Daniel: We see the power of doing this with CSS syntax, etc., but we don't agree it should be in CSS 09:58:59 Håkon: It's in GCPM, which is in a separate space. 10:00:05 alexmog has joined #css 10:00:57 Anne: Document outline is in HTML5. 10:01:36 Steve: Did you look at XSL-FO for bookmarks? 10:01:45 Håkon: I should. 10:02:02
10:22:19 Extensions to the float property 10:22:35 Howcome: Discussed on the mailing list recently. Antenna House has lots of good ideas. 10:22:49 Howcome: There are four different alternatives. 10:22:59 Howcome: First we extend float with 'inside' and 'outside'. 10:23:07 Howcome: synonyms for left and right depending on which page you're on 10:23:13 Howcome: Then we add 'top' 'bottom 10:23:22 Howcome: for vertical 10:23:39 Thenw e have reference keywords: 'page', 'column', 'multi-column' 10:23:56 Howcome: Then we have conditional keywords: 'unless-room' | 'hide-unless' 10:24:13 Howcome: so that advertisers can use any unused whitespace on the page 10:24:27 Alex: you could have adverts of different size 10:25:01 s/hide-unless/hide-unless-room/ 10:26:53 Howcome: float: top next page unless-room; Moves figure to top of next page unless room on current page 10:27:02 Alex: How is this different from the default behavior of floats? 10:27:43 Howcome draws on the whiteboard two pages 10:27:52 first page-half-filled with text 10:27:54 then a large image 10:27:57 that doesn't fit 10:28:01 normally it gets pushed to the next page 10:28:06 and text fills after the image 10:28:13 this would allow the image to shift over to the next page 10:28:19 bu the text to continue filling on the first page 10:28:29 Alex: Couldn't that just be regular float and clear? 10:29:51 top allows float to move above placeholder 10:29:58 Peter: that can get you into potential race conditions 10:30:01 Alex: that can be resolved 10:30:11 ("float: top next page unless room" could be more compactly be called "float: here") 10:31:00 Bert: you want the image centered. You only float it if it doesn't fit: it's not floated to any side. 10:32:33 Howcome: you might want it to go to the bottom of the next page if it doesn't fit 10:33:06 Steve: There's two cases 10:33:14 Steve: It either fits on the page with the callout or it doesn't 10:33:28 Steve: If it fits on the page, there are subcases. It would fit at the top, the bottom, or somewhere near the callout 10:33:43 Steve: If it doesn't fit on the page, you may want to specify where it should go when it doesn't fit 10:34:17 Steve: You want to specify where to put it if it does fit, and where to put it if it doesn't fit. 10:35:37 Peter: Can this be done with page-break controls, or widow orphans, or something else 10:35:57 Howcome: This case ('here') is non-floating 10:36:08 fits or not? 10:36:19 yes -- top | here bottom 10:36:29 s/here bottom/here | bottom/ 10:36:32 no -- 10:36:43 ... 10:37:03 Alex: We want to allow multiple figures with columns... we have to communicate intent that this should be regular float that should be anchored 10:37:08 (Or a fallback list, comma-separated, max. two items: 'float: here, top') 10:38:14 dsinger has joined #css 10:38:19 Howcome: There are some cases where you're not floating, but if there isn't room you want to float 10:39:34 Peter: Maybe you want to break out the notion of whether it fits. 10:39:43 Peter: Maybe you want to absolutely position the thing if it doesn't fits 10:40:38 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 10:40:54 Steve: other cases are it's not floated at all if it fits, but floated to next page if it doesn't 10:41:26 Steve: You don't want a break in the text. You just want it to flow. 10:43:08 Bert: I heard from Steve the use cases. 10:43:32 Bert: You place it this way if it fits, that way if it doesn't 10:43:40 Bert: Why not have a comma. 10:43:54 Bert: to separate the alternatives. 10:44:02 Bert: Then you don't have this unless keywords which ar so confusing. 10:44:43 Howcome: Suppose I have to floats that say 'top'. Are these floats both at the top, or does one go to the next page. 10:44:52 Howcome: so it can be at the top? 10:45:05 Steve: They're both floated to the top, show up in source order. 10:45:13 David: Pushing to the next page sounds like the clear property 10:45:29 Steve: Having 50% wide float then 100% wide float on top looks ugly 10:45:49 Håkon: With a very intelligent process you could fix that. 10:46:01 Alex: Grid positioning, with places in grid for bigger and smaller images. 10:46:06 Steve: Need a template. 10:46:27 Alex: With templates ... handle wanting at most one picture per page. 10:46:40 Håkon: float:top, clear: ? 10:46:43 David: clear:top ? 10:47:16 Alex: in this case you want just the float to clear, not the content that comes after 10:47:52 Steve: If you think it's complicated now... 10:48:02 Håkon: Maybe an argument for having separate vertical and horizontal floating properties? 10:48:13 Elika: Better in the same property for cascading, etc. 10:48:22 Elika: But maybe "unless-room", etc., could be a separate property. 10:49:19 David: What if float:left and v-float: top? 10:49:25 Steve, Alex: That's ok. 10:49:46 Bert writes: 10:49:53 Bert: float: left | right | here | top | bottom 10:50:30 Bert: float property can accept two comma-separated values 10:51:23 Bert: float: [left | right | none | top | bottom], [left | right | hidden | top | bottom] 10:51:32 (People discuss whether none is in the second list.) 10:52:11 float: none, * is the same as float: none 10:52:33 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) 10:53:01 Alex: I'd like to hear from a designer that they want this conditional fallback. 10:53:27 myakura has joined #css 10:53:33 Elika: Should you need the 'page' keyword for these examples? 10:54:03 Howcome: that's another question, should 'top'/'bottom' imply 'page'? 10:54:19 alexmog has joined #css 10:54:29 Howcome: There's a use case for floating to the top of the containing block. 10:54:59 Elika: Designers really want that. 10:57:02 Alex: For float anywhere on the page, we need keywords for top, left, right, bottom, plus keywords for abs pos CB and for page. 10:57:16 Peter: I can see floating to an arbitrary grid line. 10:58:27 Elika: Can we assume that these floats never escape the block formatting context we're in? 10:59:45 Discussion of grid positioning 11:00:57 Alex: I'm used to the Word model where you position an element on the page and then set the text wrap 11:04:21 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. 11:06:12 (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.) 11:09:15 (discussion of floating versus positioning) 11:11:56 Alex: just for reference, word allows positioning anywhere but not relative to auto-sized elements 11:12:48 Alex: so we'd get some very interesting issues if we have an auto-balanced multicol element with boxes floated to the bottom 11:15:19 Richard: Arabic books or Chinese books, where the page on the right face comes before the page on the left face... 11:15:32 Håkon: top is top, left is left, etc. 11:16:10 Richard: So in a vertical document, if I want a page float at the start of the text... 11:16:39 Alex: We consider 'top' and 'left' as synonyms given CSS2 floats that only go at the sides of the lines. 11:17:18 Peter, Alex: Do we want inside, outside, start, end? 11:18:22 ...before, after. 11:18:55 Håkon: I don't accept the requirement that the same style sheet should be used for Arabic and English. 11:19:12 Richard: I've spoken to people who translate to Arabic and find this very difficult. 11:20:51 (discussion of before, after, start, end, etc.) 11:21:27 Håkon: 'before page' is confusing 11:23:46 Elika: If you're designing a site that you know is going to be translated, you want to design the style sheet once. 11:25:39 Bert and Howcome don't think in a way that this makes sense 11:27:05 Alex: Approximately 50% of the people in this room see a legit use case for this 11:27:05 Peter: We have people in this room who specialize in internationalization and writing in different scripts, I think we should listen to them. 11:27:13 Richard: So Bert, you need to find people who back up your propositionin the Arabic and Hebrew-speaking world. 11:27:31 Richard: Let me be clear that sometimes you set left and you always want it to be left. 11:27:39 Richard: But oftentimes you want it to be the start of the line. 11:29:34 Steve: A long time ago we decided not to relativize left/right/top/bottom. It's confusing if left did not mean left anymore. 11:29:34 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. 11:30:05 (I was suggesting something like :root > main { float:left } :root:dir(rtl) > main { float:right } 11:30:06 ) 11:30:26 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. 11:30:59 David: The localizers will go through the theme style sheets to make sure that the style sheets use the correct relative keywords 11:31:47 David shows a copy of Firefox whose UI looks mirrored from the English layout 11:32:55 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 11:33:48 some argument about how much thinking happens when deciding which keyword to pick 11:34:28 David explains to howcome that Mozilla has implemented start/end *-start/*-end internally 11:34:57
11:36:07 MoZ has joined #css 11:49:24 dsinger has joined #css 12:31:47 type is not a valid attribute for br people 12:31:51
12:32:00 that's invalid too in HTML 12:32:19 (in fact, it would get parsed as
, which would mean another break, which works for me...) 12:34:35 Topic: Vertical text in IE 12:35:07 SaloniR has joined #css 12:35:25 Alex: We waited for Beta2 to come out before we started talking about implementing vertical writing for Mongolian etc.. 12:35:32 Alex: We have support for all eight text directions 12:35:39 Alex: We want that to be compatible with Text Layout spec 12:35:48 Alex: What we propose to do to Text Layout spec is two things 12:35:52 Alex; one we want to separate that 12:37:10 Alex: Currently there is vertical writing mode part 12:37:21 Alex: And there is a separate part about document character grid 12:37:35 Alex: We think that the text layout part of it is very well defined and appears to be complete 12:37:45 Alex: We propose to make that a separate spec and quickly bring it to completeness 12:37:58 Alex: For line grid and document grid, we are not sure how to define completeness 12:38:11 Alex: Because we don't have a requirements document. 12:38:22 Alex: We can't say whether this is complete or not complete. That should be a separate spec 12:38:37 Alex: We have a partial implementation of that as well, but we don't think that can move to REC as fast. 12:38:48 Alex: So we propose to separate that out and move it to low priority 12:38:55 Alex: but move vertical text to CR asap 12:39:12 Alex: The last thing that we want to do there is to add bottom-to-top writing mode 12:39:18 Alex: so that we have all eight directions. 12:39:35 Alex: I think we want to add it just because it is very well-defined what it does. 12:39:50 Alex: Use cases are marginal, but we don't see why we should undefine that when it is totally clear what it means. 12:39:55 Alex: I'm fine with making that optional 12:40:01 Alex: That's alll. 12:40:46 Alex: Once you've got Mongolian, you've got the hard part done. 12:40:55 Alex: Because in Mongolian your line bottom and paragraph bottom don't match. 12:43:22 Elika: So that sounds pretty good. 12:45:33 jason_cranfordtea has joined #css 12:45:43 Elika: I say to take the vertical writing mode controls and combine them with the definitions from the Box Module 12:45:51 Elika: And make that a spec 12:47:13 Elika: Because the writing mode definitions are not enough to say how the new orientation maps to the calculations in CSS2.1 Chapter 10 12:49:50 Elika: And how nested differing writing modes interact 12:50:50 ScribeNick: dbaron 12:50:52 Bert: But good thing about making text layout a CR is that it stabilizes the proeprty names. 12:51:11 Steve: So there's no objection to splitting out a piece of the text layout stuff? 12:52:18 ACTION: fantasai set up redirects 12:52:18 Created ACTION-94 - Set up redirects [on Elika Etemad - due 2008-08-28]. 12:53:21 (side discussion about publishing documents in dev space vs. group space) 12:53:40 Elika: You didn't implement glyph-orientation or ? properties? 12:53:44 Alex: right 12:53:54 Alex: they're not in the spec anymore 12:54:15 Elika: I'd like to define terminology so that other specs can refer to terminology rather than referring to values of specific properties. 12:54:22 Bert: depends on context 12:54:34