IRC log of css on 2008-08-21

Timestamps are in UTC.

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