/irc-logs / w3c / #css / 2009-06-05 / end

Options:

# Session Start: Fri Jun 05 00:00:01 2009
# Session Ident: #css
# [00:23] * Joins: jdaggett (jdaggett@82.242.111.184)
# [00:54] * Quits: karl (karlcow@128.30.54.58) (Client exited)
# [01:15] * Quits: arronei (arronei@131.107.0.114) (Client exited)
# [01:15] * Joins: arronei (arronei@131.107.0.112)
# [03:14] * Joins: karl (karlcow@128.30.54.58)
# [03:46] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
# [04:42] * Quits: arronei (arronei@131.107.0.112) (Ping timeout)
# [04:43] * Joins: arronei (arronei@131.107.0.112)
# [07:20] * Quits: arronei (arronei@131.107.0.112) (Ping timeout)
# [07:21] * Joins: arronei (arronei@131.107.0.112)
# [07:34] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: Tomorrow to fresh woods, and pastures new.)
# [07:54] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
# [07:56] * Joins: annevk (opera@80.13.73.211)
# [08:10] * Quits: jdaggett (jdaggett@82.242.111.184) (Quit: jdaggett)
# [08:39] * Quits: shepazu (schepers@128.30.52.30) (Quit: Core Breach)
# [08:52] * Joins: shepazu (schepers@128.30.52.30)
# [09:02] * Quits: annevk (opera@80.13.73.211) (Quit: annevk)
# [09:23] * Joins: jdaggett (jdaggett@193.51.208.72)
# [09:27] * Joins: Arron (arronei@193.51.208.72)
# [09:27] * Joins: alexmog (alexmog@193.51.208.72)
# [09:30] * Joins: glazou (glazou@193.51.208.72)
# [09:31] * Joins: ChrisL (ChrisL@128.30.52.30)
# [09:31] * Joins: mollydotcom (molly@193.51.208.72)
# [09:31] <Bert> trackbot, start meeting
# [09:31] * trackbot is starting a teleconference
# [09:31] * Joins: RRSAgent (rrs-loggee@128.30.52.30)
# [09:31] <RRSAgent> logging to http://www.w3.org/2009/06/05-CSS-irc
# [09:31] <trackbot> RRSAgent, make logs member
# [09:31] <RRSAgent> I have made the request, trackbot
# [09:31] * Joins: dbaron (dbaron@193.51.208.72)
# [09:31] <trackbot> Zakim, this will be Style_CSS FP
# [09:31] <Zakim> I do not see a conference matching that name scheduled within the next hour, trackbot
# [09:31] <trackbot> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
# [09:31] <trackbot> Date: 05 June 2009
# [09:31] <Bert> Scribe: Bert
# [09:31] <Bert> ScribeNick: Bert
# [09:31] <dbaron> ScribeNick: Bert
# [09:32] <Bert> Topic: SVG and CSS properties
# [09:34] <Bert> Chris: Some are attribs in SVG 1, not properties. Width/height attribs, but also width/height properties.
# [09:34] <Bert> Chris: This is ongoing work to harmonize in SVG2
# [09:35] <Bert> Chris: SVG2 intent is to say that that the property width is the *CSS* property width.
# [09:35] <Bert> Chris: SVG also wants to know what happens with calc().
# [09:35] <Bert> http://lists.w3.org/Archives/Public/www-style/2009Jun/0057.html
# [09:36] <Bert> Fantasai: Antennahouse has implemented calc().
# [09:36] <Bert> Fantasai: Editor is Håkon.
# [09:36] <Bert> Håkon: Values and Units module.
# [09:37] <Bert> Håkon: I didn't know about the implementation. Browsers don't do it currently.
# [09:37] <Bert> Chris: Calc very much wanted.
# [09:38] <Bert> Håkon: Also interested in other stuff, like cycle()?
# [09:38] <Bert> Chris: Don't know...
# [09:39] <Bert> DavidB: Use case for cycle() is list style, cycling through a set of values, then start over when you run out: symbols for bullets, italic/normal for font-style., etc.
# [09:40] <Bert> Chris: As I'm co-editor, I can probably just go ahead. But what parts are others interested in?
# [09:40] <Bert> DavidB: Mozilla might get to it soon.
# [09:40] <Bert> Fantasai: To Web authors this is as imprortant as backgrounds.
# [09:41] <Bert> Håkon: Authors can just add another element and get the effects.
# [09:41] * Joins: sylvaing (sylvaing@193.51.208.72)
# [09:41] * sylvaing -o-fight-club: auto;
# [09:42] <Bert> [Discussion about how realistic that is. Many designers or db-driven sites can't.]
# [09:42] <Bert> Alex: MS is looking at the features. No commitments. Seems possible to add it.
# [09:43] <Bert> Chris: We don't know what Apple plans.
# [09:43] <Bert> Chris: Module also seems to have to wait for other odules, because we might still need another unit or something like that.
# [09:44] <Bert> Daniel: So anser to SVG about calc() is: yes
# [09:44] <Bert> DavidB:Val & Units still needs impl. feedback, so expect some changes still.
# [09:45] <Bert> David: I think we'll find that we broke something somewhere in this module. AnntennaHouse didn't sent many comments, but I'm skeptical that it is really ready.
# [09:46] <Bert> Daniel: Is SVG asking for 'x' and 'y' properties?
# [09:47] <Bert> Chris: Or use 'top' and 'left'? But what is the interaction?
# [09:47] <Bert> Chris: What feedback can I take to the SVG WG?
# [09:47] <Bert> Anne: Can you do 'svg-x'?
# [09:47] <Bert> DavidB: Using 'top' seems OK, as long as you don't abs. pos. SVG elements.
# [09:48] <Bert> Fantasai: What are those properties in the e-mail for, exactly?
# [09:48] <Bert> [Chris explains x, y, width, cx, rx.... for center radius, etc.]
# [09:50] <Bert> Fantasai: Can maybe put some of them together in a shorthand. Use more descriptive name, write out the name.
# [09:51] <Bert> Fantasai: Naming scheme not very like CSS tradition.
# [09:51] <Bert> Anne: prefixing with svg- may be enough.
# [09:51] <Bert> Daniel: Discuss at TPAC?
# [09:51] <Bert> Chris: SVG will not meet there, but some people can be there.
# [09:52] <Bert> Daniel: Good, bcause SVG apparently already thought more about this.
# [09:52] <Bert> Steve: How about the writing-direction independent versions?
# [09:52] <Bert> Chris: The geometry is not dependent on writing direction.
# [09:53] <Bert> Chris: Relative directions are useful for text.
# [09:53] <Bert> Topic: SVG comments on Transitions
# [09:54] <Bert> Chris: Some mistakes in module, e.g., some properties are not interpolatable.
# [09:54] <Bert> Chris: Dean hasn't responded to the comments so far.
# [09:55] <Bert> http://lists.w3.org/Archives/Public/www-style/2009Feb/0681.html
# [09:56] <Bert> Chris: Not clear why things are different from SMIL. Is that on purpose or oversight?
# [09:56] * Joins: myakura (d2e8220d@64.62.228.82)
# [09:56] <Bert> Chris: Dean should explain that, if there are problems with SVG and SMIL approach.
# [09:57] <Bert> Daniel: Without maintainer of spec present we cannot go much further. We need replies from him first.
# [09:58] <Bert> Daniel: Since Feb [when e-mailwas sent] no replies at all?
# [09:58] <Bert> [We find a reply Mar 4]
# [09:59] <Bert> Chris: So seems SVG missed that reply then.
# [10:00] <Bert> Chris: So we need to wait for the updated draft then.
# [10:00] <Bert> Chris: Come back to it when we have that update.
# [10:02] <Bert> Topic: Fonts
# [10:02] <jdaggett> http://lists.w3.org/Archives/Public/www-style/2009Jun/0059.html
# [10:02] <Bert> John: Wanted to talk about bolder/lighter.
# [10:02] <Bert> John: I made a FF test build.
# [10:03] <Bert> John: Pb with old definition is figuring out what weight is when there are multiple steps since some ancestors.
# [10:04] <Bert> Chris: Does new idea work when there are only two fonts and two weights in the family?
# [10:04] <Bert> John: My build is available for people to experiment with.
# [10:04] * Joins: ed_work (ed@88.131.66.80)
# [10:05] <Bert> John: You can toggle between old and new behavior, via about:config
# [10:05] <Bert> [John shows results with a rich font on screen]
# [10:07] <Bert> John: Differences in weights between some steps is quite subtle. This screen is from existing behavior. Very little difference in this font between 800 and 900. 200 and 300 are the same in this font.
# [10:08] <Bert> Chris: What was the mapping from original font to CSS weight values in this case?
# [10:08] <Bert> John: The spec is very specific, it is defined, especially in the new draft.
# [10:09] <Bert> John: Searching for available font first goes in direction of keyword (down for 'lighter') and when it doesn't find any it goes back up.
# [10:09] <Bert> John: Important for a font with only one weight, e.g.,
# [10:10] <Bert> John: 400 and 500 can both become the normal weight, depending on the font. Some fonts have both, sone one or the other,
# [10:11] <Bert> [Another screen, three weights in the font.]
# [10:13] <Bert> [John shows example with actual text, side by side old and new]
# [10:15] <Bert> John: The table in my e-mail is font-independent. E.g., if you inherit 600 and ask for bolder, you get 900 as computed value.
# [10:16] <Bert> [Another example, with font that has 100, 200 and 400. so going 'bolder' from 100 gets 200 in the old scheme, but 400 in the new.]
# [10:17] <Bert> [Another screen, with nested elements]
# [10:18] <Bert> [Screen shows that with a rich font, the old scheme shows almost no difference when you do 'lighter'.]
# [10:19] <Bert> John: This last example is not a very typical case. Can't imagine somebody actually doing this. There are also only very few fonts like that.
# [10:20] <Bert> John: Also not very interoperable. On Windows quite hard to get at those weights.
# [10:20] <Bert> Chris: So question of using the right APIs.
# [10:21] <Bert> Chris: With @font-face, you can make a font that counts as weight '900' even if the font file itself says '100'.
# [10:21] <Bert> John: Yes, I have an example later on with that principle.
# [10:23] <Bert> Steve: The model for @font-face is that it provides an index into a database of fonts and you use the font that is finds for you.
# [10:24] <Bert> John: New system for bolder/lighter doesn't have to know what the available weights are.
# [10:24] <Bert> John: Some comments from Adobe seemed to be from viewpoint of API and asking 'bolder' relatibe to this font. But there is no "this font" in new system.
# [10:25] <Bert> Steve: Can calc() apply here?
# [10:25] <Bert> Steve: Ask for "old font-weight + 100" e.g.
# [10:26] <Bert> Steve: I'm trying to step through the font, looking for all available weights. But that seems impossible in practice.
# [10:26] <Bert> Steve: Would need a new type of query, to get the set of available weights.
# [10:27] <Bert> Steve: I think John's new system works well for the naive user. I was wondering if we lost something that was possible before.
# [10:28] <Bert> [Discussion of how much and how bolder/lighter are used at the moment.]
# [10:29] <Bert> John: We said at telcon before that the new mapping table was probably OK but we needed more examples.
# [10:30] <Bert> John: Bert, you had some issues before?
# [10:30] <Bert> Bert: Don't remember exactly, but the system seems reasonable so far.
# [10:31] <Bert> John: Current Fonts module mostly has implementations apart from some parts.
# [10:31] <Bert> DavidB: How about wider/narrower?
# [10:32] <Bert> John: Yes, I don't like that part in the spec. Don't see the use case.
# [10:32] <Bert> John: Bolder/ligher makes sense, but why wider/narrower?
# [10:33] <Bert> Chris: Probably thy just exist for symmetry with bolder/lighter?
# [10:33] <Bert> John: Drp them then?
# [10:34] <Bert> Chris: Leave, but mark them, so people can react.
# [10:34] <Bert> Chris: What is status of font-variant?
# [10:35] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: Tomorrow to fresh woods, and pastures new.)
# [10:35] <Bert> John: I want to work on accessing OpenType features, in combination with font-variant, but I don't have that yet.
# [10:35] <Bert> [John shows stretching example]
# [10:36] <Bert> John: Condensed faces are more common than expanded.
# [10:36] <Bert> John: Also added exmaples for 'unicode-range'.
# [10:37] <Bert> John: Google's Droid font is interesting, it has a couple of faces, including symbols.
# [10:37] <Bert> John: Various Unicode ranges in varipus faces, so you don't usually need the big 4.5MB font.
# [10:38] <Bert> John: Latin/Greek/Cyrilic is only 190K, e.g.
# [10:39] <Bert> John: With @font-face and unicode-range you can declare the complete font but not have to download it all.
# [10:40] <Bert> Chris: So what are the cases where previous bolder/lighter gave different results?
# [10:40] <Bert> John: Some cases were undefined.
# [10:40] <Bert> Chris: What happens with weights that aren't hundreds? E.g. 250?
# [10:41] <Bert> John: Can we come back to that later in the discussion, I have some thoughts.
# [10:42] <Bert> John: Existing wording already talked about font systems that don't use the numbers, but only has names.
# [10:43] <Bert> John: Weights in OpenType are in something called the OS/2 table, Apple uses it sometimes but not always. And it changes between Apple releases...
# [10:44] <dbaron> (mapping from style names to weights)
# [10:44] <Bert> Steve: Adobe has similar adjustments, because table not always reliable.
# [10:45] <Bert> John: Also mapping from name in different languages to weights is difficult (impossible?) to standardize.
# [10:45] <Bert> Chris: We should keep patform-dependent aspects out of the spec.
# [10:46] <Bert> Steve: That seems consistent with other heuristics we have, such as using italic when oblique was requested.
# [10:46] <ChrisL> wel, out of the model. those details can ber in an implementation appendix for example
# [10:46] <Bert> John: Adobe has no fonts with weights lower than 250.
# [10:47] <Bert> Steve: That is because of GDI...
# [10:47] <ChrisL> but the model should (re)group the logical components of a font faily together
# [10:47] <Bert> John: The module gives description of this, informative.
# [10:47] <Bert> Chris: That is fine. Explaining is good, but the model has to be clear.
# [10:48] <Bert> Steve: Won't get interoperability, though.
# [10:48] * ChrisL thanks bert. justwanted it to be clear
# [10:48] <Bert> Steve: Because the mapping when the numeric weights are missing or unreliable will be different on different platforms, implementations, etc.
# [10:49] <Bert> Steve: Testing difficult.
# [10:49] <Bert> Chris: Nothing in the description is a testable statement.
# [10:50] <Bert> John: We may want to make it normative that families can have more than two weights.
# [10:50] <jdaggett> http://people.mozilla.org/~jdaggett/font-face/
# [10:51] <Bert> John: E.g., Arial Narrow can still be used, but it should also be possible to use Arial with property narrow.
# [10:51] <Bert> John: Name given by @font-face overrides the name in the font file.
# [10:52] <Bert> John: John: So I ask for 'font-family: headline' and the system happens to have a "headline", but I still want the font that I called "Headline" in my own @font-face.
# [10:53] <Bert> [John shows example of that]
# [10:53] <Bert> John: We will need to make test cases for this.
# [10:53] <ChrisL> I notice http://people.mozilla.org/~jdaggett/font-face/fontfacewithall.html
# [10:54] <Bert> [John shows an example of overriding weights and styles with @font-face: a table that shows same font for all weights and styles.]
# [10:55] <Bert> Chris: Important for small-caps, too.
# [10:55] <Bert> John: But 'font-variant' is not a descriptor, so that doesn't work.
# [10:56] <Bert> John: But I'm working on OpenType features, bsides small-caps.
# [10:56] <ChrisL> i would support adding back font-variant as a descriptor, to point to small-caps fonts
# [10:56] <Bert> John: To enable OT features, we need to add more values to font-variant. The traditional values remain, but as rendering, rather than selection features.
# [10:57] <Bert> John: [Talking about shaping in Arabic, shows example]
# [10:57] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
# [10:58] <Bert> John: I added a hint: format("truetype-aat")
# [10:58] <Bert> John: A platform that recognizes that can use the font with that format, which contains advanced shaping.
# [10:59] <Bert> Chris: Does OT allow both the tradional and the AAT tables in one file?
# [10:59] <Bert> John: Syntactically yes, but some people say they will conflict.
# [11:00] <Bert> John: In the list after 'src', UA downloads the first fornat it recognizes (if any).
# [11:00] * ed_work thinks it would be good if the format-table listed ".svgz" as a common extension for svg fonts
# [11:01] * ChrisL wants erik t say that on the record
# [11:01] <Bert> Steve: What are the format() keywords? I sthere a registry? OT has different variations.
# [11:01] <ed_work> it would be good if the format-table listed ".svgz" as a common extension for svg fonts
# [11:01] <fantasai> why are they quoted? why not identifiers?
# [11:02] <Bert> John: The list of keywords is not a requirement on UAs to know them all.
# [11:02] <Bert> John: Vendors can add more.
# [11:02] <Bert> John: I see the issue, but seems a separate issue, unrelated to the spec.
# [11:03] <Bert> Chris: It is a non-exclusive registry, currently. The list in the spec is defined, but other keywords are allowed.
# [11:03] <Bert> Anne: Can suggest a vendor prefix?
# [11:04] <Bert> Steve: But unlike prefixed proeprties, these names are meant to be shared.
# [11:04] <Bert> Steve: Need a way to find the definition of a name.
# [11:05] <Bert> Steve: Can you mark the issue in the draft? Ask for comments on need for registry.
# [11:05] <Bert> Chris: Erik just asked for .svgz to be mentioned.
# [11:06] <Bert> Håkon: The "z" means it is same as SVG, but compressed?
# [11:07] <Bert> Anne: Do we need the list of extensions to be there at all?
# [11:07] <Bert> Chris: There are no MIME types for fonts.
# [11:08] <Bert> John: Not as font/foo, no, but we can do MIME types.
# [11:08] <anne> Anne: we do not do extension sniffing, we do content body sniffing
# [11:08] <Bert> Steve: In appendix, looks like mapping is wrong way round, from features to properties.
# [11:08] <Bert> Steve: Change the heading?
# [11:09] <anne> Anne: therefore extensions are irrelevant and should not be listed
# [11:09] * Bert thanks Anne
# [11:10] <Bert> Steve: Also in appendix, what about weights like 250?
# [11:11] <Bert> John: I don't really know how to solve that. Needs more time, to long for this draft.
# [11:11] <Bert> Steve: I sent a proposal earlier.
# [11:11] <Bert> John: OK, we should look at that (after today).
# [11:13] <Bert> Steve: Looking for something that says that the model may have hundreds as values, but...
# [11:14] <Bert> Steve: Something that helps people to understand that info about a font comes from several sources.
# [11:14] <Bert> Steve: Not normative, but warning people.
# [11:14] <Bert> Steve: A pointer to the appendix from the definition maybe enough.
# [11:15] <Bert> Steve: Original spec implied that values like 250 could not be mapped into CSS model.
# [11:16] <Bert> John: It is a 9-point scale, forget about the actual values. Just need to map the font onto nine points, whatever their names.
# [11:17] <Bert> Steve: Overlap between font models make things difficult.
# [11:17] <Bert> Daniel: Publish?
# [11:17] <Bert> RESOLVED: publish WD
# [11:18] <Bert> [BREAK]
# [11:22] <myakura> "Note: The following systems and UNICODE characters have not been given keywords: The superscript and subscript digits (starting at U+2070)" http://dev.w3.org/csswg/css3-lists/#non-repeating
# [11:24] <myakura> since we got "super-decimal" in <numeric>, this should be updated right?
# [11:37] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Ping timeout)
# [11:39] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
# [11:40] <fantasai> ScribeNick: fantasai
# [11:40] <fantasai> jdaggett: Once the current draft is in WD, I will start adding proposals for extensions to what we have now
# [11:40] <fantasai> jdaggett: Steve and I were discussing how to add support for specific OpenType features
# [11:41] <fantasai> jdaggett: But I think it's better if I put those in a more concrete form before we discuss
# [11:41] <fantasai> jdaggett: Also considering stroke and ? for fonts
# [11:41] <ChrisL> s/?/fill/
# [11:42] <fantasai> jdaggett: Hyatt had some proposals for that
# [11:42] <fantasai> fantasai: Can we just use the SVG properties? Less properties to carry around
# [11:42] <fantasai> jdaggett seems unconvinced
# [11:42] <ChrisL> please use the svg properties which already do that, not a new and conflicting thing
# [11:42] <fantasai> ChrisL seems enthusiastic
# [11:43] <fantasai> myakura, good point. But I'm thinking to remove the non-repeating section entirely...
# [11:44] <fantasai> myakura, circled numbers could be defined as numeric imo
# [11:44] <fantasai> myakura, but I haven't thought about itmuch yet :)
# [11:44] * Bert to myakura: yes, and maybe we should check if those superscript digits *can* be combined into numbers, i.e., if fonts typically are designed so that two of these digits next to each other look good...
# [11:44] <fantasai> Topic: Grid, Templates, and other coarse layout systems
# [11:45] * fantasai thinks we should assume they do and if they don't, consider that a bug in the font
# [11:45] <fantasai> Alex wants to show a demo
# [11:46] <fantasai> Alex: I'll start with something simple
# [11:46] <fantasai> Alex: This is our internal test framework
# [11:46] <fantasai> Alex: It does have Trident, but it's not IE
# [11:46] <fantasai> Alex: This is my private build, which is very very experimental
# [11:46] <fantasai> Alex: What we have here is a grid, and I'll show how it is defined
# [11:47] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Ping timeout)
# [11:47] <fantasai> Alex: This is the old syntax, it's not what we agreed when we discussed it and came up with repeat and fr unit
# [11:47] <fantasai> Alex: but we're not discussing syntax
# [11:47] <fantasai> Alex: This defines a grid with five columns
# [11:47] <alexmog> grid-columns: 1* 2* 3* 4* 5*;
# [11:47] <alexmog> <!DOCTYPE HTML>
# [11:47] <alexmog> <html>
# [11:47] <alexmog> <head>
# [11:47] <alexmog> <meta http-equiv="X-UA-Compatible" content="IE=9" >
# [11:47] <alexmog> <style>
# [11:47] <alexmog> body, html
# [11:47] <alexmog> {
# [11:47] <alexmog> margin:0;
# [11:47] <alexmog> padding:0;
# [11:47] <alexmog> width:100%;
# [11:48] <alexmog> height:100%;
# [11:48] <alexmog> }
# [11:48] <alexmog> div.grid
# [11:48] <alexmog> {
# [11:48] <alexmog> background:darkgray;
# [11:48] <alexmog> position:relative;
# [11:48] <alexmog> height:50%;
# [11:48] <alexmog> width:50%;
# [11:48] <alexmog> margin:50px;
# [11:48] <alexmog> grid-columns: 1* 2* 3* 4* 5*;
# [11:48] <alexmog> grid-rows: 1* 2* 3* 4* 5*;
# [11:48] <alexmog> }
# [11:48] <alexmog> .figure
# [11:48] <alexmog> {
# [11:48] <alexmog> position:absolute;
# [11:48] <alexmog> -ms-filter:"Alpha(Opacity=70)";
# [11:48] <alexmog> }
# [11:48] <alexmog> </style>
# [11:48] <fantasai> Alex: These colored rectangles are absolute-positioned using grid units. They're all 1gr unit wide and 1gr unit tall. The first one is based at 11, the second at 1.5.
# [11:48] <alexmog> </head>
# [11:48] <alexmog> <body id="Body">
# [11:48] <alexmog> <div id="BlackSquare" class="grid">
# [11:48] <alexmog> <div class="figure" style="background:blue; top:1gr; left:1gr; width:1gr; height:1gr;"></div>
# [11:48] <alexmog> <div class="figure" style="background:yellow; top:1.5gr; left:1.5gr; width:1gr; height:1gr;"></div>
# [11:48] <alexmog> <div class="figure" style="background:green; top:2.5gr; left:2.5gr; width:1gr; height:1gr;"></div>
# [11:48] <alexmog> <div class="figure" style="background:orange; bottom:0.5gr; right:0.5gr; width:1gr; height:1gr;"></div>
# [11:48] <alexmog> </div>
# [11:48] <alexmog> </body>
# [11:48] <alexmog> </html>
# [11:48] <fantasai> Alex: The way gr works with fractional units, goes from center of one grid column to center of other grid column.
# [11:49] <fantasai> Alex: The orange one is positioned from the right
# [11:49] <ChrisL> rrsagent, draft minutes
# [11:49] <RRSAgent> I have made the request to generate http://www.w3.org/2009/06/05-CSS-minutes.html ChrisL
# [11:49] <fantasai> Alex shows a grid with five columns and five rows
# [11:49] <fantasai> The first column and row is narrow, they gradually increase to wide for the last column and row
# [11:50] <fantasai> A blue rectangle fills the second row second column
# [11:50] <fantasai> Various other colored rectangles shift down, with their corners each in the center of a box in the grid
# [11:50] * ChrisL is relieved that the html paste (especially </html> seems to be escaped in the minutes
# [11:51] * fantasai It's w3c. If it couldn't handle markup pastes... we wouldn't still be using it so many years now!
# [11:52] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
# [11:52] <fantasai> Alex shows another demo with multicol text
# [11:52] * ChrisL it used to break on that, actually
# [11:53] <fantasai> His build shows the debug grid lines at the edges of the column boxes, breaking the multicol element into grid columns of column boxes and column gaps
# [11:54] * ChrisL groans at -ms-filter, hoped it was using rgba
# [11:55] <fantasai> He has manually set up a grid to match the multicol element (in the future a grid will be automatically created to match the multicol element)
# [11:55] <fantasai> Colored boxes are given a width in grid units
# [11:55] <fantasai> and the demo shows how they change size and position as they are shifted over, 0.5gr by 0.5gr
# [11:56] <fantasai> A series of 3gr wide boxes is green
# [11:56] <fantasai> the first one starts at the left edge, ends on the right edge of the second column
# [11:56] <fantasai> the second one starts halfway in the first column, ends halfway through the second column gap
# [11:56] <fantasai> the third one starts in the first column gap, ends at the right edge of the second columnn gap (start of the third column)
# [11:56] <fantasai> etc
# [11:57] <fantasai> howcome: There are a amazing things you can do with this
# [11:57] <fantasai> howcome: but with abspos elements you can't tell how tall they'll be
# [11:57] <fantasai> howcome: abspos elements would not intrude on the content.. but floats would
# [11:57] <fantasai> howcome: have you implemented floats?
# [11:57] <fantasai> howcome wants to see floats
# [11:57] <fantasai> Alex suspects this will crash
# [11:58] <fantasai> Molly: What happens if you use min or max heights?
# [11:58] <fantasai> Molly: with an auto-height box
# [11:58] <fantasai> Molly: Would that interfere with the grid system?
# [11:58] <fantasai> howcome: no, you'll just get a fixed height if the auto goes over and need a scrollbar or something
# [11:59] <fantasai> Alex shows a float that is centered in a 2-column element
# [11:59] <fantasai> Alex has positioned it with gr units, using abspos, plus -ms-float-wrap: square;
# [12:00] <fantasai> Alex: This is equivalent of float-offset of 1gr
# [12:00] <fantasai> Alex: I thought of implementing float-offset as well, but we can simulate any float-offset with abspos with this
# [12:01] <fantasai> howcome: So you position something absolutely, then flip a switch that makes it intrude
# [12:01] <fantasai> howcome: wouldn't it be better to float it from the beginning?
# [12:01] * Bert remembers having seen this demo, ten years ago, at a ftf in A'dam, by Quark, except that the intruding box was also rotated 30 degrees then... :-)
# [12:01] <fantasai> Alex: I started with this implementation for two reasons. It's the minimum amount of work to start using grid unit
# [12:01] <fantasai> Alex: ... how it will work internally anyway
# [12:01] <fantasai> Alex: Any system of complex floats, I will have two ...
# [12:01] <fantasai> (talking too fast)
# [12:02] <fantasai> dbaron: What if I give it top: 50%, which is 50% of the containers height, but we don't know the containers height until we've laid out the contents
# [12:02] <fantasai> Alex: there's a lot of circular dependencies
# [12:02] <fantasai> Alex ...
# [12:02] <fantasai> Alex: Our thinking was that in any circular dependencies like this, we will do a two pass layout
# [12:03] <fantasai> Alex: We will do normal layout that doesn't do any backwards positioning, that gives the enter points for auto positioning
# [12:03] <fantasai> Alex: If we need to recalculate, we then do another pass, but dont' reposition the auto
# [12:03] <fantasai> dbaron: how does this interact with other two pass layouts, if you nest them?
# [12:03] <fantasai> dbaron: There's stuff with various float -positioning stuff that already does two-pass layout
# [12:04] <fantasai> dbaron: some of this circular stuff will be hard to get righ
# [12:04] <fantasai> t
# [12:04] <fantasai> howcome: I would like to see a bake-off here to see which is the best syntax
# [12:04] <fantasai> Alex: I make no claims on syntax with this prototype, this prototype only tries to show up the units
# [12:04] <fantasai> howcome: I think using float and float-offset better expresses
# [12:05] <fantasai> Steve: no, because as I change the column widths, the figure goes all over the place
# [12:05] <fantasai> howcome: no, float-offset works horizontally and vertically
# [12:05] <fantasai> howcome: look at the gcpm draft
# [12:05] <fantasai> ...
# [12:06] <fantasai> discussion of whether it's floats or abspos
# [12:06] <fantasai> Steve: The important part of float is that it keeps an anchor in the text and tries to stay near it
# [12:07] <fantasai> howcome: In GCPM we extend float to be able to change the reference point to ancestor containers like the multicol element or the page
# [12:07] <fantasai> ...
# [12:08] <fantasai> howcome: I think we should see the same examples and syntax side by side
# [12:08] <fantasai> Steve: Yes, we should look at it in both kinds of models
# [12:08] <fantasai> Steve: If that's the only thing we're discussing, that's pretty good :)
# [12:09] <fantasai> Alex shows another demo
# [12:09] <fantasai> Alex: This is something like what a news site would look like
# [12:09] <fantasai> Alex has NEWS in blue stretched across the top of a grid with
# [12:09] <fantasai> six columns and narrow column gaps in between
# [12:09] <fantasai> the horizontal grid is 1em straight through
# [12:10] <fantasai> Article text is laid out in columns
# [12:10] <fantasai> first article takes up two columns
# [12:10] <fantasai> second three columns, split into 3 columns (muticol)
# [12:10] <fantasai> last one slips into last column
# [12:10] * Quits: glazou (glazou@193.51.208.72) (Quit: glazou)
# [12:11] <fantasai> (first article is two grid columns, but only one column of text)
# [12:11] <fantasai> howcome: what happens if you make the page narrower? do the columns collapse?
# [12:12] <fantasai> howcome: multicol reduces the number of columns as you run out of room for them
# [12:12] * Quits: myakura (d2e8220d@64.62.228.82) (Quit: http://www.mibbit.com ajax IRC Client)
# [12:12] <fantasai> fantasai: I'm not sure absolutely positioning this layout is a good idea.
# [12:13] <fantasai> fantasai: I would want to use in-flow layout, with snap-to-grid
# [12:13] <fantasai> fantasai: so the boxes align on the grid lines, but they have the ability to adapt to the content and the available width
# [12:13] <fantasai> Alex: ...
# [12:14] <fantasai> Alex thinks snap-to-grid is a good idea, it would be the next step
# [12:15] <fantasai> Steve: If I had float-position, and said float-position: 0 1gr, wouldn't that snap to grid?
# [12:15] <fantasai> Alex: You just came up with a property that doesn't exist
# [12:16] <fantasai> Alex: snap-to-grid would mean from your starting position, find the next grid line
# [12:16] <fantasai> Alex: snap-to-grid should be a separate property
# [12:17] <fantasai> dbaron: I think part of the question here is when people have layouts like this
# [12:17] <fantasai> dbaron: That has stuff wrapped around something in the middle
# [12:17] <fantasai> dbaron: what rules are determining where that goes?
# [12:17] <fantasai> dbaron: What leads people to chose to put something where it's put?
# [12:18] <fantasai> dbaron: Learning that should determine how we design a system that lets them do that
# [12:18] * fantasai thinks dbaron's point is very important !!!
# [12:18] <fantasai> Alex: In one process you have a grid, and you know exactly where everything goes (?)
# [12:18] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: Tomorrow to fresh woods, and pastures new.)
# [12:19] <fantasai> Alex: In another process, you have a bunch of stuff that you want to align to the grid, but you're not sure exactly where they go
# [12:19] <fantasai> Alex: For the second system, you'd use snap-to-grid
# [12:19] <fantasai> dbaron: I was asking more about the case where you have a thing with content flowing around it, is it floating, or abspos, or some new thing that's neither
# [12:21] <dbaron> ScribeNick: dbaron
# [12:21] <dbaron> fantasai: So suppose I have a 2-column layout with a bunch of boxes in each of unknown heights, and I want the tops and bottoms of these boxes in the columns to snap to the grid [draws on whiteboard].
# [12:23] <dbaron> dbaron: Can snap-to-grid be a length, so height: calc(auto + snap-to-grid), calc(5em + snap-to-grid)?
# [12:23] <dbaron> Alex: I was thinking of snap-to-grid being a property.
# [12:24] <fantasai> dbaron: If snap-to-grid is a property, what do you snap to the grid?
# [12:24] <dbaron> ScribeNick: fantasai
# [12:24] <fantasai> howcome: I don't think it can be a property, you snap the height
# [12:24] <fantasai> Alex says snap-to-grid would be a value
# [12:25] <fantasai> Steve: So you could rop the calc() if you define snap-to-grid to mean auto plus snap-to-grid
# [12:25] <fantasai> fantasai: but the height is the content-box height
# [12:25] <dbaron> fantasai: What if I want the border-box height to snap to the grid rather than the content-box height to snap to the grid?
# [12:25] <dbaron> fantasai: Consider interaction with min-height.
# [12:25] <fantasai> Arron: and perhaps I want the min-height to be the previous gridline
# [12:25] <fantasai> Arron: You might have an overflow condition
# [12:26] <fantasai> Alex: We have a lot of pretty cool ideas
# [12:26] <fantasai> Alex: We can try to come up with use cases and examples of syntax
# [12:26] * Bert wonders if you can't just put it all in a <table> :-)
# [12:26] <fantasai> Alex: I would be willing to try an implementation
# [12:26] <fantasai> howcome: We had a document of use cases for floats
# [12:26] <fantasai> Alex: uc.html in the gcpm directory
# [12:27] <fantasai> Alex: I didn't meant to make all this conversation about grid positioning, I think the agenda item was multiple proposals and how they interact
# [12:27] <fantasai> fantasai: I think grid positioning plus snap-to-grid would interact very well with the template layout module
# [12:28] <fantasai> Bert: The abspos intrution is intriguing, but are other people willing to implement it?
# [12:28] <fantasai> dbaron: With abspos, we lay out the abspos elements *after* we're done laying out their container
# [12:28] <fantasai> dbaron: Because of percentages etc.
# [12:28] * Joins: howcome (howcome@193.51.208.72)
# [12:28] <fantasai> dbaron: but that doesn't let you wrap text around it
# [12:28] <howcome> http://dev.w3.org/csswg/css3-gcpm/uc.html
# [12:29] <fantasai> dbaron: I don't understand how you do this
# [12:29] <fantasai> Alex: abspos intrustions are really floats, just because the syntax is the same as abspos doesn't mean it has to be laid out as such
# [12:29] <fantasai> dbaron: But if we're doing in the abspos model, we have features like top: 50% and bottom: 50%, that we might not want in this case
# [12:30] <fantasai> Alex: We could disallow percentages on absolute intrusions
# [12:30] <fantasai> Alex: Or we may have to deal with multiple pass layout
# [12:30] <fantasai> dbaron: I'd like to avoid multiple-pass layout as much as possible
# [12:30] <fantasai> dbaron: Because I don't think authors know what triggers it, and trigger it by accident
# [12:30] <fantasai> dbaron: And then nest like five things with multiple-pass layout, which slows down pages considerably
# [12:31] <fantasai> Molly: What would cause that? I know tables cause that
# [12:31] <fantasai> dbaron: Tables have fewer passes because the passes are to do different things
# [12:31] <fantasai> dbaron: And the first one you can cache
# [12:31] <fantasai> dbaron: There's potentially a third pass there to do height recalculation
# [12:32] <fantasai> dbaron: There's also some multiple pass stuff in our implementation for line breaking and floats.. that doesn't necessarily need to be multiple passes
# [12:32] * Bert notices that Alex's screen looks like Nextstep from 1989, except with color :-)
# [12:32] <fantasai> Steve: If you're doing floats that can cross columns backwards, that is enough to create most of the problems you're dealing with
# [12:32] <fantasai> dbaron: fwiw, I've been investigating some float-wrapping bugs
# [12:33] <fantasai> dbaron: And I've written testcases that no browsers get right according to spec
# [12:33] * sylvaing @Bert it's called Windows 7. Really :)
# [12:33] <fantasai> dbaron: And I couldn't figure out how to implement in our implementation at all
# [12:33] <fantasai> dbaron: so I just gave up
# [12:33] <fantasai> dbaron: And that's the float stuff in our existing model
# [12:33] <fantasai> Steve: ... lenght of total container is dependent on those
# [12:33] <fantasai> Steve: We didn't allow circularity. One way to avoid that is to say you can't use percentage heights for this sort of thing
# [12:33] * Joins: glazou (glazou@193.51.208.72)
# [12:34] <fantasai> Steve: You could use grid unit heights
# [12:34] <fantasai> fantasai: you can do percentages with grid units
# [12:34] <fantasai> fantasai: by defining the grid relative to the size of the block
# [12:35] <fantasai> howcome: You could see a cocktail of calc and grid units and percentages ... :)
# [12:35] <fantasai> Bert: Another thing that designers will want is some way to position elements but then have them all be as tall as the tallest element
# [12:35] <fantasai> Molly: like tables
# [12:36] <fantasai> Bert: for example, the news articles in Alex's example, you would want them boxes to be as tall as the tallest
# [12:36] <fantasai> Molly: This is one of the most disconcerting and difficult things to explain to people moving from table layout to postinioning
# [12:37] * jdaggett stomach grumbles...
# [12:38] <fantasai> fantasai: Template layout plus snap-to-grid would probably be better for Alex's example
# [12:38] * jdaggett mmmm, cafeteria food dreams....
# [12:38] <glazou> Daniel: we had this discussion this morning in the car and a proposal could be height: inherit(/selector/)
# [12:38] <Bert> Daniel: Something like 'height: inherit-from(<some selector>)'
# [12:38] <fantasai> Molly: So suppose you have three TDs in a row. Even if they have various amounts of content, the boxes are all the same height
# [12:39] <fantasai> howcome: Now that IE8 has CSS tables, you can express it in CSS tables
# [12:39] * sylvaing -moz-jdaggett: hungrier; // 9 point scale ?
# [12:39] <fantasai> ChrisL: CSS tables are for non-tabular data tthat you want to lay out as tables
# [12:39] <fantasai> Bert: The main shortcoming is that you can't reorder the cells
# [12:40] * jdaggett no, no, integer values 100 ... 900
# [12:40] * glazou notes that this document is pretty old but still has interesting options... http://daniel.glazman.free.fr/weblog/position__new.html
# [12:40] * jdaggett with hungrier and fuller as relative values
# [12:40] * dbaron thought that was jdaggett { hunger: hungrier; }
# [12:40] <fantasai> Molly: In an environment such as BBC, the lack of reordering of columns is a huge problem
# [12:41] <fantasai> Steve: Use case, I have parallel English and French text. Sometimes one is taller, some times another is taller, but in each case I want each paragraph to start at the same level
# [12:42] <fantasai> howcome: We have row-based tables now. If you want to do that, you want a column-based table
# [12:42] * sylvaing dbaron, correct! and from my Tokyo recollection, the property inherits
# [12:43] <fantasai> howcome: Another thing I want from tables is some way to start a new row, without having to insert a row element
# [12:43] * Parts: anne (annevk@193.51.208.72)
# [12:43] * Joins: anne (annevk@193.51.208.72)
# [12:43] * jdaggett will soon be nibbling on bert
# [12:44] * jdaggett probably a bit salty...
# [12:44] * sylvaing @jdaggett don't tempt us with a good time
# [12:44] <fantasai> snap-to-grid would not solve the equal heights problem in Molly and Steve's use cases
# [12:44] <fantasai> dbaron: Another question I wanted to bring up is what defines the horizontal grid lines
# [12:45] <fantasai> dbaron: Sometimes you want the horizontal grid lines to depend on the content in interesting ways like this
# [12:45] <fantasai> Alex: So far we've tried to avoid fit-to-content with grid lines
# [12:45] <fantasai> Alex: like template layout depending on content, then defining grid lines, that the content relies on
# [12:46] <fantasai> Alex: that's pretty scary
# [12:46] * mollydotcom I'll just eat content
# [12:46] * dbaron thinks this grammar is something up with which I will not put
# [12:46] <fantasai> Steve: How do I define a sequence of grid cells that make up the region into which content is flowed?
# [12:46] * sylvaing hunger: there should be an app for that
# [12:46] <fantasai> steve: e.g in his story, how do I know that the first story did columns 1 and 2, and the second 3-4-5, the last 6
# [12:47] <fantasai> Steve: What is the syntax for specifying the flow sequence?
# [12:47] * Quits: mollydotcom (molly@193.51.208.72) (Quit: mollydotcom)
# [12:47] <fantasai> <br type="lunch"/>
# [12:47] * Quits: glazou (glazou@193.51.208.72) (Quit: glazou)
# [12:50] * Quits: Arron (arronei@193.51.208.72) (Ping timeout)
# [13:47] * Joins: glazou (glazou@193.51.208.72)
# [13:50] * Joins: mollydotcom (molly@193.51.208.72)
# [13:56] * Joins: Arron (arronei@193.51.208.72)
# [13:57] <dbaron> http://maps.google.com/maps?f=q&q=M%C3%A9diath%C3%A8que+d%27Antibes,+Antibes,+France&ie=UTF8
# [14:00] <howcome> http://people.opera.com/howcome/2009/tests/three-column.html
# [14:01] <jdaggett> ScribeNick: jdaggett
# [14:01] <jdaggett> steve z drawing grids on whiteboard
# [14:01] * Bert - KML also here: http://www.w3.org/Style/CSS/W3C-ERCIM.kml
# [14:01] <jdaggett> how does
# [14:01] <fantasai> The grid has five columns, with 2 and 4 being narrow
# [14:02] <fantasai> All five rows are equal height
# [14:02] <jdaggett> a. which columns correspond to which flow
# [14:02] <jdaggett> b. what's the flow order between columns
# [14:03] <jdaggett> stevez: labeling graph in column major order
# [14:03] <jdaggett> stevez: need to distinguish gaps too
# [14:04] <jdaggett> stevez: indesign allows one to specify flow order
# [14:04] <jdaggett> stevez draws non-rectangular flow example
# [14:05] <jdaggett> stevez: could use cell indices to specify flow order
# [14:05] <jdaggett> stevez: not proposing this, but need to consider this case
# [14:06] <jdaggett> hakon: problem is you're defining an absolute size
# [14:07] <jdaggett> hakon: so what happens when content spills out
# [14:07] <jdaggett> stevez: regions may be growable
# [14:07] <jdaggett> hakon: needs to be growable so fixed coords may not be the best way
# [14:08] <jdaggett> bert: could still have growable model with coords
# [14:08] <jdaggett> bert: name defines spaces not overall sizes
# [14:08] <jdaggett> bert: sizes could be flexible
# [14:09] <jdaggett> stevez: there are still relations that you want to keep in this example
# [14:09] <jdaggett> alex: could define a way of specifying grow direction
# [14:10] <jdaggett> stevez: point is we need to suggest a solution here
# [14:10] <jdaggett> alex: another thing is need a way to specify linkage with other containers
# [14:10] <jdaggett> hakon: that gets into page layout
# [14:11] <jdaggett> hakon talks about pagination in gcpm
# [14:11] <jdaggett> discussion of whether floats suffice or not
# [14:12] <jdaggett> elika: floats can't intrude on other floats
# [14:12] <jdaggett> hakon: not yet (threatening tone)
# [14:12] <jdaggett> dbaron: need to think about borders/bg here
# [14:13] * Quits: shepazu (schepers@128.30.52.30) (Ping timeout)
# [14:13] <jdaggett> bert: want to mention flex unit could also be applied to grid
# [14:14] <jdaggett> alex: grid syntax and flex model are not supersets of each other
# [14:14] <jdaggett> bert: a designer liked using template layout but also likes gr units
# [14:15] <jdaggett> stevez: how do we drive this forward?
# [14:15] <jdaggett> stevez: we have grids, templates and flex units
# [14:15] <jdaggett> stevez: how do we make progress?
# [14:15] <jdaggett> alex: need use cases
# [14:16] <jdaggett> alex: web/book/other sorts of layout
# [14:16] <jdaggett> bert: have other examples from designers
# [14:17] <jdaggett> anne: need to remember ui, example: gmail
# [14:17] <jdaggett> dbaron comments on funky layout used by gmail
# [14:18] <dbaron> well, its use of tables
# [14:18] <fantasai> ?: We should have a repository of use cases
# [14:18] <jdaggett> stevez: maybe there are students who want to do this as a thesis topic
# [14:19] <jdaggett> elika: hard to get details, not just images but src code
# [14:19] <jdaggett> molly: yup
# [14:19] <jdaggett> molly: designers don't understand src, that's rare, only a handful in the whole wide world
# [14:20] <jdaggett> elika: also, how does the model work when you change the window, etc.
# [14:20] <fantasai> We need to understand not just the static picture people wnat to get
# [14:20] <fantasai> but also how it corresponds to the source code
# [14:20] <fantasai> (ideally)
# [14:20] <fantasai> And then also how that static image changes in response to changes in window size
# [14:20] <fantasai> and font size
# [14:20] <fantasai> Molly: and dynamic content
# [14:21] <jdaggett> molly: some of the css11 folks my be a good resource
# [14:22] * anne finds http://www.css11.navy.mil/
# [14:22] <jdaggett> elika: static markups are fine if they reflect behavior
# [14:22] * anne thinks that's a different CSS 11
# [14:22] <fantasai> you'd need multiple pictures and explanation mixed in
# [14:23] * sylvaing thinks we should listen to people with nuclear weapons
# [14:24] * anne North Korea FTW
# [14:24] <jdaggett> molly discussing how to interact with design community
# [14:25] <jdaggett> elika: not so much syntax but what the behavior / use case is
# [14:25] * Bert wants a property that makes his screen twice as large :-)
# [14:25] <fantasai> elika: they should not think of syntax at all, or of the constraints CSS has, only what source code they want to input and what they want the resulting layout and behavior to be
# [14:26] * sylvaing wonders if Hakon can host a Pyongyang F2F ?
# [14:26] <jdaggett> discussion in infinite loop
# [14:26] <jdaggett> while (true) { talk to designers }
# [14:27] <fantasai> several: ask visual designers with no background in CSS
# [14:27] <fantasai> fantasai: consideration there is that most of those are stuck in print design, where you get static pixel-perfect layouts
# [14:27] * jdaggett does not want this mom thinking about css
# [14:27] <fantasai> fantasai: whereas we need to understand how the layout flexes
# [14:27] * jdaggett s/this/his/
# [14:27] <fantasai> Alex ...
# [14:28] <fantasai> Steve: We want a set of pictures or content scenarios with changes
# [14:28] <fantasai> Steve: Give us a layout for this, now what happens if we swap this content with that
# [14:28] <fantasai> Steve: And then we have to figure out what the requirements are from that
# [14:29] <fantasai> Molly: That's something I could ask via my own website
# [14:29] <fantasai> Molly: We could find a lot of people that would contribute to that
# [14:29] <fantasai> Molly: We just need some set criteria so we get useful results
# [14:30] <fantasai> Molly: It may be useful also to go to hybrid designers, good code and good design
# [14:30] <fantasai> Arron: Start with the visual designers, then go to the more technical people
# [14:30] <jdaggett> glazman: end of item
# [14:31] <fantasai> ACTION: Molly set up a list of criteria for fishing for layout reqs
# [14:31] * trackbot noticed an ACTION. Trying to create it.
# [14:31] * RRSAgent records action 1
# [14:31] <trackbot> Created ACTION-157 - Set up a list of criteria for fishing for layout reqs [on Molly Holzschlag - due 2009-06-12].
# [14:31] <glazou> GRENAAAAAAADE !!!!!
# [14:32] <fantasai> ACTION: Molly find a place to host feedback
# [14:32] * trackbot noticed an ACTION. Trying to create it.
# [14:32] * RRSAgent records action 2
# [14:32] <trackbot> Created ACTION-158 - Find a place to host feedback [on Molly Holzschlag - due 2009-06-12].
# [14:33] <jdaggett> topic: bg/border
# [14:33] <jdaggett> elika: split out border-image from current draft
# [14:34] <jdaggett> other issues
# [14:34] <fantasai> http://dev.w3.org/csswg/css3-background/#border-images
# [14:34] <fantasai> http://lists.w3.org/Archives/Public/www-style/2009Jun/0074.html
# [14:34] <jdaggett> interaction of border-image and box shadow
# [14:37] <jdaggett> elika explaining responses to border-image survey
# [14:37] <jdaggett> elika: open issues are fifth question
# [14:37] <jdaggett> elika: exact syntax for fallback colors
# [14:38] <jdaggett> elika: using border-image to mask box shadow
# [14:38] <fantasai> seems to be a slight preference for masking
# [14:38] <fantasai> people cite JavaScript manip
# [14:38] <jdaggett> elika: first question just needs a decision by us
# [14:39] <jdaggett> elika: clipping the border image
# [14:39] <jdaggett> elika showing spec
# [14:39] <jdaggett> dbaron: names for these keywords
# [14:39] <jdaggett> elika: fill and empty
# [14:40] <jdaggett> elika: fill means clipped by default, use fill to trigger
# [14:40] <jdaggett> dbaron: with 9 slices, do you draw the middle ones or not?
# [14:41] <fantasai> A) Keep the middle by default. Add 'empty' to clip it.
# [14:41] <fantasai> B) Clip the middle by default. Add 'fill' to use it.
# [14:41] <fantasai> C) No keyword, always kept. (Make transparent as needed.)
# [14:41] <jdaggett> stevez: simplest is (c)
# [14:42] <jdaggett> dbaron: don't like the name 'empty'
# [14:42] <fantasai> keyword, if added, would be added to 'border-image-slice' party
# [14:42] <jdaggett> bert: empty is good
# [14:42] <jdaggett> stevez: doughnut?
# [14:42] <jdaggett> anne: clip-middle?
# [14:43] <jdaggett> elika: no donuts please
# [14:43] <jdaggett> hakon: we're talking about a border, it shouldn't cover everything by default
# [14:43] <jdaggett> stevez: relation to background?
# [14:43] <jdaggett> elika: on top of bg
# [14:44] <jdaggett> chrisl: how does this tile?
# [14:44] <jdaggett> elika: depends
# [14:44] <Bert> empty / doughnut / hollow...
# [14:44] <Bert> or donut
# [14:44] <jdaggett> stevez: i like (b), with or without fill keyword
# [14:45] <jdaggett> elika: use case: aqua buttons
# [14:45] <jdaggett> dbaron: i vote for (c)
# [14:46] * mollydotcom points out that already people are pinging me: re ways to contribute ideas
# [14:46] <jdaggett> discussion of image types used for this, whether have alpha or not
# [14:46] <jdaggett> elika: straw poll?
# [14:47] <jdaggett> hakon: idea of border-image is to allow any image
# [14:47] <fantasai> several: most use cases of border image would need transparency around the outer edge any way
# [14:47] <jdaggett> dbaron: you're not going to chop and slice a picture of your face
# [14:47] <fantasai> s/image/image format/
# [14:48] <jdaggett> stevez: all in favor of anything that increases photoshop sales
# [14:48] <jdaggett> chrisl: b
# [14:48] <jdaggett> arron: c
# [14:48] <jdaggett> elika: c
# [14:48] <jdaggett> molly: b
# [14:48] <jdaggett> alex: abstain
# [14:48] <jdaggett> hakon: b
# [14:48] <dbaron> jdaggett: abstain
# [14:48] <jdaggett> anne: c
# [14:49] <jdaggett> bert: c
# [14:49] <jdaggett> dbaron: c
# [14:49] <jdaggett> glazman: abstain
# [14:49] <jdaggett> stevez: b
# [14:49] <jdaggett> sylvain: b
# [14:49] <jdaggett> glazman: survivor wins?
# [14:50] <jdaggett> glazman: no use of sticks...
# [14:50] * sylvaing calls on the Commander Submarine Squadron
# [14:50] <jdaggett> stevez: why c? simpler?
# [14:50] <fantasai> and if people complain, then you can add it later
# [14:50] <jdaggett> jdaggett: abstain to c
# [14:51] <jdaggett> don't have consensus here
# [14:51] <jdaggett> bert: didn't designers ask for (a)
# [14:52] <jdaggett> elika: hyatt wanted a way of clipping but doesn't care
# [14:52] <jdaggett> hakon: anybody who doesn't like (a)?
# [14:52] <jdaggett> hakon: can the (c) people live with (a)?
# [14:52] <jdaggett> stevez: (b) makes sense for performance, get high perf by default
# [14:53] <jdaggett> bert: why better perf?
# [14:53] <jdaggett> stevez: by default, don't need to draw
# [14:53] <jdaggett> bert: but how slow is it to blit
# [14:53] <jdaggett> hakon: i can live with (a) or (b)
# [14:54] <jdaggett> hakon: want to make a border out of a jpeg
# [14:55] <jdaggett> daniel: conversions like this happen all the time (jpeg <==> png)
# [14:55] <jdaggett> hakon: with (c) what if you have to scale the png?
# [14:56] <jdaggett> hakon: worried about half pixels
# [14:56] <jdaggett> dbaron: guess i'm ok with (b)
# [14:56] <jdaggett> elika: i'm ok with (b)
# [14:56] <jdaggett> anne: (b) is useless but, sure, whatever
# [14:57] <jdaggett> hakon: but this should be the default
# [14:57] <jdaggett> daniel: so?
# [14:57] <jdaggett> aaron: don't like empty, fill not so much
# [14:58] <dbaron> (sense that people dislike (a) because of the 'empty' keyword, not the concept)
# [14:58] <jdaggett> chrisl: i like what (b) does, whatever the keyword
# [14:59] <jdaggett> elika: hyatt likes (b) for perf reasons
# [14:59] <Arron> s/aaron/arron
# [14:59] <fantasai> s/likes/would like/
# [14:59] <fantasai> RESOLVED: Clip middle by default, add 'fill' to use it
# [14:59] <jdaggett> elika: but i haven't talked to hyatt in six months...
# [14:59] <fantasai> lol
# [15:00] <jdaggett> bert: the keyword 'fill' has other uses?
# [15:00] <dbaron> I don't like 'fit: fill'
# [15:00] <jdaggett> chrisl: fill is overloaded
# [15:00] <jdaggett> molly: need to use context
# [15:01] <jdaggett> stevez: fill-center, clip-center?
# [15:01] <jdaggett> elika: no, god damn it, don't need to be so explicit
# [15:01] <jdaggett> <break>
# [15:02] <jdaggett> dbaron requests HTML syntax
# [15:02] * jdaggett is a free man
# [15:26] * mollydotcom thinks jdaggett is no longer free
# [15:26] <jdaggett> <break over>?
# [15:27] <glazou> jdaggett: no, clear:both :-)
# [15:29] <anne> <br clear=all>
# [15:29] <jdaggett> elika: next topic - masking issue
# [15:29] <jdaggett> elika: chrisl to think about this
# [15:30] <jdaggett> elika: last issue - syntax for fallback colors
# [15:30] <jdaggett> chrisl: and the shorthand
# [15:30] * Zakim jdaggett, you typed too many words without commas; I suspect you forgot to start with 'to ...'
# [15:31] <jdaggett> Zakim, please don't pester me
# [15:31] <Zakim> I don't understand 'please don't pester me', jdaggett
# [15:31] <jdaggett> Zakim, that's fine
# [15:31] <Zakim> I don't understand 'that's fine', jdaggett
# [15:32] <jdaggett> elika: people want fallback colors
# [15:32] <jdaggett> elika: proposal from dbaron to require background-size to follow background-position
# [15:32] <jdaggett> dbaron: already require that if both are present
# [15:33] <jdaggett> dbaron quotes spec
# [15:33] <dbaron> http://dev.w3.org/csswg/css3-background/#the-background-shorthand-property
# [15:33] <fantasai> <final-bg-layer> = <bg-image> || <bg-position> || / <bg-size> || <repeat> || <attachment> || <bg-origin> || no-clip || <'background-color'>
# [15:33] <dbaron> where ‘/ <bg-size>’ must occur after ‘<bg-position>’ if both are present.
# [15:33] <dbaron> I thought "after" meant "immediately after".
# [15:33] <fantasai> that part was added recently, when I was trying to fix this issue
# [15:33] <jdaggett> dbaron: i think it should be immediately after
# [15:34] <jdaggett> dbaron: weird to use slash as a delimiter if don't have both sides
# [15:34] <jdaggett> and solves ambiguity problem
# [15:34] <fantasai> dbaron: and that would require background-position if background-size is used
# [15:35] <jdaggett> elika: i don't like the idea of requiring one when using the other
# [15:35] <jdaggett> elika: don't have any other ideas...
# [15:36] <jdaggett> <pregnant pause>
# [15:36] <fantasai> Someone suggested that the fallback color should go on the background-image property
# [15:36] <fantasai> background-image: url(wavy.png) / blue;
# [15:37] <Bert> (I think that is grammar #3 in http://lists.w3.org/Archives/Public/www-style/2009Apr/0358.html )
# [15:37] <jdaggett> dbaron: i'd rather say "has to come after"
# [15:37] <fantasai> then you could say bg-size can't come immediately after url9)
# [15:37] <fantasai> background-image: url(wavy.png) / blue;
# [15:37] <fantasai> background-image: url(wavy.png) / blue;
# [15:37] <fantasai> er
# [15:38] <fantasai> background: url(wavy.png) / 100%; /* invalid */
# [15:38] <fantasai> background: url(wavy.png) / blue / 100%; /* valid */
# [15:38] <jdaggett> ick
# [15:38] <jdaggett> dbaron: that's why i want to require these together
# [15:39] <jdaggett> molly: doesn't make sense?
# [15:39] <fantasai> background: url(wavy.png) top / 100%; /* valid */
# [15:39] <fantasai> background: url(wavy.png) /blue repeat-x / 100% /* valid */
# [15:39] <fantasai> dbaron proposes
# [15:39] <fantasai> background: url(wavy.png) / blue / 100%; /* invalid */
# [15:39] <fantasai> background: url(wavy.png) / blue center / 100%; /* valid */
# [15:40] <ChrisL> background: url(wavy.png) /* if css.gt.3 blue */
# [15:40] <fantasai> background: url(wavy.png) / lightblue blue center / 100%; /* valid */
# [15:41] <jdaggett> anne: fallback color needs to be the last one
# [15:41] <jdaggett> dbaron: can't distinguish that from bottom layer being color only
# [15:41] <jdaggett> elika: the fallback color has to be associated with last image
# [15:42] <jdaggett> anne: can we drop this?
# [15:43] <jdaggett> elika showing example
# [15:43] <fantasai> http://skitch.com/cgriego/bmay8/tabs-and-css-fallback-colors
# [15:44] <jdaggett> molly: yeah, this is useful
# [15:44] <jdaggett> molly: i see the issue
# [15:45] <jdaggett> anne: turn off css altogether if that's the problem
# [15:45] <jdaggett> mumbling about shift-g
# [15:45] <jdaggett> jdaggett: i officially hate this feature...
# [15:46] <jdaggett> molly: the only thing that needs to be there is the text
# [15:46] <jdaggett> molly: if the image doesn't load
# [15:46] <fantasai> fantasai: We also had some suggestions for a generic fallback mechanism
# [15:47] <jdaggett> elika: the dsl in tehran is slow
# [15:47] <jdaggett> elika: so we need this feature
# [15:47] <fantasai> elika: and most people have dialup
# [15:47] <fantasai> nevermind dsl
# [15:48] <fantasai> background: image(wavy.svg, wavy.png, wavy.gif, blue);
# [15:49] <jdaggett> anne: this is still feature bloat
# [15:49] <jdaggett> molly: this makes sense
# [15:50] <jdaggett> anne: this isn't needed at all
# [15:50] <jdaggett> molly: if you want the feature, this notation is better
# [15:51] <jdaggett> dbaron: can have commas in urls
# [15:51] <ChrisL> image(url(), url(), blue)
# [15:51] <jdaggett> dbaron: what about other values?
# [15:52] <jdaggett> anne: this is way more complex
# [15:52] <jdaggett> elika: we've wanted this for years
# [15:52] <dbaron> like regions within the image
# [15:52] <fantasai> Chris, I really would prefer to avoid the nested parentheses
# [15:52] <jdaggett> molly: should come to consesus that this is needed
# [15:52] <jdaggett> bert: not so black and white
# [15:52] <dbaron> FWIW, we designed the background layers and fallback stuff at the October 2004 meeting.
# [15:52] <jdaggett> bert: needed or wanted?
# [15:53] <jdaggett> hakon: what's the motivating factor for this?
# [15:53] <jdaggett> stevez: defines images off behavior
# [15:53] <ChrisL> ain one is to have a fallback color
# [15:54] <jdaggett> dbaron: drop this feature from background
# [15:54] <jdaggett> dbaron: add a value
# [15:54] <dbaron> we have two feature requests for the image value, fallback and https://bugzilla.mozilla.org/show_bug.cgi?id=113577#c3
# [15:55] * Joins: szilles (chatzilla@192.150.10.200)
# [15:55] <jdaggett> elika: color is treated as having no intrinsic size
# [15:55] <jdaggett> anne: yeah, because of me
# [15:55] * szilles I am on
# [15:55] * dbaron rrsagent, pointer
# [15:55] * RRSAgent See http://www.w3.org/2009/06/05-CSS-irc#T13-51-30
# [15:55] <jdaggett> szilles figures out network connection
# [15:56] <jdaggett> anne: my main concern is that we add so many features
# [15:57] <jdaggett> dbaron: i think we should drop the fallback color from the background syntax
# [15:57] <anne> and especially that we haven't had any deployment of them, actual usage feedback
# [15:57] <jdaggett> dbaron: whether we go forward with the image syntax
# [15:57] <jdaggett> discussion of which spec to use
# [15:58] <jdaggett> bert recommends writing it in chinese, less space used
# [15:58] <fantasai> RESOLUTION: fallback color dropped, explore image() syntax in another draft
# [15:58] <jdaggett> other discussions of gcpm
# [15:58] <jdaggett> hakon: changing discussion to gcpm
# [15:59] <jdaggett> large discussion of soviet union ==> russia transform
# [15:59] <jdaggett> general feeling is that this transform is definitive use case
# [16:00] <jdaggett> elika: i'm done
# [16:00] <jdaggett> daniel: all cooked and roasted
# [16:00] <jdaggett> dbaron: resolution on clipped
# [16:00] <jdaggett> elika: dropped
# [16:00] * Quits: howcome (howcome@193.51.208.72) (Ping timeout)
# [16:00] <jdaggett> dbaron: implications of dropping background-clip: context-box
# [16:00] * sylvaing this Garbage Collection Placeholder Module moment put the f in wtf
# [16:01] <jdaggett> dbaron: from the shorthand
# [16:01] * Zakim jdaggett, you typed too many words without commas; I suspect you forgot to start with 'to ...'
# [16:01] <jdaggett> dbaron explains current behavior
# [16:02] * Quits: ChrisL (ChrisL@128.30.52.30) (Client exited)
# [16:02] <jdaggett> elika: context-box is not desirable
# [16:02] <fantasai> s/context-box/background-clip: content-box/
# [16:03] <jdaggett> dbaron enumerating possible sequences of keyword sequences
# [16:03] <dbaron> So I guess we're ok with being able to hit only 4 of the six combinations of 'background-clip' and 'background-origin' with the shorthand.
# [16:07] <jdaggett> multiple editors editing...
# [16:10] <jdaggett> molly: wow
# [16:10] <jdaggett> molly: wow, thank you daniel
# [16:11] <jdaggett> big clap for daniel
# [16:11] <jdaggett> thanks to bert
# [16:11] <jdaggett> bert: come back soon
# [16:11] <jdaggett> daniel: all done
# [16:11] <jdaggett> </body>
# [16:13] <mollydotcom> </html>
# [16:16] <anne> parse error
# [16:17] * Quits: sylvaing (sylvaing@193.51.208.72) (Quit: sylvaing)
# [16:17] * Parts: mollydotcom (molly@193.51.208.72)
# [16:18] * Quits: Arron (arronei@193.51.208.72) (Ping timeout)
# [16:19] * Quits: alexmog (alexmog@193.51.208.72) (Ping timeout)
# [16:19] * Quits: dbaron (dbaron@193.51.208.72) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [16:19] * Quits: glazou (glazou@193.51.208.72) (Quit: glazou)
# [16:20] * Quits: jdaggett (jdaggett@193.51.208.72) (Ping timeout)
# [16:22] * Parts: anne (annevk@193.51.208.72)
# [16:22] * Quits: szilles (chatzilla@192.150.10.200) (Ping timeout)
# [16:24] * Joins: shepazu (schepers@128.30.52.30)
# [16:28] * Joins: myakura (myakura@122.29.15.50)
# [17:00] * Joins: dsinger (dsinger@68.126.192.44)
# [17:01] * dsinger good afternoon
# [17:05] * Joins: glazou (glazou@78.250.202.45)
# [17:14] * Quits: glazou (glazou@78.250.202.45) (Ping timeout)
# [17:39] * Quits: shepazu (schepers@128.30.52.30) (Ping timeout)
# [18:25] * Quits: dsinger (dsinger@68.126.192.44) (Quit: dsinger)
# [18:34] * Quits: Hixie (ianh@129.241.93.37) (Ping timeout)
# [18:35] * Joins: Hixie (ianh@129.241.93.37)
# [19:20] * Joins: shepazu (schepers@128.30.52.30)
# [19:42] * Quits: myakura (myakura@122.29.15.50) (Quit: Leaving...)
# [20:48] * Quits: shepazu (schepers@128.30.52.30) (Ping timeout)
# [20:57] * Joins: shepazu (schepers@128.30.52.30)
# [21:12] * Quits: shepazu (schepers@128.30.52.30) (Quit: shepazu)
# [23:04] * RRSAgent excuses himself; his presence no longer seems to be needed
# [23:04] * Parts: RRSAgent (rrs-loggee@128.30.52.30)
# [23:08] * Quits: arronei (arronei@131.107.0.112) (Connection reset by peer)
# [23:08] * Joins: arronei (arronei@131.107.0.111)
# [23:40] * Joins: glazou (glazou@90.41.159.40)
# [23:59] * Joins: dbaron (dbaron@93.10.129.131)
# Session Close: Sat Jun 06 00:00:00 2009

The end :)